高并发下的网站架构

1、何崚:曾先后就职于中科院下属的两家基因研究所，从事基因组测序中的算法设 计和高性能运算。2006 年加入阿里巴巴 B2B ，此后一直就职于阿里巴巴中国站， 最近在关注 性能优化和服务化 相关领域。业余除了 JAVA 开发外，还对游戏开发和三维动画制作兴趣浓厚 精彩文字内容 （请各位下载 PPT ，结合 PPT 看文字） 何崚： 我做一个自我介绍，我叫何崚，来自中国网站技术部网站架构组，主要负责 中文站架构设计， 性能优化的话是我日常工作中非常重要的部分， 所以我今天跟 大家探讨一下这个问题。很多同学对网站性能状况不是很了解，我讲一下基本现状，我们中国站的网 站正常流量情况，现在主要的服务器，单

2、台并发，高峰期的时候不会超过10，吞吐量在高峰期也就是 10： 00-11 ：00 点钟，每一台服务器单台 CPU 使用率， 一般只占 1 颗核，平均 60% 左右，服务器平均响应时间在高峰期一般也不会超 过 150 毫秒，图片每天总流量带宽，就是各个网站总和不会超过 1.8G 。但是在特定情况下，比如说运营推广的时候，会遇到一个高并发的情况，所 谓高并发，就是很多用户在同一个时间点访问我们网站，这个时候看什么问题， 首先第一个， 如果这么多用户同时访问网站， 那么我们的网络带宽可能在一个瞬 间内耗尽，服务器 Load 迅速飙高，一般情况下不会超过 2，推广时期经常出现 几十甚至上百的现象，这

3、样基本上就停止响应了。高并发症德士古，比如说是旺旺弹出，过去运营在旺旺引入一个大的图片， 有一兆，旺旺在瞬间弹出来以后， 那 1 兆大图片导致带宽耗尽， 那我们现在增加 审核机制，运营推广增加的图片流量不能超过现有流量的 30% 。我们找一些合 作媒体推广，比如迅雷、暴风影音浮出广告， 导致旺铺集群 Crash ，另外是秒杀， 像 1688.com 开业 88 小时不间断秒杀活动。（第三张 PPT ）这个是非常典型的高并发的情况， 这是我们自己对自己的一个 DEOS 的攻击， 我们看这三张图， 反映了一个高并发对网站性能的影响， 左上角是并发数对吞吐 量的影响， 大家看到在并发数比较小的情况下

4、面， 吞吐量是缓慢上升， 但是到了 其中一个点，大概 120 左右，这个点就是一个拐点，过了这个点以后，吞吐量 迅速下降，非常快，所以我们性能优化一个很重大责任就是把拐点尽量往后推。右边这张图是并发数对服务器平均请求响应时间的影响，这张图和左边这张 图有一些不一样， 在并发数小的时候， 随着并发数的增长， 请求平均响应时间不 会有太大变化，基本上直线，但是到了拐点以后， 120 左右，会迅速上升，也就 是服务器会越来越慢。下面这张图是并发数对用户平均请求等待时间影响，用户平均请求等待时间 基本上可以分为三部分， 第一部分是网络传输时间， 第二部分是服务器他的平均 响应时间， 第三部分是数据浏览

5、器渲染时间的总和， 这张图跟上面的平均响应时 间是相似的。右上角的图响应级是在毫秒级的，这是静态页面，因为我们现在高性能的外 部服务器他们基本上对静态页面可以做到内核级别的这么一个文件复制， 不需要 把这个数据读到应用层， 所以可能直接就是把文件读到内核缓冲区， 然后直接发 送到网卡数据缓冲区， 不需要经过应用层， 所以现在高性能外部服务器响应时间 是非常恐怖的。（第 4 张 PPT ）接下来我就讲一下我们非常典型的一个高并发事例，也就是 1688.com ，我们中文站打造全球最大的一个 B2B 平台开业推出 88 小时不间断 秒杀活动， 这是非常典型的高并发例子， 当时我们运营人员购买了中央

