一句话解决高并发的核心原则

高并发访问的核心原则其实就一句话“把所有的用户访问请求都尽量往前推”。

如果把来访用户比作来犯的"敌人"&＃xff0c;我们一定要把他们挡在800里地以外&＃xff0c;即不能让他们的请求一下打到我们的指挥部&＃xff08;指挥部就是数据库及分布式存储&＃xff09;。

如&＃xff1a;能缓存在用户电脑本地的&＃xff0c;就不要让他去访问CDN。 能缓存CDN服务器上的&＃xff0c;就不要让CDN去访问源&＃xff08;静态服务器&＃xff09;了。能访问静态服务器的&＃xff0c;就不要去访问动态服务器。以此类推&＃xff1a;能不访问数据库和存储就一定不要去访问数据库和存储。

   说起来很轻松&＃xff0c;实际做起来却不容易&＃xff0c;但只要稍加努力是可以做到的&＃xff0c;Google的日独立IP过亿不也做到了么&＃xff1f;我们这几千万的PV站比起Google不是小屋见大屋了。我们还是先从我们的小屋搭起吧&＃xff01;哈哈&＃xff01;下面内容的介绍起点是千万级别的PV站&＃xff0c;也可以支持亿级PV的网站架构。

高性能高并发高可扩展网站架构访问的几个层次&＃xff1a;

有人会问&＃xff0c;我们老是说把用户对业务的访问往前推&＃xff0c;到底怎么推啊&＃xff1f;推到哪呢&＃xff1f;下面&＃xff0c;老男孩就为大家一一道来。

第一层&＃xff1a;首先在用户浏览器端&＃xff0c;使用Apache的mod_deflate压缩传输&＃xff0c;再比如&＃xff1a;expires功能、deflate和expires功能利用的好&＃xff0c;就会大大提升用户体验效果及减少网站带宽&＃xff0c;减少后端服务器的压力。当然&＃xff0c;方法还有很多&＃xff0c;这里不一一细谈了。

提示&＃xff1a;有关压缩传输及expires功能nginx/lighttpd等软件同样也有。

第二层&＃xff1a;页面元素&＃xff0c;如图片/js/css等或静态数据html&＃xff0c;这个层面是网页缓存层,比如CDN&＃xff08;效果比公司自己部署squid/nginx要好&＃xff0c;他们更专业&＃xff0c;价格低廉&＃xff0c;比如快网/CC等&＃xff08;价格80元/M/月甚至更低&＃xff09;而且覆盖的城市节点更多&＃xff09;&＃xff0c;自己架设squid/nginx cache来做小型CDN是次选(超大规模的公司可能会考虑风险问题实行自建加购买服务结合)&＃xff0c;除非是为前端的CDN提供数据源服务&＃xff0c;以减轻后端我们的服务器数据及存储压力&＃xff0c;而不是直接提供cache服务给最终用户。taobao的CDN曾经因为一部分图片的次寸大而导致CDN压力大的情况&＃xff0c;甚至对图片尺寸大的来改小&＃xff0c;以达到降低流量及带宽的作用。

提示&＃xff1a;我们也可以自己架设一层cache层&＃xff0c;对我们购买的CDN提供数据源服务&＃xff0c;可用的软件有varnish/nginx/squid等cache&＃xff0c;以减轻第三层静态数据层的压力。在这层的前端我们也可以架设DNS服务器&＃xff0c;来达到跨机房业务拓展及智能解析的目的。

    第三层&＃xff1a;静态服务器层一般为图片服务器&＃xff0c;视频服务器&＃xff0c;静态HTML服务器。这一层是前面缓存层和后面动态服务器层的连接纽带&＃xff0c;大公司发布新闻等内容直接由发布人员分发到各cache节点&＃xff08;sina,163等都是如此&＃xff09;&＃xff0c;这和一般公司的业务可能不一样。所以&＃xff0c;没法直接的参考模仿&＃xff0c;比如人人的SNS。

