惊！一个千万级 PV 规模高性能高并发网站架构

作者：一盏烛光，贤牛特邀工程师。

成为【贤牛】工程师，按需运维，灵活用工，让运维工程师多赚一些零花钱，多一些企业级运维经验。

• 客户端：缓存（expires）、deflate 压缩

• 缓存服务器：CDN/cache 缓存静态内容如：html、jpg、gif、js 等

• 静态web服务器：Apache/Nginx 静态服务器提供 html 页面内容

• php/java服务器：PHP/JAVA 动态内容

• 数据库缓存服务器：数据库缓存 memcache/redis

• 数据库服务器：MYSQL 数据库

• 数据存储：NFS/HADOOP 等

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

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

如：能缓存在用户电脑本地的，就不要让他去访问CDN/cache。能缓存CDN/cache服务器上的，就不要让CDN/cache去访问源（静态web服务器）了。

能访问静态web服务器的，就不要去访问动态服务器。以此类推：能不访问数据库和存储就一定不要去访问数据库和存储。

高性能高并发高可扩展网站架构访问的几个层次：

• 第一层：首先在用户浏览器端，使用Apache的mod_deflate压缩传输，再比如：expires功能,deflate和expires功能利用的好，就会大大提升用户体验效果及减少网站带宽，减少后端服务器的压力。

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

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

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

• 第三层：静态服务器层一般为图片服务器，视频服务器，静态HTML服务器。这一层是前面缓存层和后面动态服务器层的连接纽带。

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

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

• 第五层：数据库cache层，比如：memcache,redis等等。
  根据不同的业务需求，选择适合具体业务的数据库。对于memcache、redis，可以在第四层通过程序来实现对本层实现分布式访问，每个分布式访问的节点都可能是一组负载均衡（数十台机器）。

• 第六层：数据库层，一般的不是超大站点都会用mysql主从结构，程序层做分布式数据库读写分离，一主（或双主）多从的方式，访问大了，可以做级连的主从及环状的多主多从，然后，实现多组负载均衡，供前端的分布式程序调用，如果访问量再大，就需要拆业务了，比如：分司把www服务,blog服务，bbs服务都放一个服务器上，然后做主从。这种情况，当业务访问量大了，可以简单的把www,blog,bbs服务分别各用一组服务器拆分开。当然访问量再大了，可以继续针对某一个服务拆分如：www库拆分，每个库做一组负载均衡，还可以对库里的表拆分。需要高可用可以通过MHA等工具做成高可用方式。对于写大的，可以做主主或多主的MYSQL REP方式。

  像百度等巨型公司除了会采用常规的mysql及oracle