作者:一盏烛光,贤牛特邀工程师。
成为【贤牛】工程师,按需运维,灵活用工,让运维工程师多赚一些零花钱,多一些企业级运维经验。
-
客户端:缓存(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库拆分&#