我们可以使用Q队列方式实现异步的分发访问&＃xff0c;同时把动态发布数据&＃xff08;数据库中的数据&＃xff09;静态化存储。即放到本层访问&＃xff0c;或通过其他办法发布到各cache节点&＃xff0c;而不是直接让所有用户去访问数据库&＃xff0c;不知道大家发现了没有&＃xff0c;qq.com门户的新闻评论多的有几十万条&＃xff0c;如果所有用户一看新闻就加载所有评论&＃xff0c;那数据库不挂才怪。他们的评论需要审核&＃xff08;美其名约&＃xff0c;实际是异步的方式&＃xff0c;而且&＃xff0c;评论可能都是静态化的或类似的静态化或内存cache的方式&＃xff09;&＃xff0c;这点可能就是需要51cto.com这样站点学习的&＃xff0c;你们打开51CTO的一篇博文&＃xff0c;就会发现下面的评论一直都显示出来了&＃xff0c;也可能是分页的。不过&＃xff0c;应该都是直接读库的&＃xff0c;一旦访问量大&＃xff0c;数据库压力大是必然。这里不是说51cto网站不好&＃xff0c;所有的网站都是从类似的程序架构开始发展的。CU也可能是如此。

提示&＃xff1a;我们可以在静态数据层的前端自己架设一层cache层&＃xff0c;对我们购买的CDN提供数据源服务&＃xff0c;可用的软件有varnish/nginx/squid 等cache。在这层的前端我们也可以架设DNS服务器&＃xff0c;来达到跨机房业务拓展及智能解析的目的。

第四层&＃xff1a;动态服务器层&＃xff1a;php,java等&＃xff0c;只有透过了前面3层后的访问请求才会到这个层&＃xff0c;才可能会访问数据库及存储设备。经过前三层的访问过滤能到这层访问请求一般来说已非常少了&＃xff0c;一般都是新发布的内容和新发布内容第一次浏览如&＃xff1b;博文&＃xff08;包括微博等&＃xff09;&＃xff0c;BBS帖子。

特别提示&＃xff1a;此层可以在程序上多做文章&＃xff0c;比如向下访问cache层&＃xff0c;memcache,memcachedb,tc,mysql,oracle&＃xff0c;在程序级别实现分布式访问&＃xff0c;分布式读写分离&＃xff0c;而程序级别分布式访问的每个dbcache节点&＃xff0c;又可以是一组业务或者一组业务拆分开来的多台服务器的负载均衡。这样的架构会为后面的数据库和存储层大大的减少压力&＃xff0c;那么这里呢&＃xff0c;相当于指挥部的外层了。

第五层&＃xff1a;数据库cache层&＃xff0c;比如&＃xff1a;memcache,memcachedb,tc等等。

根据不同的业务需求&＃xff0c;选择适合具体业务的数据库。对于memcache、memcachedb ttserver及相关nosql数据库&＃xff0c;可以在第四层通过程序来实现对本层实现分布式访问&＃xff0c;每个分布式访问的节点都可能是一组负载均衡&＃xff08;数十台机器&＃xff09;。

第六层&＃xff1a;数据库层&＃xff0c;一般的不是超大站点都会用mysql主从结构&＃xff0c;如&＃xff1a;163,sina,kaixin都是如此&＃xff0c;程序层做分布式数据库读写分离&＃xff0c;一主&＃xff08;或双主&＃xff09;多从的方式&＃xff0c;访问大了&＃xff0c;可以做级连的主从及环状的多主多从&＃xff0c;然后&＃xff0c;实现多组负载均衡&＃xff0c;供前端的分布式程序调用&＃xff0c;如果访问量在大&＃xff0c;就需要拆业务了&＃xff0c;比如&＃xff1a;我再给某企业做兼职时&＃xff0c;发现类似的51cto的一个站点&＃xff0c;把www服务,blog服务&＃xff0c;bbs服务都放一个服务器上&＃xff0c;然后做主从。这种情况&＃xff0c;当业务访问量大了&＃xff0c;可以简单的把www,blog,bbs服务分别各用一组服务器拆分开&＃xff0c;这种方式运维都会的没啥难度。当然访问量在大了&＃xff0c;可以继续针对某一个服务拆分如&＃xff1a;www库拆分&＃xff0c;每个库做一组负载均衡&＃xff0c;还可以对库里的表拆分。需要高可用可以通过drbd等工具做成高可用方式。对于写大的&＃xff0c;可以做主主或多主的MYSQL REP方式&＃xff0c;对于ORACLE来说&＃xff0c;来几组oracle DG&＃xff08;1master多salve方式&＃xff09;就够了&＃xff0c;11G的DG可以象mysqlrep一样&＃xff0c;支持读写分离了。当然可选的方案还有&＃xff0c;mysql cluster 和oracle 的RAC&＃xff0c;玩mysqlcluster和oracleRAC要需要更好更多的硬件及部署后的大量维护成本&＃xff0c;因此&＃xff0c;要综合考虑&＃xff0c;到这里访问量还很大&＃xff0c;那就恭喜了&＃xff0c;起码是几千万以上甚至上亿的PV了。