6、台黄金广 告时间，在各大主流媒体，包括地铁站广告牌，像各大网站网络广告，他都做了 很多广告投放， 当时耗资在 2 亿左右， 所以说这个活动搞的很大， 当时我们每小 时整点推送八款，每款总量都是 168 件，每人限定 3 件，那每个人不能多买一 件，也不能少买一件，必须限定三件，商品比如说拖拉机、牛这样的东西，所以 说也是挺有诱惑力的。当时我们秒杀的拖拉机单价也有好几万，比较高质量的拖拉机，但是秒杀价 就是 1.68 元，我们看一下挑战，首先就是一个瞬间的高并发，因为根据我们运 营估计，当时运营参考了淘宝秒房子的活动， 淘宝秒房子是在没有做任何广告的 情况下， 它的并发数达到一万， 然后第一次淘

7、宝做秒房子的时候， 在秒杀开始那 一瞬间，淘宝整个带宽全部被耗尽，整个秒杀活动也就结束了。我们运营认为做那么多的广告，我们商品也很有诱惑力，他认为我们至少这 个商品的并发数可以达到淘宝的 1/10 ，在一千左右，我们有八款商品，秒杀在 线人数应该会达到八千， 也就是说八千个并发， 给我们带来的风险带宽很有可能 耗尽，第二块的话， 我们从来没有做过这么大的并发， 我们中国日常平均最高的 并发也就是一百左右， 我们很担心在那一瞬间到底是秒杀还是被秒杀， 这肯定是 一个问题。第三块风险的话可能会来自于秒杀器，现在主要有两种秒杀器，第一种秒杀 器在秒杀前几秒钟， 会不断刷新秒杀页面， 直到秒杀按钮可以

8、点了， 那迅速点下 去，就完成秒杀这个动作。第二种秒杀器更狠，直接跳过秒杀页面，直接进入下 单页面，填下单页面。秒杀器其实是我们高并发最大的来源， 我们比较担心机器， 不太担心人。接下来就会面临一个服务器和网络的问题，运营告诉我们这个秒杀的时候，离秒杀开始只有五天时间， 所有广告都已经投放出去了， 五天过后肯定会进行秒 杀活动的， 所以我们开发这个东西也就是五天时间， 我们服务器不可能走采购流 程了，只能拆东墙、补西墙来搞服务器，来组建我们的秒杀活动。（第 5 张 PPT ）我们的服务器准备，服务器准备（距秒杀开始仅五天时间来 不及采购） style 服务器（ Lighttpd 集群）：5 台

9、 图片服务器（ Nginx 集群） ： 5 台 静态服务器（ Apache 集群） ： 10 台 交易服务器（ JBoss 动态集群）：10 台 带宽准备 图片出口带宽上限： 2.5G （出口带宽支持 10G ，但图片服务器集群的处理能力： 图片服务集群最大并发处理能力 X 网站平均图片大小 = 2.5G ） CDN 准备： Chinacache 沟通；借用 Taobao CDN（第 6 张 PPT）可以用于秒杀的图片网络带宽 1.0G 左右，我们算出来每商品页面图片大小不 能超过 125K 。网站并发的话，网站并发： 单件商品并发： 1000 【来自运营的预估】 总并发 : 8（件商品） X

10、 1000 （人/商品） =8000（第 7 张 PPT ）我们看一下 1688 秒杀系统的组成，有三个页面组成，分别是秒杀商品列表、 秒杀商品介绍以及下单页面。（第 8 张 PPT ）当时我们用五天时间实现 1688.com 秒杀，我们从流量和并 发这块去设计的，第一个是静态化页面，采用 JS 自动更新技术将动态页面转化 为静态页面。 第二块我们要去并发控制， 最大的并发可能达到八千， 但是我们想 一些办法，把并发降下来，我们还要想一些防秒杀器的策略， 我们设计一些闸门， 因为秒杀商品总共有这么多件，这一千人里面，只有最前面的人能够抢到商品， 我们可以设计阀门， 把前面一部分人放进秒杀器，

