站点设计高性能高并发
高性能高并发
高并发訪问的核心原则事实上就一句话“把全部的用户訪问请求都尽量往前推”。
假设把来訪用户比作来犯的"敌人",我们一定要把他们挡在800里地以外,即不能让他们的请求一下打到我们的指挥部(指挥部就是数据库及分布式存储)。
如:能缓存在用户电脑本地的,就不要让他去訪问CDN。能缓存CDNserver上的,就不要让CDN去訪问源(静态server)了。能訪问静态server的,就不要去訪问动态server。以此类推:能不訪问数据库和存储就一定不要去訪问数据库和存储。
说起来非常轻松,实际做起来却不easy,但仅仅要稍加努力是能够做到的,Google的日独立IP过亿不也做到了么?我们这几千万的PV站比起Google不是小屋见大屋了。我们还是先从我们的小屋搭起吧!哈哈!以下内容的介绍起点是千万级别的PV站,也能够支持亿级PV(page view 网页訪问量)的站点架构。
高性能高并发高可扩展站点架构訪问的几个层次:
有人会问,我们老是说把用户对业务的訪问往前推,究竟怎么推啊?推到哪呢?以下,老男孩就为大家一一道来。
第一层:首先在用户浏览器端,使用Apache的mod_deflate压缩传输,再比方:expires功能、deflate和expires功能利用的好,就会大大提升用户体验效果及降低站点带宽,降低后端server的压力。当然,方法还有非常多,这里不一一细谈了。提示:有关压缩传输及expires功能nginx/lighttpd等软件相同也有。
第二层:页面元素,如图片/js/css等或静态数据html,这个层面是网页缓存层,比方CDN(效果比公司自己部署squid/nginx要好,他们更专业,价格低廉,比方快网/CC等(价格80元/M/月甚至更低)并且覆盖的城市节点很多其它),自己架设squid/nginx cache来做小型CDN是次选(超大规模的公司可能会考虑风险问题实行自建加购买服务结合),除非是为前端的CDN提供数据源服务,以减轻后端我们的server数据及存储压力,而不是直接提供cache服务给终于用户。taobao的CDN以前由于一部分图片的次寸大而导致CDN压力大的情况,甚至对图片尺寸大的来改小,以达到减少流量及带宽的作用。
提示:我们也能够自己架设一层cache层,对我们购买的CDN提供数据源服务,可用的软件有varnish/nginx/squid 等cache,以减轻第三层静态数据层的压力。在这层的前端我们也能够架设DNSserver,来达到跨机房业务拓展及智能解析的目的。
第三层:静态server层一般为图片server,视频server,静态HTMLserver。这一层是前面缓存层和后面动态server层的连接纽带,大公司公布新闻等内容直接由公布人员分发到各cache节点(sina,163等都是如此),这和一般公司的业务可能不一样。所以,没法直接的參考模仿,比方人人的SNS。
我们能够使用Q队列方式实现异步的分发訪问,同一时候把动态公布数据(数据库中的数据)静态化存储。即放到本层訪问,或通过其它办法公布到各cache节点,而不是直接让全部用户去訪问数据库,不知道大家发现了没有,qq.com门户的新闻评论多的有几十万条,假设全部用户一看新闻就载入全部评论,那数据库不挂才怪。他们的评论须要审核(美其名约,实际是异步的方式,并且,评论可能都是静态化的或类似的静态化或内存cache的方式),这点可能就是须要51cto.com这样站点学习的,你们打开51CTO的一篇博文,就会发现以下的评论一直都显示出来了,也可能是分页的。只是,应该都是直接读库的,一旦訪问量大,数据库压力大是必定。这里不是说51cto站点不好,全部的站点都是从类似的程序架构開始发展的。CU也可能是如此。
提示:我们能够在静态数据层的前端自己架设一层cache层,对我们购买的CDN提供数据源服务,可用的软件有varnish/nginx/squid 等cache。在这层的前端我们也能够架设DNSserver,来达到跨机房业务拓展及智能解析的目的。
第四层:动态server层:php,java等,仅仅有透过了前面3层后的訪问请求才会到这个层,才可能会訪问数据库及存储设备。经过前三层的訪问过滤能到这层訪问请求一般来说已很少了,一般都是新公布的内容和新公布内容第一次浏览如;博文(包含微博等),BBS帖子。
特别提示:此层能够在程序上多做文章,比方向下訪问cache层,memcache,memcachedb,tc,mysql,oracle,在程序级别实现分布式訪问,分布式读写分离,而程序级别分布式訪问的每一个db cache节点,又能够是一组业务或者一组业务拆分开来的多台server的负载均衡。这种架构会为后面的数据库和存储层大大的降低压力,那么这里呢,相当于指挥部的外层了。
第五层:数据库cache层,比方:memcache,memcachedb,tc等等。
依据不同的业务需求,选择适合详细业务的数据库。对于memcache、memcachedb ttserver及相关nosql数据库,能够在第四层通过程序来实现对本层实现分布式訪问,每一个分布式訪问的节点都可能是一组负载均衡(数十台机器)。
第六层:数据库层,一般的不是超大网站都会用mysql主从结构,如:163,sina,kaixin都是如此,程序层做分布式数据库读写分离,一主(或双主)多从的方式,訪问大了,能够做级连的主从及环状的多主多从,然后,实现多组负载均衡,供前端的分布式程序调用,假设訪问量在大,就须要拆业务了,比方:我再给某企业做兼职时,发现类似的51cto的一个网站,把www服务,blog服务,bbs服务都放一个server上,然后做主从。这样的情况,当业务訪问量大了,能够简单的把www,blog,bbs服务分别各用一组server拆分开,这样的方式运维都会的没啥难度。当然訪问量在大了,能够继续针对某一个服务拆分如:www库拆分,每一个库做一组负载均衡,还能够对库里的表拆分。须要高可用能够通过drbd等工具做成高可用方式。对于写大的,能够做主主或多主的MYSQL REP方式,对于ORACLE来说,来几组oracle DG(1master多salve方式)就够了,11G的DG能够象mysql rep一样,支持读写分离了。当然可选的方案还有,mysql cluster 和oracle 的RAC,玩mysql cluster和oracle RAC要须要更好很多其它的硬件及部署后的大量维护成本,因此,要综合考虑,到这里訪问量还非常大,那就恭喜了,起码是几千万以上甚至上亿的PV了。
象百度等巨型公司除了会採用常规的mysql及oracle数据库库外,会在性能要求更高的领域,大量的使用nosql数据库,然后前端在加DNS,负载均衡,分布式的读写分离,最后依旧是拆业务,拆库,。。。逐步细化,然后每一个点又能够是一组或多组机器。
特别提示:数据库层的硬件好坏也会决定訪问量的多少,尤其是要考虑磁盘IO的问题,大公司往往在性价比上做文章,比方核心业务採用硬件netapp/emc及san光纤架构,对于资源数据存储,如图片视频,会採用sas或固态ssd盘,假设数据超大,能够採取热点分取分存的方法:如:最常訪问的10-20%使用ssd存储,中间的20-30%採用sas盘,最后的40-50%能够採用便宜的sata。
第七层:千万级PV的站假设设计的合理一些,1,2个NFS SERVER就足够了。我所维护(兼职)或经历过的上千万PV的用NFS及普通server做存储的还有大把,多一些磁盘,如SAS 15K*6的,或者用dell6850,搞几组 NFS存储,中小站点足够了。当然能够做成drbd+heartbeat+nfs+a/a的方式。
假设能达到本文设计要求的,中等规模站点,后端的数据库及存储压力会很小了。 象门户站点级别,如XX等, 会採用硬件netapp/emc等等硬件存储设备或是san光纤同道,甚至在性价比上做文章,比方核心业务採用硬件netapp/emc及san光纤架构,对于资源数据存储,如图片视频,会採用sas或固态ssd盘,假设数据超到,能够採取热点分取分存的方法:如:最常訪问的10-20%使用ssd存储,中间的20-30%採用sas盘,最后的40-50%能够採用便宜的sata。
象XX等巨型公司会採用hadoop等分布式的存储架构,前端在加上多层CACHE及多及的负载均衡,相同会依据业务进行拆分,比方爬虫层存储,索引层存储,服务层存储。。。能够更细更细。。。为了应付压力,什么手段都用上了。
特殊业务,如某些SNS门户站,包含门户站点的评论,微博,大多都是异步的写入方式,即不管读写,并发訪问数据库都是很少量的。
以上1-7层,假设都搭好了,这样漏网到第四层动态server层的訪问,就不多了。一般的中等网站,绝对不会对数据库造成太大的压力。程序层的分布式訪问是从千万及PV向亿级PV的发展,当然特殊的业务 还须要特殊架构,来合理利用数据库和存储。