象百度等巨型公司除了会采用常规的mysql及oracle数据库库外&＃xff0c;会在性能要求更高的领域&＃xff0c;大量的使用nosql数据库&＃xff0c;然后前端在加DNS&＃xff0c;负载均衡&＃xff0c;分布式的读写分离&＃xff0c;最后依然是拆业务&＃xff0c;拆库&＃xff0c;。。。逐步细化&＃xff0c;然后每个点又可以是一组或多组机器。

特别提示&＃xff1a;数据库层的硬件好坏也会决定访问量的多少&＃xff0c;尤其是要考虑磁盘IO的问题&＃xff0c;大公司往往在性价比上做文章&＃xff0c;比如核心业务采用硬件netapp/emc及san光纤架构&＃xff0c;对于资源数据存储&＃xff0c;如图片视频&＃xff0c;会采用sas或固态ssd盘&＃xff0c;如果数据超大&＃xff0c;可以采取热点分取分存的方法&＃xff1a;如&＃xff1a;最常访问的10-20%使用ssd存储&＃xff0c;中间的20-30%采用sas盘&＃xff0c;最后的40-50%可以采用廉价的sata。

第七层&＃xff1a;千万级PV的站如果设计的合理一些&＃xff0c;1&＃xff0c;2个NFSSERVER就足够了。我所维护&＃xff08;兼职&＃xff09;或经历过的上千万PV的用NFS及普通服务器做存储的还有大把&＃xff0c;多一些磁盘&＃xff0c;如SAS 15K*6的&＃xff0c;或者用dell6850&＃xff0c;搞几组 NFS存储&＃xff0c;中小网站足够了。当然可以做成drbd&＃43;heartbeat&＃43;nfs&＃43;a/a的方式。

如果能达到本文设计要求的&＃xff0c;中等规模网站&＃xff0c;后端的数据库及存储压力会非常小了。 象门户网站级别&＃xff0c;如sina等&＃xff0c;会采用硬件netapp/emc等等硬件存储设备或是san光纤同道&＃xff0c;甚至在性价比上做文章&＃xff0c;比如核心业务采用硬件netapp/emc及san光纤架构&＃xff0c;对于资源数据存储&＃xff0c;如图片视频&＃xff0c;会采用sas或固态ssd盘&＃xff0c;如果数据超到&＃xff0c;可以采取热点分取分存的方法&＃xff1a;如&＃xff1a;最常访问的10-20%使用ssd存储&＃xff0c;中间的20-30%采用sas盘&＃xff0c;最后的40-50%可以采用廉价的sata。

象百度等巨型公司会采用hadoop等分布式的存储架构&＃xff0c;前端在加上多层CACHE及多及的负载均衡&＃xff0c;同样会根据业务进行拆分&＃xff0c;比如爬虫层存储&＃xff0c;索引层存储&＃xff0c;服务层存储。。。可以更细更细。。。为了应付压力&＃xff0c;什么手段都用上了。

    特殊业务&＃xff0c;如人人&＃xff0c;开心网&＃xff0c;包括门户网站的评论&＃xff0c;微博&＃xff0c;大多都是异步的写入方式&＃xff0c;即无论读写&＃xff0c;并发访问数据库都是非常少量的。