> 酒肉穿肠过的博客详情
&浅谈千万级PV/IP规模高性能高并发网站架构
原创作品，允许转载，转载时请务必以超链接形式标明文章&
&、作者信息和本声明。否则将追究法律责任。
原创作者：老男孩linux实战运维培训机构&老男孩 QQ： && 说明：几个月前老男孩发过一次类似的文章，本次为了参加一个朋友邀请的活动，稍微完善了一下，欢迎各位同仁一起交流网站架构技术。
文章架构简图：
高并发访问的核心原则其实就一句话“把所有的用户访问请求都尽量往前推”。
&&&&如果把来访用户比作来犯的"敌人"，我们一定要把他们挡在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节点，而不是直接让所有用户去访问数据库，不知道大家发现了没有，<门户的新闻评论多的有几十万条，如果所有用户一看新闻就加载所有评论，那数据库不挂才怪。他们的评论需要审核（美其名约，实际是异步的方式，而且，评论可能都是静态化的或类似的静态化或内存cache的方式），这点可能就是需要<这样站点学习的，你们打开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的方式。
&&&&如果能达到本文设计要求的，中等规模网站，后端的数据库及存储压力会非常小了。&象门户网站级别，如XX等， 会采用硬件netapp/emc等等硬件存储设备或是san光纤同道，甚至在性价比上做文章，比如核心业务采用硬件netapp/emc及san光纤架构，对于资源数据存储，如图片视频，会采用sas或固态ssd盘，如果数据超到，可以采取热点分取分存的方法：如：最常访问的10-20%使用ssd存储，中间的20-30%采用sas盘，最后的40-50%可以采用廉价的sata。
&&&&象XX等巨型公司会采用hadoop等分布式的存储架构，前端在加上多层CACHE及多及的负载均衡，同样会根据业务进行拆分，比如爬虫层存储，索引层存储，服务层存储。。。可以更细更细。。。为了应付压力，什么手段都用上了。
&&&&特殊业务，如某些SNS门户站，包括门户网站的评论，微博，大多都是异步的写入方式，即无论读写，并发访问数据库都是非常少量的。
&&&&以上1-7层，如果都搭好了，这样漏网到第四层动态服务器层的访问，就不多了。一般的中等站点，绝对不会对数据库造成太大的压力。程序层的分布式访问是从千万及PV向亿级PV的发展，当然特殊的业务 还需要特殊架构，来合理利用数据库和存储。
&&&&老男孩，资深unix/Linux系统运维网站架构专家、高级运维总监。从事一线网站运维及系统架构管理10年以上，13年的教育教学培训经历(擅长教育心理，职业规划，性格分析、谈判，职场，就业)。并将自身的网站运维架构及教育领域的经验成功结合应用到IT教育领域教学工作中。曾前后就职于若干个大规模高并发访问量的行业门户网站，并为多家互联网公司做过技术顾问，企业技术培训。提供各类网站系统架构解决方案。
&&&&老男孩linux实战培训中心是老男孩于2007年开办的国内首个linux运维实战培训私塾式精英教育培训机构。截止到2012年，累计受益学生达到千余人（其中培训VIP面授学生数百人，网络班学生数百人）。全科毕业学生平均就业工资7000以上，其中部分学生就职于淘宝、阿里巴巴、百度、腾讯、和讯、开心网、人人、激动网、小米科技、土豆、酷六、sohu、sina、金山、尚德，欢聚网、蓝港，chinacache,快网、帝联，遨游、赶集、拉手网，窝窝团、就业工场、联通、电信、乐视、乐淘、启明星辰，寻医问药，高德，360等公司。
其他活动： 1）曾为《构建高可用Linux服务器》一书做首序！ 2）曾多次受邀参加51cto,CU,it168技术活动（因兼职及培训、写书，部分未参加）。
老男孩目前从事工作： 1)&老男孩linux运维实战培训机构精英办学（面试通过方可入学）。 2）提供企业技术培训及技术顾问服务。 3）提供各种网站系统架构（数据库）解决方案。 4）提供linux技术方向企业雇员双向猎头、HR。 5）提供优质linux运维原创系列视频（初级，中级，高级）。 6）Linux网站运维从初级到高级架构的书籍写作工作。
联系方式： 网名：老男孩 QQ号:（顾问咨询）& 信箱:
培训咨询: 咨询：QQ: 33741 电话：
个人博客： （2011年度十大杰出IT博客）
个人微博： （运维思想分享地）
QQ群： 老男孩培训交流群&&246017 网站运维交流群：&518 19852 网站运维经理交流群&（非经理级别莫入）
代表作品： 老男孩浅谈如何看待运维？ 老男孩在创业及培训中28条感悟语录分享！ 批量分发管理3种简单、易用的解决方案案例视频分享& 浅谈千万级PV/IP规模高性能高并发网站架构& 老男孩linux培训某节课前考试试题及答案分享& 老男孩之学好运维四要素“坚持”的启示分享& 学会感恩会使你回报的更多--老男孩& 一道实用linux运维问题的9种shell解答方法！ Linux系统基础网络配置老鸟精华篇&
本文出自 “” 博客，请务必保留此出处
人打赏支持
码字总数 78332
支付宝支付
微信扫码支付
打赏金额: ￥
已支付成功
打赏金额: ￥
& 开源中国(OSChina.NET) |
开源中国社区(OSChina.net)是工信部
指定的官方社区9449人阅读
假想思索（3）
你想建设一个能承受500万PV/每天的网站吗？ 500万PV是什么概念？服务器每秒要处理多少个请求才能应对？如果计算呢？&
PV是什么：
PV是page view的简写。PV是指页面的访问次数，每打开或刷新一次页面，就算做一个pv。
计算模型：
每台服务器每秒处理请求的数量=((80%*总PV量)/(24小时*60分*60秒*40%)) / 服务器数量 。
其中关键的参数是80%、40%。表示一天中有80%的请求发生在一天的40%的时间内。24小时的40%是9.6小时，有80%的请求发生一天的9.6个小时当中（很适合互联网的应用，白天请求多，晚上请求少）。
简单计算的结果：
((80%*500万)/(24小时*60分*60秒*40%))/1 = 115.7个请求/秒
((80%*100万)/(24小时*60分*60秒*40%))/1 = 23.1个请求/秒
初步结论：
现在我们在做压力测试时，就有了标准，如果你的服务器一秒能处理115.7个请求，就可以承受500万PV/每天。如果你的服务器一秒能处理23.1个请求，就可以承受100万PV/每天。
留足余量：
以上请求数量是均匀的分布在白天的9.6个小时中，但实际情况并不会这么均匀的分布，会有高峰有低谷。为了应对高峰时段，应该留一些余地，最少也要x2倍，x3倍也不为过。
115.7个请求/秒&*2倍=231.4个请求/秒
115.7个请求/秒&*3倍=347.1个请求/秒
23.1个请求/秒&*2倍=46.2个请求/秒
23.1个请求/秒&*3倍=69.3个请求/秒
最终结论：
如果你的服务器一秒能处理231.4--347.1个请求/秒，就可以应对平均500万PV/每天。
如果你的服务器一秒能处理46.2--69.3个请求，就可以应对平均100万PV/每天。
这里说明每秒N个请求，就是QPS。因为我关心的是应用程序处理业务的能力。&
实际经验：
1、根据实际经验，采用两台常规配置的机架式服务器，配置是很常见的配置，例如一个4核CPU&#43;4G内存&#43;服务器SAS硬盘。
2、个人武断的认为在服务器CPU领域Intel的CPU要优于AMD的CPU，有反对的就反对吧，我都说我武断了（请看），不要太相信AMD的广告，比较CPU性能简单办法就是比价&#26684;，不要比频率与核心数，价&#26684;相差不多的性能也相差不多。
3、硬盘的性能很重要，由其是数据库服务器。一般的服务器都配1.5万转的SAS硬盘，高级一点的可以配SSD固态硬盘，性能会更好。最最最最重要的指标是“随机读写性能”而不是“顺序读写性能”。（本例还是配置最常见的1.5万转的SAS硬盘吧）
4、一台服务器跑Tomcat运行j2ee程序,一台服务器跑MySql数据库,程序写的中等水平(这个真的不好量化)，是论坛类型的应用(总有回帖,不太容易做缓存,也无法静态化)。
5、以上软硬件情况下，是可以承受100万PV/每天的。(已留有余量应对突然的访问高峰)
注意机房的网络带宽：
有人说以上条件我都满足了，但实际性能还是达不到目标。这时请注意你对外的网络的带宽，在国内服务器便宜但带宽很贵，很可能你在机房是与大家共享一条100M的光纤，实际每个人可分到2M左右带宽。再好一点5M,再好一点双线机房10M独享，这已经很贵了（北京价&#26684;）。
一天总流量：每个页面20k字节*100万个页面/M字节=19G字节，
1小时=2034M/小时=578K字节/s & 如果请求是均匀分布的，需要5M（640K字节）带宽（5Mb=640KB
注意大小写，b是位，B是字节，差了8倍），但所有请求不可能是均匀分布的，当有高峰时5M带宽一定不够，X2倍就是10M带宽。10M带宽基本可以满足要求。
以上是假设每个页面20k字节，基本不包含图片，要是包含图片就更大了，10M带宽也不能满足要求了。你自已计算吧。
（全文完）
附：性能测试基本概念
---------------------------------------------------------------------------------------
基本概念：
Throughput（吞吐量）：按照常规理解网络吞吐量表示在单位时间内通过网卡数据量之和，其中即包括本机网卡发送出去的数据量也包括本机网卡接收到的数据量。 一个100Mb(位)的双工网卡，最大发送数据的速度是12.5M字节/s ，
最大接收数据的速度是12.5M字节/s，
收发 数据。
并发用户数：是同时执行操作的用户(线程数)。
响应时间：从请求发出到收到响应花费的时间 。
QPS - Queries Per Second& 每秒处理的查询数（如果是数据库，就相当于读取）
TPS - Transactions Per Second& 每秒处理的事务数(如果是数据库，就相当于写入、修改)
IOPS，每秒磁盘进行的I/O操作次数
例如对某个数据库测试，分开两次测QPS与TPS。
QPS（读取）&#20540;总是高于TPS(写、改)，并且有倍率关系，因为：
1、数据库对查询可能有缓存。
2、机械硬盘或SSD硬盘的读就是比写快。
---------------------------------------------------------------------------------------
JMeter测试参数说明：
Label：每一个测试单元的名字。
#Samples：表示一个测试单元一共发出了多少个请求。
Average：平均响应时间——默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，也可以以Transaction 为单位显示平均响应时间。，不重要。
Median：中位数，也就是 50％ 用户的响应时间，如果把响应时间从小到大顺序排序，那么50％的请求的响应时间在这个范围之内。重要。
90% Line：90％ 用户的响应时间，如果把响应时间从小到大顺序排序，那么90％的请求的响应时间在这个范围之内。重要 。
Min：最小响应时间，不重要。
Max：最大响应时间，出现几率只不过是千分之一甚至万分之一，不重要。
Error%：本次测试中出现错误的请求的数量
Throughput：吞吐量——默认情况下表示每秒完成的请求数（Request per Second），当使用了 Transaction Controller 时，也可以表示类&#20284; LoadRunner 的 Transaction per Second 数
KB/Sec：每秒从服务器端接收 到的数据量(只是接收)，相当于LoadRunner中的Throughput/Sec
---------------------------------------------------------------------------------------
loadrunner测试参数说明：
响应时间： 取90%&#20540;，如果把响应时间从小到大顺序排序，那么90％的请求的响应时间在这个范围之内。重要。
每秒点击数 ：hits per Second,每秒钟向服务器提交请求的数量。
TPS： Transaction per Second ，每秒事务数，一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程
Throughput（吞吐量）： Loadrunner记录的Throughput是接收到服务器返回的所有字节数之和，与本地发出的字节数无关。
Throughput/Sec： 每秒的吞吐量。
对于BS架构的一般分析 响应时间、点击率、吞吐量、TPS（每秒事务数）。
对于CS架构的一般分析 TPS（每秒事务数）
---------------------------------------------------------------------------------------
Apache ab测试参数说明：
RPS： Request per Second,每秒处理的请求数
http://blog.chinaunix.net/u3/108043/showart_2260477.html
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：474577次
积分：3899
积分：3899
排名：第6133名
原创：90篇
转载：15篇
评论：78条
(1)(1)(7)(4)(1)(1)(1)(2)(20)(25)(31)(9)(2)问题补充&&
本页链接：
猜你感兴趣公司里配两台服务器，20万左右一台，大家有没有什么好的建议_显卡吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：2,089,904贴子：
公司里配两台服务器，20万左右一台，大家有没有什么好的建议收藏
和戴尔客服咨询了一下， poweredge R920cpu 四路 E7 8857 v2 内存16条16G硬盘 5块15000转 600G机械硬盘电源4块 1100W的报价19万8卡基们看这配置有什么优化没，主要是对CPU主频要求比较高，其次核心数要尽量多除了DELL有没有其他比较好的牌子推荐，主要是稳定性要求高
报考一级消防师要求,学尔森13年考培经验为您解答,更有百度信贷分期付学费.
超微（AMD）、HP、DIY、华硕、美帝良心
power8 和E7比，单核心差距怎么样，主要还是比较关心单核心性能，有了解的么，刚咨询了下IBM，power8最低配置的就在20万左右，是不是非常贵
那加几块计算卡怎么样
你去打电话质询一下
登录百度帐号推荐应用
为兴趣而生，贴吧更懂你。或