解决服务器高并发解决方案.docx

解决服务器高并发解决方案.docx

《解决服务器高并发解决方案.docx》由会员分享，可在线阅读，更多相关《解决服务器高并发解决方案.docx（18页珍藏版）》请在冰豆网上搜索。

解决服务器高并发解决方案

【关键字】解决

服务器高并发解决方案

　　篇一：

JAVAWEB高并发解决方案

　　java处理高并发高负载类网站中数据库的设计方法（java教程,java处理大量数据，java高负载数据）

　　一：

高并发高负载类网站关注点之数据库没错,首先是数据库,这是大多数应用所面临的首个SPOF。

尤其是的应用，数据库的响应是首先要解决的。

　　一般来说MySQL是最常用的，可能最初是一个mysql主机，当数据增加到100万以上，那么，MySQL的效能急剧下降。

常用的优化措施是M-S（主-从）方式进行同步复制，将查询和操作和分别在不同的服务器上进行操作。

我推荐的是M-M-Slaves方式，2个主Mysql，多个Slaves，需要注意的是，虽然有2个Master，但是同时只有1个是Active，我们可以在一定时候切换。

之所以用2个M，是保证M不会又成为系统的SPOF。

　　Slaves可以进一步负载均衡，可以结合LVS,从而将select操作适当的平衡到不同的slaves上。

　　以上架构可以抗衡到一定量的负载，但是随着用户进一步增加，你的用户表数据超过1千万，这时那个M变成了SPOF。

你不能任意扩充Slaves，否则复制同步的开销将直线上升，怎么办？

我的方法是表分区，从业务层面上进行分区。

最简单的，以用户数据为例。

根据一定的切分方式，比如id，切分到不同的数据库集群去。

　　全局数据库用于meta数据的查询。

缺点是每次查询，会增加一次，比如你要查一个用户nightsailer,你首先要到全局数据库群找到nightsailer对应的clusterid，然后再到指定的cluster找到nightsailer的实际数据。

　　每个cluster可以用m-m方式，或者m-m-slaves方式。

这是一个可以扩展的结构，随着负载的增加，你可以简单的增加新的mysqlcluster进去。

　　需要注意的是：

　　1、禁用全部auto_increment的字段

　　2、id需要采用通用的算法集中分配

　　3、要具有比较好的方法来监控mysql主机的负载和服务的运行状态。

如果你有30台以上的mysql数据库在跑就明白我的意思了。

　　4、不要使用持久性链接（不要用pconnect）,相反，使用sqlrelay这种第三方的数据库链接池，或者干脆自己做，因为php4中mysql的链接池经常出问题。

　　二：

高并发高负载网站的系统架构之HTML静态化

　　其实大家都知道，效率最高、消耗最小的就是纯静态化

　　/shtml/XX07/的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。

但是对于大量内容并且频繁革新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

　　除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有革新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。

　　同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容革新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是革新频率很小，可以考虑将这部分内容进行后台革新的时候进行静态化，这样避免了大量的数据库访问请求高并发。

　　网站HTML静态化解决方案

　　当一个Servlet资源请求到达WEB服务器之后我们会填充指定的JSP页面来响应请求:

　　HTTP请求---Web服务器---Servlet--业务逻辑处理--访问数据--填充JSP--响应请求

　　HTML静态化之后:

　　HTTP请求---Web服务器---Servlet--HTML--响应请求

　　静态访求如下

　　Servlet:

　　publicvoiddoGet（HttpServletRequestrequest,HttpServletResponseresponse）throwsServletException,IOException{

　　if（（"chapterId"）!

=null）{

　　StringchapterFileName=

　　"bookChapterRead_"+（"chapterId"）+".html";

　　StringchapterFilePath=getServletContext（）.getRealPath（"/"）+chapterFileName;FilechapterFile=newFile（chapterFilePath）;

　　if（（））{（chapterFileName）;return;}//如果有这个文件就告诉浏览器转向

　　INovelChapterBiznovelChapterBiz=newNovelChapterBizImpl（）;

　　NovelChapternovelChapter=

　　（（（"chapterId"）））;//章节信息

　　intlastPageId=

　　（（）.getId（）,

　　（））;

　　intnextPageId=

　　（（）.getId（）,

　　（））;

　　（"novelChapter",novelChapter）;

　　（"lastPageId",lastPageId）;

　　（"nextPageId",nextPageId）;

　　newCreateStaticHTMLPage（）.createStaticHTMLPage（request,response,getServletContext（）,

　　chapterFileName,chapterFilePath,"/"）;

　　}

　　}

