高并发的核心原则

其实就一句话 把所有的用户访问 尽量都往前推

如果把用户比作来犯的“敌人”，我们一定要把他们挡在800里之外的老巢（浏览器）中，不能让他们一下子打到我们的指挥部（数据库或者其他数据存储设备）

比如：

1. 能缓存在用户本地的就不要让他去访问CDN
2. 能缓存在CDN服务器的，就不要让CDN去访问 静态服务器
3. 能访问静态服务器的，就不要去访问动态服务器
4. 能访问缓存的，就不要去访问数据库

高并发网站访问的几个层次

1. 第一层：在用户浏览器端，使用apache的mod_deflate压缩传输，在比如：expires功能 deflate和expires功能利用的好，就会大大提升用户体验效果及减少网站带宽， 减少后端服务器的压力。当然，方法还有很多，这里不一一细谈了。这里的apache,还可以是Nginx,lighttpd等web服务软件。

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

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

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

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

6. 第六层：数据库层，一般的不是超大站点都会用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数据库。 这些都是浮云，我们搞服务，不是看人家喊什么你就用什么，好多人网上发布的帖子只是测试的。或者不适合你的。 网上提供的文档等，你能测试搞出来就不容易了，出问题能快速解决，这个就没法一下子学会了。而且，好多软件本来就没有大公司用过，即没有大经过大规模的高并发测试，一旦用于重要业务，出问题，后果是很严重的，这就是开源的一个弊端，没有人支持。

7. 第七层：其实大多数公司用NFS就够了。我所维护或经历过的上千万PV的用NFS及普通服务器做存储的还有大把， 多一些磁盘，如SAS 15K*6的，或者用dell6850，搞几组 NFS存储，中小网站足够了