11、后面的人告诉他秒杀已经结束 了。第三块就是简化流程，砍掉不重要的分支流程，比如说下单页面很复杂，里 面会有一些数据库， 把以前填过的地址全部都查出来， 以下单成功作为秒杀成功 标志，支付流程只要在一天内完成即可。我们在 1688.com 的 88 小时秒杀过程 当中，其实我们这边 DBA 最轻松的。第四块是前端优化，我们采用 YSLOW 原 则提升页面响应速度， 不知道大家有没有用过雅虎有一个 YSLOW 浏览器插件， 对页面做一些分析， 去提出优化建议， 比如说图片有继续压缩余地， 根据这些原 则去优化页面，达到最快的页面响应速度。刚才我们说了静态化，通过 js 的自动更新，实现把动态页面转

12、成静态页面， 具体怎么实现，这里讲一下。（第 9 张 PPT ）我们把秒杀商品的 List 页面和 Detail 页面转化为静态 Html 页面，首先由网站 运营把秒杀商品的详细信息录入到后台系统， 然后 BOPS 系统有一个定时任务， 会在秒杀开始前的几秒钟，把这两个页面刷下来生成静态页面，然后推送到1688.com 前台，推送到秒杀服务器。（第 10 张 PPT ） 秒杀商品的介绍页面，在秒杀开始的时候，会显示的按钮是灰的，显示秒杀 还没有开始，在秒杀开始的时候，按钮会变亮，秒杀结束以后，告诉你商品已经 秒杀结束了，它是怎么实现的， 能够在静态页面里面实现的， 很关键的这个页面 有 js

13、文件，然后这个 js 文件里面放着一个我们商品的一个数据，这个数据就是 当前可以被秒杀的商品， 是怎么生成的， 我们在交易系统里面做一个缓存， 会在 里面把每件商品的计数器，就是有多少商品的计数器，放在缓存的计数器里面， 我们有一个脚本会定时， 可能是每秒钟一次去读一下计数器， 看一下当前还可以 被秒杀的商品有哪些，然后把那个商品ID找出来，然后生成js文件。Inotify同 步 Linux Inotify 机制检查到 JS 文件变更，调用 Async 同步到 。（第 11 张 PPT ）我们可以通过阀门形式，把不可能拍到商品的人挡在系统之外，我们设计三 道阀门，

14、刚刚说的秒杀页面，就是秒杀的 list 页面和详情页面，放在静态集群， 然后我们的下单页面是在中文站的交易系统， 我们这边设计了三个阀门， 第一道 阀门，就是用户进入我们的秒杀页面时， 也就是说可以点按钮页面的时候， 最多 不能超过一千个人能够访问这个页面，因为我们商品总量是 168 件，只有 56 个 人能够拍到商品， 我们认为一千个以后的人基本上不可能拍到秒杀商品， 所以我 们在这边做一个计数器， 当这个计数器访问秒杀商品的这么一个页面超过一千的 时候，我们就把这个秒杀页面下线了，就会跳到秒杀结束页面。然后限制进入下单页面不超过一百人，也就是说能够点秒杀按钮的人数不超 过一百，这样就限制进

15、入我们的交易系统这么一个人数在瞬间不会超过一百人进 入交易系统， 最大限度保护我们的中国站交易系统。 第三块是限制进入支付宝系 统不超过 56，也就是说提交我们的下单页面，然后进入支付宝系统，我们限制 不超过 56 个人，因为我们中国站的秒杀系统，也把支付宝拖垮了，所以我们在 这边也做一个限制。 我们秒杀结束标志是他提交定单，然后进入支付宝。（第 12 张 PPT ）接下来讲一下秒杀器预防，首先他预先知道秒杀 Detail 页面的 URL 是什么， 我们对秒杀 Detail 页面，这个 URL 是随机的，连我们自己都不知道，会在秒杀 前的 2 秒钟放出来，脚本随机数生成的。然后秒杀 Detai

