高并发下网站架构.docx

何崚:曾先后就职于中科院下属的两家基因研究所，从事基因组测序中的算法设计和高性能运算。 2006年加入阿里巴巴B2B，此后一直就职于阿里巴巴中国站，最近在关注性能优化和服务化相关领域。 业余除了JAVA开发外，还对游戏开发和三维动画制作兴趣浓厚。 精彩文字内容 （请各位下载PPT，结合PPT看文字）何崚： 我做一个自我介绍，我叫何崚，来自中国网站技术部网站架构组，主要负责中文站架构设计，性能优化的话是我日常工作中非常重要的部分，所以我今天跟大家探讨一下这个问题。 很多同学对网站性能状况不是很了解，我讲一下基本现状，我们中国站的网站正常流量情况，现在主要的服务器，单台并发，高峰期的时候不会超过10，吞吐量在高峰期也就是10：00-11：00点钟，每一台服务器单台CPU使用率，一般只占1颗核，平均60%左右，服务器平均响应时间在高峰期一般也不会超过150毫秒，图片每天总流量带宽，就是各个网站总和不会超过1.8G。 但是在特定情况下，比如说运营推广的时候，会遇到一个高并发的情况，所谓高并发，就是很多用户在同一个时间点访问我们网站，这个时候看什么问题，首先第一个，如果这么多用户同时访问网站，那么我们的网络带宽可能在一个瞬间内耗尽，服务器Load迅速飙高，一般情况下不会超过2，推广时期经常出现几十甚至上百的现象，这样基本上就停止响应了。 高并发症德士古，比如说是旺旺弹出，过去运营在旺旺引入一个大的图片，有一兆，旺旺在瞬间弹出来以后，那1兆大图片导致带宽耗尽，那我们现在增加审核机制，运营推广增加的图片流量不能超过现有流量的30%。我们找一些合作媒体推广，比如迅雷、暴风影音浮出广告，导致旺铺集群Crash，另外是秒杀，像1688.com开业88小时不间断秒杀活动。 （第三张PPT） 这个是非常典型的高并发的情况，这是我们自己对自己的一个DEOS的攻击，我们看这三张图，反映了一个高并发对网站性能的影响，左上角是并发数对吞吐量的影响，大家看到在并发数比较小的情况下面，吞吐量是缓慢上升，但是到了其中一个点，大概120左右，这个点就是一个拐点，过了这个点以后，吞吐量迅速下降，非常快，所以我们性能优化一个很重大责任就是把拐点尽量往后推。 右边这张图是并发数对服务器平均请求响应时间的影响，这张图和左边这张图有一些不一样，在并发数小的时候，随着并发数的增长，请求平均响应时间不会有太大变化，基本上直线，但是到了拐点以后，120左右，会迅速上升，也就是服务器会越来越慢。 下面这张图是并发数对用户平均请求等待时间影响，用户平均请求等待时间基本上可以分为三部分，第一部分是网络传输时间，第二部分是服务器他的平均响应时间，第三部分是数据浏览器渲染时间的总和，这张图跟上面的平均响应时间是相似的。 右上角的图响应级是在毫秒级的，这是静态页面，因为我们现在高性能的外部服务器他们基本上对静态页面可以做到内核级别的这么一个文件复制，不需要把这个数据读到应用层，所以可能直接就是把文件读到内核缓冲区，然后直接发送到网卡数据缓冲区，不需要经过应用层，所以现在高性能外部服务器响应时间是非常恐怖的。 （第4张PPT）接下来我就讲一下我们非常典型的一个高并发事例，也就是1688.com，我们中文站打造全球最大的一个B2B平台开业推出88小时不间断秒杀活动，这是非常典型的高并发例子，当时我们运营人员购买了中央台黄金广告时间，在各大主流媒体，包括地铁站广告牌，像各大网站网络广告，他都做了很多广告投放，当时耗资在2亿左右，所以说这个活动搞的很大，当时我们每小时整点推送八款，每款总量都是168件，每人限定3件，那每个人不能多买一件，也不能少买一件，必须限定三件，商品比如说拖拉机、牛这样的东西，所以说也是挺有诱惑力的。 当时我们秒杀的拖拉机单价也有好几万，比较高质量的拖拉机，但是秒杀价就是1.68元，我们看一下挑战，首先就是一个瞬间的高并发，因为根据我们运营估计，当时运营参考了淘宝秒房子的活动，淘宝秒房子是在没有做任何广告的情况下，它的并发数达到一万，然后第一次淘宝做秒房子的时候，在秒杀开始那一瞬间，淘宝整个带宽全部被耗尽，整个秒杀活动也就结束了。 我们运营认为做那么多的广告，我们商品也很有诱惑力，他认为我们至少这个商品的并发数可以达到淘宝的1/10，在一千左右，我们有八款商品，秒杀在线人数应该会达到八千，也就是说八千个并发，给我们带来的风险带宽很有可能耗尽，第二块的话，我们从来没有做过这么大的并发，我们中国日常平均最高的并发也就是一百左右，我们很担心在那一瞬间到底是秒杀还是被秒杀，这肯定是一个问题。 第三块风险的话可能会来自于秒杀器，现在主要有两种秒杀器，第一种秒杀器在秒杀前几秒钟，会不断刷新秒杀页面，直到秒杀按钮可以点了，那迅速点下去，就完成秒杀这个动作。第二种秒杀器更狠，直接跳过秒杀页面，直接进入下单页面，填下单页面。秒杀器其实是我们高并发最大的来源，我们比较担心机器，不太担心人。 接下来就会面临一个服务器和网络的问题，运营告诉我们这个秒杀的时候，离秒杀开始只有五天时间，所有广告都已经投放出去了，五天过后肯定会进行秒杀活动的，所以我们开发这个东西也就是五天时间，我们服务器不可能走采购流程了，只能拆东墙、补西墙来搞服务器，来组建我们的秒杀活动。 （第5张PPT）我们的服务器准备，服务器准备（距秒杀开始仅五天时间来不及采购） style服务器（Lighttpd集群）：5台 图片服务器（Nginx集群） ：5台 静态服务器（Apache集群） ：10台 交易服务器（JBoss动态集群）：10台 带宽准备 图片出口带宽上限：2.5G （出口带宽支持10G，但图片服务器集群的处理能力：图片服务集群最大并发处理能力 X 网站平均图片大小 = 2.5G） CDN准备：Chinacache沟通；借用Taobao CDN （第6张PPT） 可以用于秒杀的图片网络带宽1.0G左右，我们算出来每商品页面图片大小不能超过125K。网站并发的话，网站并发： 单件商品并发：1000 【来自运营的预估】 总并发: 8（件商品）X 1000（人/商品）=8000 （第7张PPT） 我们看一下1688秒杀系统的组成，有三个页面组成，分别是秒杀商品列表、秒杀商品介绍以及下单页面。 （第8张PPT）当时我们用五天时间实现1688.com秒杀，我们从流量和并发这块去设计的，第一个是静态化页面，采用JS自动更新技术将动态页面转化为静态页面。第二块我们要去并发控制，最大的并发可能达到八千，但是我们想一些办法，把并发降下来，我们还要想一些防秒杀器的策略，我们设计一些闸门，因为秒杀商品总共有这么多件，这一千人里面，只有最前面的人能够抢到商品，我们可以设计阀门，把前面一部分人放进秒杀器，后面的人告诉他秒杀已经结束了。第三块就是简化流程，砍掉不重要的分支流程，比如说下单页面很复杂，里面会有一些数据库，把以前填过的地址全部都查出来，以下单成功作为秒杀成功标志，支付流程只要在一天内完成即可。我们在1688.com的88小时秒杀过程当中，其实我们这边DBA最轻松的。第四块是前端优化，我们采用YSLOW原则提升页面响应速度，不知道大家有没有用过雅虎有一个YSLOW浏览器插件，对页面做一些分析，去提出优化建议，比如说图片有继续压缩余地，根据这些原则去优化页面，达到最快的页面响应速度。 刚才我们说了静态化，通过js的自动更新，实现把动态页面转成静态页面，具体怎么实现，这里讲一下。 （第9张PPT） 我们把秒杀商品的List页面和Detail页面转化为静态Html页面，首先由网站运营把秒杀商品的详细信息录入到后台系统，然后BOPS系统有一个定时任务，会在秒杀开始前的几秒钟，把这两个页面刷下来生成静态页面，然后推送到1688.com前台，推送到秒杀服务器。 （第10张PPT） 秒杀商品的介绍页面，在秒杀开始的时候，会显示的按钮是灰的，显示秒杀还没有开始，在秒杀开始的时候，按钮会变亮，秒杀结束以后，告诉你商品已经秒杀结束了，它是怎么实现的，能够在静态页面里面实现的，很关键的这个页面有js文件，然后这个js文件里面放着一个我们商品的一个数据，这个数据就是当前可以被秒杀的商品，是怎么生成的，我们在交易系统里面做一个缓存，会在里面把每件商品的计数器，就是有多少商品的计数器，放在缓存的计数器里面，我们有一个脚本会定时，可能是每秒钟一次去读一下计数器，看一下当前还可以被秒杀的商品有哪些，然后把那个商品ID找出来，然后生成js文件。Inotify同步Linux Inotify机制检查到JS文件变更，调用Async同步到。 （第11张PPT） 我们可以通过阀门形式，把不可能拍到商品的人挡在系统之外，我们设计三道阀门，刚刚说的秒杀页面，就是秒杀的list页面和详情页面，放在静态集群，然后我们的下单页面是在中文站的交易系统，我们这边设计了三个阀门，第一道阀门，就是用户进入我们的秒杀页面时，也就是说可以点按钮页面的时候，最多不能超过一千个人能够访问这个页面，因为我们商品总量是168件，只有56个人能够拍到商品，我们认为一千个以后的人基本上不可能拍到秒杀商品，所以我们在这边做一个计数器，当这个计数器访问秒杀商品的这么一个页面超过一千的时候，我们就把这个秒杀页面下线了，就会跳到秒杀结束页面。 然后限制进入下单页面不超过一百人，也就是说能够点秒杀按钮的人数不超过一百，这样就限制进入我们的交易系统这么一个人数在瞬间不会超过一百人进入交易系统，最大限度保护我们的中国站交易系统。第三块是限制进入支付宝系统不超过56，也就是说提交我们的下单页面，然后进入支付宝系统，我们限制不超过56个人，因为我们中国站的秒杀系统，也把支付宝拖垮了，所以我们在这边也做一个限制。 我们秒杀结束标志是他提交定单，然后进入支付宝。 （第12张PPT） 接下来讲一下秒杀器预防，首先他预先知道秒杀Detail页面的URL是什么，我们对秒杀Detail页面，这个URL是随机的，连我们自己都不知道，会在秒杀前的2秒钟放出来，脚本随机数生成的。然后秒杀Detail页面一千人访问，不断抓秒杀Detail页面的秒杀器基本上可以拦住了，第二种秒杀器，就是进入我们的下单页面，他根本不仅如秒杀Detail页面，这个我们怎么做呢，第一点订单ID是随机的，这样他就不能够进入商品下单页面了，第二个不能直接跳过秒杀Detail页面进入，第三个是每一件秒杀商品，他都会预先生成一个随机的Token作为URL参数，通过JS会传到前台，然后点下单的时候，会把这个Token带过来，跟交易系统Token做一个对比。第四点，如果这个用户已经秒杀过，就直接跳到秒杀结束页面，他进入下单页面一次，另外对下单页面做一百次访问上限控制，基本上这么一个严格的策略，第二种直接进入下单页面被挡住。 （第13张PPT） 我们对Web server调优，对Apache的调优，这个是我从今天线上系统里面发现的，KeepAlive相关参数调优，其他参数调优 HostnameLookups 设为off， 对allowfromdomain等后的域名不进行正向和反向的dns解析 关闭cookies-log日志 打开Linux sendfile() 关闭无用的module mod_Gzip (秒杀页面，非图片html文本所占流量比重可忽略不计，zip意义不大), mod_Beacon, mod_hummock（等待反应过来，秒杀已经over了） （第14张PPT） （第15张PPT） 接下来讲一下秒杀静态页面的商品优化，分别是秒杀商品列表和秒杀商品介绍，我们把图片合并，8张图片合并成1张图片，通过CSS偏移去展示，大家知道为什么要这样做？减少请求数，这样能够减少Net解析时间，我们中文站的发送cookies的量很大，我们之前没有很好的规划，所以通过图片合并减少发送cookies的量。 第二块是对HTML内容压缩，把该去掉的空格去掉，另外是把图片压缩，这里也一个经验公式，就是图片Bytes长宽/2250。第四是HTML Header Cache-Control设置，第五点是CSS，JS 精简 CSS,JS 精简到极致，部分直接写在页面中，减少Http请求次数。 （第16张PPT） 下单页面优化，我们对数据库操作全部砍掉，原下单页面要访问8次数据库，全部看掉。秒杀流程精简 砍掉填写或选择收货地址，放在秒杀成功后填写 砍掉调用是否开通支付宝接口，秒杀首页文案提示必须开通。第三是采用内存缓存，秒杀Offer数据，支付宝相关信息、缓存。 （第17张PPT） 这里面我们看一下交易系统的性能优化，交易系统的调优目标，下单页面优化前并发是20，TPS是100，下单页面优化后并发是40，TPS是400。 第二个是关闭keep Alive，分析交易系统accesslog，用户在短时间内连续点击概率很低。第三是JVM优化 优化CMS 垃圾回收器的参数。第四是消灭 Top10 Bottlenecks Velocity参数调优 采用DBCP1.4 替换C3P0 Offer 产品参数的XML解析。 Keep Alive 对于网站应用其实用处不大，因为我们现在的页面是动静分离的，没有用户会在很尤其是F5后台数非常多的大集群，但是对于秒杀器是有用的，因为它在瞬间发起大量请求 MaxKeepAliveRequests指令限制了当启用KeepAlive时，每个连接允许的请求数量。用apache ab作压力测试的时候不应该带 -k。 （第18张PPT） 这