浅谈千万级PV/IP
规模高性能高并发网站架构
高并发访问的核心原则其实就一句话“把所有的用户访问请求都尽量往前推”。
如果把来访用户比作来犯的"
敌人"
,我们一定要把他们挡在800
里地以外,即不能让他们的请求一下打到我们的指挥部(指挥部就是数据库及分布式存储)。
如:能缓存在用户电脑本地的,就不要让他去访问CDN
。 能缓存CDN
服务器上的,就不要让CDN
去访问源(静态服务器)了。能访问静态服务器的,就不要去访问动态服务器。以此类推:能不访问数据库和存储就一定不要去访问数据库和存储。
说起来很轻松,实际做起来却不容易,但只要稍加努力是可以做到的,Google
的日独立IP
过亿不也做到了么?我们这几千万的PV
站比起Google
不是小屋见大屋了。我们还是先从我们的小屋搭起吧!哈哈!下面内容的介绍起点是千万级别的PV
站,也可以支持亿级PV
的网站架构。
高性能高并发高可扩展网站架构访问的几个层次:
有人会问,我们老是说把用户对业务的访问往前推,到底怎么推啊?推到哪呢?下面,老男孩就为大家一一道来。
第一层:
首先在用户浏览器端,使用Apache
的mod_deflate
压缩传输,再比如:expires
功能、deflate
和expires
功能利用的好,就会大大提升用户体验效果及减少网站带宽,减少后端服务器的压力。当然,方法还有很多,这里不一一细谈了。
提示:有关压缩传输及expires
功能nginx/lighttpd
等软件同样也有。
第二层:
页面元素,如图片/js/css
等或静态数据html
,这个层面是网页缓存层,
比如CDN
(效果比公司自己部署squid/nginx
要好,他们更专业,价格低廉,比如快网/CC
等(价格80
元/M/
月甚至更低)而且覆盖的城市节点更多),自己架设squid/nginx cache
来做小型CDN
是次选(
超大规模的公司可能会考虑风险问题实行自建加购买服务结合)
,除非是为前端的CDN
提供数据源服务,以减轻后端我们的服务器数据及存储压力,而不是直接提供cache
服务给最终用户。taobao
的CDN
曾经因为一部分图片的次寸大而导致CDN
压力大的情况,甚至对图片尺寸大的来改小,以达到降低流量及带宽的作用。
提示:我们也可以自己架设一层cache
层,对我们购买的CDN
提供数据源服务,可用的软件有varnish/nginx/squid
等cache
,以减轻第三层静态数据层的压力。在这层的前端我们也可以架设DNS
服务器,来达到跨机房业务拓展及智能解析的目的。
第三层:
静态服务器层一般为图片服务器,视频服务器,静态HTML
服务器。这一层是前面缓存层和后面动态服务器层的连接纽带,大公司发布新闻等内容直接由发布人员分发到各cache
节点(sina,163
等都是如此),这和一般公司的业务可能不一样。所以,没法直接的参考模仿,比如人人的SNS
。
我们可以使用Q
队列方式实现异步的分发访问,同时把动态发布数据(数据库中的数据)静态化存储。即放到本层访问,或通过其他办法发布到各cache
节点,而不是直接让所有用户去访问数据库,不知道大家发现了没有,qq.com
门户的新闻评论多的有几十万条,如果所有用户一看新闻就加载所有评论,那数据库不挂才怪。他们的评论需要审核(美其名约,实际是异步的方式,而且,评论可能都是静态化的或类似的静态化或内存cache
的方式),这点可能就是需要51cto.com
这样站点学习的,你们打开51CTO
的一篇博文,就会发现下面的评论一直都显示出来了,也可能是分页的。不过,应该都是直接读库的,一旦访问量大,数据库压力大是必然。这里不是说51cto
网站不好,所有的网站都是从类似的程序架构开始发展的。CU也可能是如此。
提示:我们可以在静态数据层的前端自己架设一层cache
层,对我们购买的CDN
提供数据源服务,可用的软件有varnish/nginx/squid
等cache
。在这层的前端我们也可以架设DNS
服务器,来达到跨机房业务拓展及智能解析的目的。
第四层:
动态服务器层:php,java
等,只有透过了前面3
层后的访问请求才会到这个层,才可能会访问数据库及存储设备。经过前三层的访问过滤能到这层访问请求一般来说已非常少了,一般都是新发布的内容和新发布内容第一次浏览如;博文(包括微博等),BBS
帖子。
特别提示:此层可以在程序上多做文章,比如向下访问cache
层,memcache,memcachedb,tc,mysql,oracle
,在程序级别实现分布式访问,分布式读写分离,而程序级别分布式访问的每个db cache
节点,又可以是一组业务或者一组业务拆分开来的多台服务器的负载均衡。这样的架构会为后面的数据库和存储层大大的减少压力,那么这里呢,相当于指挥部的外层了。
第五层:
数据库cache
层,比如:memcache,memcachedb,tc
等等。
根据不同的业务需求,选择适合具体业务的数据库。对于memcache
、memcachedb ttserver
及相关nosql
数据库,可以在第四层通过程序来实现对本层实现分布式访问,每个分布式访问的节点都可能是一组负载均衡(数十台机器)。
第六层:
数据库层,一般的不是超大站点都会用mysql
主从结构,如:163,sina,kaixin
都是如此,程序层做分布式数据库读写分离,一主(或双主)多从的方式,访问大了,可以做级连的主从及环状的多主多从,然后,实现多组负载均衡,供前端的分布式程序调用,如果访问量在大,就需要拆业务了,比如:我再给某企业做兼职时,发现类似的51cto
的一个站点,把www
服务,blog
服务,bbs
服务都放一个服务器上,然后做主从。这种情况,当业务访问量大了,可以简单的把www,blog,bbs
服务分别各用一组服务器拆分开,这种方式运维都会的没啥难度。当然访问量在大了,可以继续针对某一个服务拆分如: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
及普通服务器做存储的还有大把,多一些磁盘,如SAS 15K*6
的,或者用dell6850
,搞几组 NFS
存储,中小网站足够了。当然可以做成drbd+heartbeat+nfs+a/a
的方式。
如果能达到本文设计要求的,中等规模网站,后端的数据库及存储压力会非常小了。
象门户网站级别,如sina
等, 会采用硬件netapp/emc
等等硬件存储设备或是san
光纤同道,甚至
在性价比上做文章,比如核心业务采用硬件netapp/emc
及san
光纤架构,对于资源数据存储,如图片视频,会采用sas
或固态ssd
盘,如果数据超到,可以采取热点分取分存的方法:如:最常访问的10-20%
使用ssd
存储,中间的20-30%
采用sas
盘,最后的40-50%
可以采用廉价的sata
。
象百度等巨型公司会采用hadoop
等分布式的存储架构,前端在加上多层CACHE
及多及的负载均衡,同样会根据业务进行拆分,比如爬虫层存储,索引层存储,服务层存储。。。可以更细更细。。。为了应付压力,什么手段都用上了。
特殊业务,如人人,开心网,包括门户网站的评论,微博,大多都是异步的写入方式,即无论读写,并发访问数据库都是非常少量的。
以上1-7
层,如果都搭好了,这样漏网到第四层动态服务器层的访问,就不多了。一般的中等站点,绝对不会对数据库造成太大的压力。程序层的分布式访问是从千万及PV
向亿级PV
的发展,当然特殊的业务 还需要特殊架构,来合理利用数据库和存储。
分享到:
相关推荐
一例千万级pv高性能高并发网站架构图,包括CDN、全局负载均衡、本地负载均衡、内网DNS、集群、Hadoop集群、数据库集群、缓存集群、NOSQL集群等
亿级 pv 网站架构的技术细节与套路
藏经阁-亿级 PV网站架构实战之性能压榨.pdf
2、亿级pv网站架构实战之性能压榨 3、做一名优秀的工程师入门篇 4、后端多元化之快速切入Java开发 5、如何在面试中脱颖而出 6、零基础构建自己的服务治理框架(上) 7、零基础构建自己的服务治理框架(下)
Nginx: PV、UV、独立IP 做网站的都知道,平常经常要查询下网站PV、UV等网站的访问数据,当然如果网站做了CDN的话,nginx本地的日志就没什么意义了,下面就对nginx网站的日志访问数据做下统计; 概念: UV(Unique ...
屌丝程序员如何打造日PV百万的网站架构
教你搭建日PV千万级的网站集群架构-绝对的极品教程.zip 阿里P8架构师谈 苏宁六年企业IT架构的演进之路 大并发大型网站架构设计 大型网站架构演化 大型分布式网站架构技术总结 Nginx负载均衡4种策略
通常老板花钱请我们架构网站的时候,会给我们提出一些目标,诸如网站每天要能承受100 万PV 的访问量等等。这时我们要预算一下大概需要多大的带宽,计算带宽大小主要涉及两个指标(峰值流量和页面大小),我们不妨在...
详细描述了互联网网站架构的演变历史,梳理了各种技术的引入时机、原因
高并发(High Concurrency)是互联网分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计保证系统能够同时并行处理很多请求。 高并发相关常用的一些指标有响应时间(Response Time),吞吐量...
Hybrid PV-wind generation shows higher availability as compared to PV or wind alone. For rural electrifications, researches are focused on hybrid power system which provides sustainable power. The ...
电商双十一稳定架构 LAMP架构到1000万PV的适用
太阳能PV_T系统电热输出性能及其Matlab仿真研究.pdf
质量流量和体积冷却对水型PV / T收集器性能的实验影响
也谈架构:百万pv项目与虚拟化
舍得网支撑1亿pv/天构架,开源了 说是支持1亿pv/天,也许有点夸张,也是为了吸引您能点进来,如果您能认真看完相信也不会让您失望,当然,肯定有很多“高手”会对此会嗤之以鼻,没关系,有很多眼高手低的人总喜欢...
MPPT with single DC-DC converter and inverter for grid connected hybrid wind-driven PMSG-PV system
L001-高级架构师12期-zabbix深度实践-13节 L002-高级架构师12期-zabbix深度实践2-2节 L003-高级架构师12期-SaltStack深度...L013-高级架构师-2016最新亿级PV大型电商网站架构综合详解 L014-高级架构师-架构师DNS实战
风光互补最优运行的电力系统程序,可以确定风机、PV组件和蓄电池的最优组合