16、l 页面一千人访问，不 断抓秒杀 Detail 页面的秒杀器基本上可以拦住了， 第二种秒杀器， 就是进入我们 的下单页面， 他根本不仅如秒杀 Detail 页面，这个我们怎么做呢， 第一点订单 ID 是随机的，这样他就不能够进入商品下单页面了，第二个不能直接跳过秒杀 Detail 页面进入，第三个是每一件秒杀商品，他都会预先生成一个随机的 Token 作为 URL 参数，通过 JS 会传到前台，然后点下单的时候，会把这个 Token 带 过来，跟交易系统 Token 做一个对比。第四点，如果这个用户已经秒杀过，就 直接跳到秒杀结束页面， 他进入下单页面一次， 另外对下单页面做一百次访问上 限控

17、制，基本上这么一个严格的策略，第二种直接进入下单页面被挡住。第 13 张 PPT )我们对 Web server 调优，对 Apache 的调优，这个是我从今天线上系统里 面发现的， KeepAlive 相关参数调优，其他参数调优 HostnameLookups 设为 off， 对 allowfromdomain 等后的域名不进行正向和反 向的 dns 解析 关闭 cookies-log 日志 打开 Linux sendfile（） 关闭无用的 module mod_Gzip （秒杀页面，非图片 html 文本所占流量比重可忽略不计， zip 意义不大 ）, mod_Beacon, mod_h

18、ummock （等待反应过来，秒杀已经 over 了）第 14 张 PPT )（第 15 张 PPT ）接下来讲一下秒杀静态页面的商品优化，分别是秒杀商品列表和秒杀商品介 绍，我们把图片合并， 8 张图片合并成 1 张图片，通过 CSS 偏移去展示，大家 知道为什么要这样做？减少请求数， 这样能够减少 Net 解析时间， 我们中文站的 发送 cookies 的量很大， 我们之前没有很好的规划， 所以通过图片合并减少发送 cookies 的量。第二块是对 HTML 内容压缩，把该去掉的空格去掉，另外是把图片压缩，这 里也一个经验公式，就是图片Bytesv长X宽/2250。第四是 HTML Hea

19、derCache-Control 设置，第五点是 CSS ， JS 精简CSS,JS 精简到极致，部分直接写在页面中，减少 Http 请求次数。（第 16 张 PPT）下单页面优化， 我们对数据库操作全部砍掉， 原下单页面要访问 8 次数据库， 全部看掉。秒杀流程精简砍掉填写或选择收货地址，放在秒杀成功后填写 砍掉调用是否开通支付宝接口， 秒杀首页文案提示必须开通。 第三是采用内存缓 存，秒杀 Offer 数据，支付宝相关信息、缓存。（第 17 张 PPT） 这里面我们看一下交易系统的性能优化，交易系统的调优目标，下单页面优 化前并发是 20， TPS 是 100，下单页面优化后并发是 40，

20、 TPS 是 400。第二个是关闭 keep Alive ，分析交易系统 accesslog ，用户在短时间内连续 点击概率很低。第三是 JVM 优化优化 CMS 垃圾回收器的参数。第四是消灭 Top10 BottlenecksVelocity 参数调优采用 DBCP1.4 替换 C3P0Offer 产品参数的 XML 解析。Keep Alive 对于网站应用其实用处不大，因为我们现在的页面是动静分离的， 没有用户会在很尤其是 F5 后台数非常多的大集群，但是对于秒杀器是有用的，因为它在瞬间发起大量请求MaxKeepAliveRequests 指令限制了当启用 KeepAlive 时，每个连接允许的请求 数量。用 apache ab 作压力测试的时候不应该带