　　生成HTML静态页面的类:

　　package;

　　import;

　　import;

　　import;

　　import;

　　import;

　　import;

　　import;

　　import;

　　import;

　　import;

　　import;

　　import;

　　/**

　　*创建HTML静态页面

　　*功能：

创建HTML静态页面

　　*时间：

XX年1011日

　　*地点：

home

　　*@authormavk

　　*

　　*/

　　publicclassCreateStaticHTMLPage{

　　/**

　　*生成静态HTML页面的方法

　　*@paramrequest请求对象

　　*@paramresponse响应对象

　　*@paramservletContextServlet上下文

　　*@paramfileName文件名称

　　*@paramfileFullPath文件完整路径

　　*@paramjspPath需要生成静态文件的JSP路径（相对即可）

　　*@throwsIOException

　　*@throwsServletException

　　*/

　　publicvoidcreateStaticHTMLPage（HttpServletRequestrequest,

　　HttpServletResponseresponse,ServletContextservletContext,StringfileName,StringfileFullPath,StringjspPath）throwsServletException,IOException{

　　（"text/html;charset=gb2312"）;//设置HTML结果流编码（即HTML文件编码）

　　RequestDispatcherrd=（jspPath）;//得到JSP资源

　　finalByteArrayOutputStreambyteArrayOutputStream=new

　　ByteArrayOutputStream（）;//用于从ServletOutputStream中接收资源

　　finalServletOutputStreamservletOuputStream=newServletOutputStream（）{//用于从HttpServletResponse中接收资源

　　publicvoidwrite（byte[]b,intoff,intlen）{

　　（b,off,len）;

　　}

　　publicvoidwrite（intb）{

　　（b）;

　　}

　　};

　　finalPrintWriterprintWriter=newPrintWriter（new

　　OutputStreamWriter（byteArrayOutputStream））;//把转换字节流转换成字符流

　　HttpServletResponsehttpServletResponse=new

　　HttpServletResponseWrapper（response）{//用于从response获取结果流资源（重写了两个方法）

　　publicServletOutputStreamgetOutputStream（）{

　　篇二：

高并发网站架构解决方案

　　一个小型的网站，比如个人网站，可以使用最简单的html静态页面就实现了，配合一些图片达到美化效果，所有的页面均存放在一个目录下，这样的网站对系统架构、性能的要求都很简单，随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。

　　大型网站，比如门户网站。

在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：

使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。

但是除了这几个方面，还没法根本解决大型网站面临的高负载和高并发问题。

　　上面提供的几个解决思路在一定程度上也意味着更大的投入，并且这样的解决思路具备瓶颈，没有很好的扩展性，下面我从低成本、高性能和高扩张性的角度来说说我的一些经验。

　　1、HTML静态化

　　其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。

但是对于大量内容并且频繁革新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

　　除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有革新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。

　　同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容革新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是革新频率很小，可以考虑将这部分内容进行后台革新的时候进行静态化，这样避免了大量的数据库访问请求。

　　一下是一个SSH下的html静态化例子

　　用Article表来演示下页面静态化，在此做记录，便于今后参考。

这里是基于SSH2架构来演示的。

　　1.演示工程整体结构概览

　　这里我引入了htdz_lib这么个UserLibraliry，包含了SSH2整合所需的jar以及。

　　同时也已创建于WEB-INF下。

　　表预览

　　我们给Article表增加个HadStatic字段，用以标识此文章是否已静态化。

　　我们不建议添加一篇文章就直接生成对应的静态页面，如果都没有用户来阅读，服务器就徒增了大量html文件，浪费资源。

　　所以我们一般采用访问生成策略：

　　用户访问某文章，判断服务器是否存在此文章对应的静态页，存在则直接重定向到此静态页面，不存在则执行静态化，然后再重定向到生成的静态页。

　　然而每次通过IO去查找文件是否存在，耗费性能，所以像Article这类表加个HadStatic字段，直接判断字段的值来决定是否静态化显得合理多了。

　　3.配置1.2.

　　3.contextConfigLocation

　　4.

　　5.classpath:

conf/spring/

　　6.

　　7.

　　8.

　　9.

　　10.

　　11.

　　12.

　　13.

　　14.

　　15.

　　16.

　　17.struts2

　　18.

　　19.

　　20.

　　21.

　　22.

　　23.

　　24.

　　25.

　　26.

　　27.

　　28.

　　29.

　　30.

　　31.

　　32.

　　33.

　　34.

　　35.

　　36.

　　37.

　　38.

　　39.

　　40.

　　41.struts2/*REQUESTFORWARDINCLUDEUrlRewriteFilterlogLevelWARNUrlRewriteFilter/*

　　其它你懂的，就是修改了struts2的过滤器的，增加了几个

　　，WHY?

后面会讲到。

另外再加了个urlrewrite的过滤器。

　　4.配置

　　1.

　　2.

　　3.

　　其他dataSource、sessionFactory、事务等配置，不是本帖的重点，略去了。

　　这里我在中用了default-autowire="byName"让spring自动装配依赖的bean了。

　　5.下面贴上各层的代码

　　以下是

　　再是及

　　篇三：

高并发数据库解决方案

　　高并发高负载数据库架构策略

　　在WEB网站的规模从小到大不断扩展的过程中，数据库的访问压力也不断的增加，数据库的架构也需要动态扩展，在数据库的扩展过程基本上包含如下几步，每一个扩展都可以比上一步骤的部署方式的性能得到数量级的提升。

　　1.WEB应用和数据库部署在同一台服务器上

　　一般的小规模的网站采用这种方式，用户量、数据量、并发访问量都比较小，否则单台服务器无法承受，并且在遇到性能瓶颈的时候升级硬件所需要的费用非常高昂，在访问量增加的时候，应用程序和数据库都来抢占有限的系统资源，很快就又会遇到性能问题。

　　2.WEB应用和数据库部署在各自独立的服务器上

　　web应用和数据库分开部署，WEB应用服务器和数据库服务器各司其职，在系统访问量增加的时候可以分别升级应用服务器和数据库服务器，这种部署方式是一般小规模网站的典型部署方式。

在将应用程序进行性能优化并且使用数据库对象缓存策略的情况下，可以承载较大的访问量，比如XX用户，200个并发，百万级别的数据量。

　　3.数据库服务器采用集群方式部署（比如Oracle的一个数据库多个实例的情况）

　　数据库集群方式能承担的负载是比较大的，数据库物理介质为一个磁盘阵列，多个数据库实例以虚拟IP方式向外部应用服务器提供数据库连接服务。

这种部署方式基本上可以满足绝大多数的常见WEB应用，但是还是不能满足大用户量、高负载、数据库读写访问非常频繁的应用。

　　4.数据库采用主从部署方式

　　在面向大众用户的博客、论谈、交友、CMS等系统中，有上百万的用户，有上千万的数据量，存在众多的数据库查询操作，也有较多的数据库写操作，并且在多数情况下都是读操作远大于写操作的。

在这个时候，假如能将数据库的读写操作分离的话，对于系统来讲是一个很大的提高啦。

数据库的主从部署方式就走到我们面前啦。

　　主从复制：

几乎所有的主流数据库都支持复制，这是进行数据库简单扩展的基本手段。

下面以Mysql为例来说明，它支持主从复制，配置也并不复杂，只需要开启主服务器上的二进制日志以及在主服务器和从服务器上分别进行简单的配置和授权。

Mysql的主从复制是一句主服务器的二进制日志文件进行的，主服务器日志中记录的操作会在从服务器上重放，从而实现复制，所以主服务器必须开启二进制日志，自动记录所有对于主数据库的革新操作，从服务器再定时到主服务器取得二进制日志文件进行重放则完成了数据的复制。

主从复制也

　　用于自动备份。

　　读写分离：

为保证数据库数据的一致性，我们要求所有对于数据库的革新操作都是针对主数据库的，但是读操作是可以针对从数据库来进行。

大多数站点的数据库读操作比写操作更加密集，而且查询条件相对复杂，数据库的大部分性能消耗在查询操作上了。

　　主从复制数据是异步完成的，这就导致主从数据库中的数据有一定的延迟，在读写分离的设计中必须要考虑这一点。

以博客为例，用户登录后发表了一篇文章，他需要马上看到自己的文章，但是对于其它用户来讲可以允许延迟一段时间（1分钟/5分钟/30分钟），不会造成什么问题。

这时对于当前用户就需要读主数据库，对于其他访问量更大的外部用户就可以读从数据库。

　　数据库反向代理：

在读写分离的方式使用主从部署方式的数据库的时候，会遇到一个问题，一个主数据库对应多台从服务器，对于写操作是针对主数据库的，数据库个数是唯一的，但是对于从服务器的读操作就需要使用适当的算法来分配请求啦，尤其对于多个从服务器的配置不一样的时候甚至需要读操作按照权重来分配。

对于上述问题可以使用数据库方向代理来实现。

就像WEB方向代理服务器一样，MYsqlProxy同样可以在SQL语句转发到后端的Mysql服务器之前对它进行修改。

　　5.数据库垂直分割

　　主从部署数据库中，当写操作占了主数据库的CPU消耗的50%以上的时候，我们再增加从服务器的意义就不是很大了，因为所有的从服务器的写操作也将占到CPU消耗的50%以上，一台从服务器提供出来查询的资源非常有限。

数据库就需要重新架构了，我们需要采用数据库垂直分区技术啦。

最简单的垂直分区方式是将原来的数据库中独立的业务进行分拆（被分拆出来的部分与其它部分不需要进行Join连接查询操作），比如WEB站点的BLOG和论坛，是相对独立的，与其它的数据的关联性不是很强，这时可以将原来的数据库拆分为一个BLog库，一个论坛库，以及剩余的表所组成的库。

这三个库再各自进行主从数据库方式部署，这样整个数据库的压力就分担啦。

　　另外查询扩展性也是采用数据库分区最主要的原因之一。

将一个大的数据库分成多个小的数据库可以提高查询的性能，因为每个数据库分区拥有自己的一小部分数据。

假设您想扫描1亿条记录，对一个单一分区的数据库来讲，该扫描操作需要数据库管理器独立扫描一亿条记录，如果您将数据库系统做成50个分区，并将这1亿条记录平均分配到这50个分区上，那么每个数据库分区的数据库管理器将只扫描200万记录。

　　6.数据库水平分割

　　在数据库的垂直分区之后，假如我们的BLOG库又再次无法承担写操作的时候，我们又该怎么办呢？

数据库垂直分区这种扩展方式又无能为力了，我们需要的是水平分区。

水平分区意味着我们可以将同一个数据库表中的记录通过特定的算法进行分离，分别保存在不同的数据库表中，从而可以部署在不同的数据库服务器上。

很多的大规模的站点基本上都是主从复制+垂直分区+水平分区这样的架构。

水平分区并不依赖什么特定的技术，完全是逻辑层面的规划，需要的是经验和业务的细分。

　　如何分区呢？

对于大型的WEB站点来说，必须分区，并且对于分区我们没有选择的余地，对于那些频繁访问导致站点接近崩溃的热点数据，我们必须分区。

　　在对数据分区的时候，我们必须要存在一个分区索引字段，比如USER_ID，它必须和所有的

　　记录都存在关系，是分区数据库中的核心表的主键，在其它表中作为外键，并且在使用主键的时候，该主键不能是自增长的，必须是业务主键才可以。

　　余数分区：

我们可以将User_ID%10后的值为依据存入到不同的分区数据库中，该算法简单高效，但是在分区数据库个数有变动的时候，整个系统的数据需要重新分布。

　　范围分区：

我们可以将User_ID的范围进行分区，比如1-100000范围为一个分区数据库，100001-XX00范围为一个分区数据库，该算法在分区数据库个数有变动的时候，系统非常有利于扩展，但是容易导致不同分区之间的压力不同，比如老用户所在的分区数据库的压力很大，但是新用户的分区数据库的压力偏小。

　　映射关系分区：

将对分区索引字段的每个可能的结果创建一个分区映射关系，这个映射关系非常庞大，需要将它们写入数据库中。

比如当应用程序需要知道User_id为10的用户的BLOG内容在那个分区时，它必须查询数据库获取答案，当然，我们可以使用缓存来提高性能。

这种方式详细保存了每一个记录的分区对应关系，所以各个分区有非常强的可伸缩性，可以灵活的控制，并且将数据库从一个分区迁移到另一个分区也很简单，也可以使各个分区通过灵活的动态调节来保持压力的分布平衡。

　　大数据量高并发的数据库优化

　　发表日期：

XX-01-19一、数据库结构的设计

　　如果不能设计一个合理的数据库模型，不仅会增加客户端和服务器段程序的编程和维护的难度，而且将会影响系统实际运行的性能。

所以，在一个系统开始实施之前，完备的数据库模型的设计是必须的。

在一个系统分析、设计阶段，因为数据量较小，负荷较低。

我们往往只注意到功能的实现，而很难注意到性能的薄弱之处，等到系统投入实际运行一段时间后，才发现系统的性能在降低，这时再来考虑提高系统性能则要花费更多的人力物力，而整个系统也不可避免的形成了一个打补丁工程。

所以在考虑整个系统的流程