如果网站的请求量过大，我们可以将页面静态化提供访问来缓解服务器压力，能够缓解服务器压力加大以及降低数据库数据的频繁交换。适合于某些访问了过大，但是内容不经常改变的页面，如首页、新闻页等

顾名思义，文件服务器就是将文件系统单独拿出来提供专注于处理文件的存储访问系统，甚至于对个文件服务器。因为对于图片这种资源的访问存储是web服务最耗资源的地方，将文件服务器单独部署既可以将压力转移，交给专门的系统处理，又可以分担风险，如果图片服务器出现问题，那么主服务器能够保证正常，顶多就是文件请求不到。

负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。

负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。其原理就是将大量工作分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。

解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的优点是基于特定环境，配置简单，使用灵活，成本低廉，可以满足一般的负载均衡需求。

软件解决方案缺点也较多，因为每台服务器上安装额外的软件运行会消耗系统不定量的资源，越是功能强大的模块，消耗得越多，所以当连接请求特别大的时候，软件本身会成为服务器工作成败的一个关键；软件可扩展性并不是很好，受到操作系统的限制；由于操作系统本身的Bug，往往会引起安全问题。

解决方案是直接在服务器和外部网络间安装负载均衡设备，这种设备通常称之为负载均衡器，由于专门的设备完成专门的任务，独立于操作系统，整体性能得到大量提高，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。

负载均衡器有多种多样的形式，除了作为独立意义上的负载均衡器外，有些负载均衡器集成在交换设备中，置于服务器与Internet链接之间，有些则以两块网络适配器将这一功能集成到PC中，一块连接到Internet上，一块连接到后端服务器群的内部网络上。

一般而言，硬件负载均衡在功能、性能上优于软件方式，不过成本昂贵。

本地负载均衡是指对本地的服务器群做负载均衡，全局负载均衡是指对分别放置在不同的地理位置、有不同网络结构的服务器群间作负载均衡。

本地负载均衡能有效地解决数据流量过大、网络负荷过重的问题，并且不需花费昂贵开支购置性能卓越的服务器，充分利用现有设备，避免服务器单点故障造成数据流量的损失。其有灵活多样的均衡策略把数据流量合理地分配给服务器群内的服务器共同负担。即使是再给现有服务器扩充升级，也只是简单地增加一个新的服务器到服务群中，而不需改变现有网络结构、停止现有的服务。

全局负载均衡主要用于在一个多区域拥有自己服务器的站点，为了使全球用户只以一个IP地址或域名就能访问到离自己最近的服务器，从而获得最快的访问速度，也可用于子公司分散站点分布广的大公司通过Intranet（企业内部互联网）来达到资源统一合理分配的目的。

全局负载均衡有以下的特点：

实现地理位置无关性，能够远距离为用户提供完全的透明服务。

除了能避免服务器、数据中心等的单点失效，也能避免由于ISP专线故障引起的单点失效。

解决网络拥塞问题，提高服务器响应速度，服务就近提供，达到更好的访问质量。

客户端直接访问的服务器并不是直接提供服务的服务器，它从别的服务器获取资源，然后将结果返回给用户。

代理服务器和反向代理服务器：

代理服务器是代我们访获取资源，然后将结果返回。例如，访问外网的代理服务器。反向代理服务器是我们正常访问一台服务器的时候，服务器自己调用了别的服务器。

反向代理就是说，用户的请求请求到负载均衡的设备上，负载均衡设备再讲请求分发到空闲的应用服务器上处理，处理完成之后再通过负载均衡设备返回给用户，这样对于用户来说，后来的分发是不可见的。

1）需要有一个负载均衡设备来分发用户请求，将用户请求分发到空闲的服务器上

2）服务器返回自己的服务到负载均衡设备

3）负载均衡将服务器的服务返回用户

代理服务器我们主动使用，是为我们服务的，不需要有自己的域名；反向代理是服务器自己使用的，我们并不知道，有自己的域名。

所谓动静分离就是将网站静态资源（HTML，JavaScript，CSS，img等文件）与后台应用分开部署，提高用户访问静态代码的速度，降低对后台应用访问。上面的文件服务器就是动静分离的一部分。

动静分离的一种做法是将静态资源部署在nginx上，后台项目部署到应用服务器上，根据一定规则静态资源的请求全部请求nginx服务器，达到动静分离的目标。

静态资源部署至CDN上

我们的方案是直接将静态资源全部存放在CDN服务器上。因为之前项目中的JavaScript,CSS以及img文件都是存放在CDN服务器上，将HTML文件一起存放到CDN上之后，可以将静态资源统一放置在一种服务器上，便于前端进行维护；而且用户在访问静态资源时，可以很好利用CDN的优点——CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。

后端应用提供API，根据前端的请求进行处理，并将处理结果通过JSON格式返回至前端。目前应用主要采用Java平台开发，因此应用服务器主要是Tomcat服务器，现在也开始有部分应用采用 node进行开发，应用服务器也开始使用node服务器。

动静分离因为静态资源和应用服务分别部署在不同的服务器上，因此会面临域名策略的选择。

