原文：http://oldboy.blog.51cto.com/2561410/615721

如何才能做到网站高并发访问?--之我荐--老男孩
#########################################################
# 如何才能做到网站高并发访问?--之我荐
#date:2011-07-18
#作者：老男孩
#QQ:31333741 MAIL:oldboy521@hotmail.com
#QQ交流群：45039636   
#blog: http://oldboy.blog.51cto.com
#psite: http://oldboy.cc（即将开放）
#pblog:http://blog.etiantian.org
##########################################################

看了抚琴煮酒兄弟的文章http://andrewyu.blog.51cto.com/1604432/612032) 由感而发，随意谈了下高并发的一些经验，因此写了本文。
      时间短，经验有限，可能有很多语句描述不清，错别字等，如果对大家有一丝帮助，我就很开心了，欢迎大家指正！

█ 高并发网站访问的几个层次
有人会问，老说把用户对业务访问往前推，到底怎么推啊？推到哪呢？
==========================================================================》
 第一层：在用户浏览器端，使用apache的mod_deflate压缩传输，在比如：expires功能
         deflate和expires功能利用的好，就会大大提升用户体验效果及减少网站带宽，
         减少后端服务器的压力。当然，方法还有很多，这里不一一细谈了。这里的apache,还可以是Nginx,lighttpd等web服务软件。

第二层：页面元素，如图片/js/css等或静态数据html，这个层面是网页缓存层,
         比如CDN（效果比公司自己部署squid要好，他们专业，价格低廉，比如快网/CC等
       （价格80元/M/月不到）而且覆盖的城市更多），
         自己架设squid是次选，除非是为前端CDN提供服务，以减轻后端存储压力，而不是
         直接提供服务给最终用户。

第三层：静态服务器层一般为图片服务器，视频服务器，静态HTML服务器。
         这一层是前面缓存层和后面动态服务器层的连接纽带，大公司发布新闻
         等直接由发布人员分发到各cache节点（sina,163等都是如此），这和一
         般公司的业务可能不一样。所以，没法直接的参考模仿，比如人人的SNS。
         我们可以使用Q队列方式实现异步的分发访问，同时把动态发布数据（数
         据库中的数据）静态化存储。即放到本层访问，或通过其他办法发布到各
         cache节点，而不是直接让所有用户去访问数据库，不知道大家发现了没有，
         qq.com门户的新闻评论多的有几十万条，如果所有用户一看新闻就加载所有
         评论，那数据库不挂才怪。他们的评论需要审核（美其名约，实际是异步的
         方式，而且，评论可能都是静态化的或类似的静态化或内存cache的方式），
         这点可能就是需要51cto.com这样站点学习的，你们打开51CTO的一篇博文，
         就会发现下面的评论一直都显示出来了，也可能是分页的。不过，应该都是
        直接读库的，一旦访问量大，数据库压力大是必然。
        这里不是说51cto网站不好，所有的网站都是从类似的程序架构开始发展起来的。

第四层：动态服务器层：php,java等，只有到这个层才可能会访问数据库。
         经过前三层的访问过滤能到这层访问就很少了，一般都是新发布的内容和新发布内容第一次浏览 如；博文
       （包括微博等），BBS帖子。

第五层：数据库cache层，比如：memcache,memcachedb,tc等等。

第六层：数据库层，一般的不是超大站点都会用mysql主从结构，如：163,sina,kaixin都是如此，做数据库读写分离，
         一主（或双主）多从的方式，访问大了，就拆业务好了，比如：
         再给企业做兼职时，发现类似的51cto的一个站点，把www服务,blog服务，bbs
         服务都放一个服务器上，然后做主从。这种情况，当业务访问量大了，可以简单的
         把www,blog,bbs服务分别各用一组服务器拆分开，这种方式运维都会的,没啥难度。
         当然访问量在大了，可以继续针对某一个服务拆分如：www库拆分，也可以对库里的表拆分。
         需要高可用可以通过drbd等工具做成高可用方式。对于写业务大的，可以做MYSQL REP主主的方式，
         对于ORACLE来说，来几组oracle dg就够了，玩RAC要需要更多的软、硬件价格及维护成本的，另外，一般的中高级DBA，玩好RAC也不是很容易的。
         如果到这里访问量还很大，那就恭喜了，起码是几千万以上的PV了
         当然，某些超大公司还可能用写MASTER及所谓的3个以上master环状同步,每个master在带几个SLAVE，甚至用nosql数据库。
         这些都是浮云，我们搞服务，不是看人家喊什么你就用什么，好多人网上发布的帖子只是测试的。或者不适合你的。
         网上提供的文档等，你能测试搞出来就不容易了，出问题能快速解决，这个就没法一下子学会了。而且，好多软件本来就没有大公司用过，即没有大经过大规模的高并发测试，一旦用于重要业务，出问题，后果是很严重的，这就是开源的一个弊端，没有人支持。

第七层：其实大多数公司用NFS就够了。我所维护或经历过的上千万PV的用NFS及普通服务器做存储的还有大把，
         多一些磁盘，如SAS 15K*6的，或者用dell6850，搞几组 NFS存储，中小网站足够了。
         当然可以做成drbd+heartbeat+nfs+a/a的方式，就象就象抚琴煮酒兄弟说的。
         最可气的是一个要来我这里报名学习的月薪2000块的同学，跟我说会mfs,hadoop。。。浮云啊，浮云。
         会什么没有用的。我一直在跟所有的VIP学生强调：什么叫做会？
         在我从事的linux培训教学工作中，常常要求学生，在5分钟内完成一个模拟生产环境标准的heartbeat服务的部署。
         对于运维，我的观点是，只有在有限的时间内部署完成任务并且标准规范，才算真正会了。当然，能够全面理解原
         理并能在上线后排查故障、维护、优化就更好了。我在列几个，老男孩在培训中认为学生学习的学会的时限标准。

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

以上1-7层 都搭好了，这样漏网到 第四层 动态服务器层：的访问，就不多了。一般的中等站点，绝对不会对数据库造成太大的压力。
当然特殊的业务 还需要特殊架构，来合理利用数据库和存储。

本文是在上班时间一个字一个字敲的。要被老板骂了，赶紧收活。呵呵！

(转载)