采用相同域名下，用户请求api时可以避免跨域所带来的问题，相对开发更为快速，工作量也相对小一些。

前后端采用不同域名时，需要前后端开发时兼容跨域请求的情况，开发量相对上一种会稍多一些。解决跨域方式最常用的方式就是采用JSONP，还有一种解决方式使用CORS（HTTP访问控制）允许某些域名下的跨域请求。

目前在我们的项目中JSONP方式更多，CORS因为需要浏览器支持，因此只会在APP内嵌HTML5，且需要POST方式时中使用。

采用不同域名的方式优点也是非常明显的，不同域名采用两个域名服务器，不同的域名服务器根据请求的不同采用不同的负载均衡策略；而且不同域名也可以邮箱方式前端携带过多的Cookie。

api接口服务化：动静分离之后，后端应用更为服务化，只需要通过提供api接口即可，可以为多个功能模块甚至是多个平台的功能使用，可以有效的节省后端人力，更便于功能维护。

前后端开发并行：前后端只需要关心接口协议即可，各自的开发相互不干扰，并行开发，并行自测，可以有效的提高开发时间，也可以有些的减少联调时间

减轻后端服务器压力，提高静态资源访问速度：后端不用再将模板渲染为html返回给用户端，且静态服务器可以采用更为专业的技术提高静态资源的访问速度。

在开发中可以采用前端缓存不经常变化数据的方式来解决，只有哪些经常发生变化的数据才每次向后端请求。

开发量变大，前后端交流成本升高：后端api返回的数据，往往是有自身逻辑在内的，比如返回数据中的包含status（1-处理中，2-处理成功，3-处理失败），前端需要理解status的不同含义，对应的前端操作需要理解（如，status =1 or status = 2，不可提交）。

在业务高速发展时需要慎重考虑：因为开发量变大，如果在业务开始阶段，缺乏前端又要求开发速度很快，就需要慎重考虑这种方式的实现成本对业务发展的影响。

对于相同功能的sql，如果数据库的sql没有做过优化和做过优化的sql比较起来，其处理能力完全是天壤之别，其差距可以有几倍甚至几十上百上千的速度差距、资源消耗差距。所以对于一个优秀的web应用，sql优化是必须做的。

对于缓存我想大家都不陌生，缓存可以让我们将一些有时效性的、经常访问的、不便于存储数据库等的数据，我们可以将数据存储在专门的用于缓存的应用程序中，如果有必要，还可以将缓存应用服务器单独部署，如果数据量过大，我们还可以组成缓存服务器集群，比如：cache、redis等都是比较专注于缓存数据的。

只所以使用缓存，是因为一是减少数据库的访问压力，二是一般专注于缓存的应用对于数据的读写较于数据库都是非常快的

读写分离是为了提供程序的性能，随着用户的增加，数据库的压力也会越来越大，对数据库或者SQL的基本优化可能达不到最终的效果，读写分离简单的说是把对数据库读和写的操作分开对应不同的数据库服务器，这样能有效地减轻数据库压力，也能减轻io压力。主数据库提供写操作，从数据库提供读操作。主数据库提供写操作，从数据库提 供读操作，其实在很多系统中，主要是读的操作。当主数据库进行写操作时，数据要同步到从的数据库，这样才能有效保证数据库完整性。Quest SharePlex就是比较牛的同步数据工具，听说比oracle本身的流复制还好，mysql也有自己的同步数据技术。mysql只要是通过二进制日志来复制数据。通过日志在从数据库重复主数据库的操作达到复制数据目的。这个复制比较好的就是通过异步方法，把数据同步到从数据库。

当然同样的因为数据的复制同步需要时间，对于一些实时性要求非常高的逻辑可能会有问题。

9.数据库活跃数据分离

所谓的活跃数据就是经常用到的数据，比如经常活跃的用户数据等。不活跃数据，比如好长时间不等路的用户数据，还有几个月前的数据等等。

对于这种不活跃的数据参与到查询中，会很大的拖累查询速度吗，所以讲非活跃数据单独同步到一个数据库中，这样大概率的查询只需要查活跃数据的数据库，只有活跃数据的数据库查不到时，才去查非活跃数据库。

10.批量读取和延迟修改

高并发情况可以将多个查询请求合并到一个。同一查询，同一返回处理，降低短时间内的数据库请求数量。高并发且频繁修改的可以暂存缓存中，然后统一进行修改。

11.数据库集群和库表散列

通常对于一个服务器的处理的瓶颈大多在于数据库的瓶颈，对于大数据量的请求处理，单个数据库处理能力有限，所以我们可以部署多个数据库，然后将数据库组成一个集群。

对于数据库集群，每个成熟的数据库都有自己的解决方案，我们按照方案进行扩展即可。

上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

　　前言：最近在做分布式海量数据处理项目，使用到了java的线程池，所以搜集了一些资料对它的使用做了一下总结和探究，

　　前面介绍的东西大多都是从网上搜集整理而来。文中最核心的东西在于后面两节无界队列线程池和有界队列线程池的实例使用以及线上问题处理方案。