写点什么

9.5 系统性能优化案例:秒杀系统

用户头像
张荣召
关注
发布于: 2020 年 11 月 22 日

1.秒杀

       秒杀要求:高性能

       秒杀场景:在一秒钟时间内,大量的用户并发的同时请求系统,抢购有限的商品,造成性能压力。如何解决这个问题?

                        如何设计秒杀系统?有什么指导思想?思路?系统核心的优化点是什么?

       

2.*****性能现状

XXXXX 正常流量情况:

  • 并发(单台),高峰期<10;

  • 吞吐量(TPS,单台)高峰期<60

  • CPU 负载 Load 高峰期,   <2, 大部分服务器<1;

  • CPU 使用率,一般只占 1 颗核,平均 60%左右

  • 服务器平均响应时间  高峰期, <150ms

  • 图片总流量带宽 1.8G(各网站总和)

      ===>系统运行在(a,b)区

高并发下的风险:

  • 网络带宽耗尽

  • 服务器 Load 飙高,停止响应

  • 数据库瘫痪

高并发下的事故:

  • 事故:网站运营推广页面弹出 1M 大图片导致带宽耗尽

                    增加审核机制:运营推广增加的图片流量不能超过现有流量的 30%

  • 合作媒体推广:迅雷,暴风影音付出广告,导致 ZZ 集群 Crash。

      秒杀:

  • XXXX.com 开业 88 小时不间断秒杀活动。                              


3.高并发实例:X.com 开业秒杀


商业需求:

  • 为庆祝 XXXX.com 开业推出 88 小时不间断秒杀活动

  • 每小时整点推出 8 款商品。。。。。

  • 每款商品供 168 件,每人限批 3 件,成交人数 56 人

  • CCTV 黄金广告时间,各种网络,平面媒体轰炸,总广告费:1.5 亿

  • 接到运营通知,距离秒杀开始仅仅 5 天时间。

技术挑战:

  • 瞬间高并发:

                  8000 并发:预估秒杀在线人数可达 8000 人

                  风险:带宽耗尽

                  服务器:崩溃,可以理解成自己给自己的准备的 D.D.O.S 攻击

  • 秒杀器:                       

                  第一种:秒杀前不断刷新秒杀页面,知道秒杀开始,抢着下单。(机器人刷,并发量>8000)

                  第二种:跳过秒杀页面,直接进入下单页面,下单。(防止)


核心问题:高并发带来的性能压力

     1.原有并发 100,秒杀并发预估 10000,并发是原有的 100 倍,甚至更高,怎样面对这样的并发请求?

     2.如何使用户遵循秒杀规则--不跳过秒杀开始页面,阻止用户跳过秒杀页面,阻止用户直接下单?

     解析:1.扩容。扩容 100 倍,原有集群 100 台服务器,扩容 100 倍,10000 台服务器,成本急剧升高,第二只有 5 天时间,时间来不及====>现实中,直接扩容 100 倍的思路,是走不通的,也是不允许的。

               2.不再当前系统上做秒杀。单独开发秒杀系统,部署秒杀集群。秒杀系统和原有系统隔离。

               3.架构师能力:复杂业务系统中,理清头绪。复杂问题,简单化,将复杂问题分解成多个简单问题,然后逐一击破。隔离事情---隔离系统


.com秒杀系统:服务器和网络准备

      服务器准备:(距离秒杀开始仅五天时间来不及采购)

  • style 服务器(LightHttpd 集群):5 台  --CSS,JS

  • 图片服务器(Nginx 集群):5 台----------img

  • 静态服务器(Apache 集群):10 台--------

  • 交易服务器(JBoss 动态集群):10 台-----

     带宽准备

  • 图片出口带宽上限:2.5G(出口带宽支持 10G,但图片服务器集群的处理能力:图片服务器集群最大并发处理能力 X 网站平均图片大小=2.5G)

  • CDN 准备:Chinacache 沟通,借用 CCCC CDN

5.X.com秒杀系统:架构目标

     1.图片网络带宽:1.0G

               新增图片带宽:必须控制在 1.0G 左右

               每件商品秒杀页面的图片总大小不得超过:1000000/(1000*8)=125K/每商品。

     2.网站并发:

               单间商品并发:1000【来自运营的预估】

               总并发:8(件商品)*1000(人/商品)=8000 并发


6.X.com秒杀系统:组成

    简单系统:

           三个页面组成:秒杀商品列表,秒杀商品介绍,下单 .

下单成功后,进入支付系统,走支付流程

7..com秒杀系统:设计原则

静态化:

  • 采用 JS 自动更新技术奖动态页面转化为静态页面。

并发控制,防秒杀器:

  • 设置阀门,只放最前面的一部分人进入秒杀系统

简化流程:

  • 砍掉不重要的分支流程,如下单页面的所有数据库查询

  • 以下单成功作为秒杀成功标志。支付流程只要在一天内完成即可。

前端优化:

  • 采用 YSLOW 原则提升页面响应速度。     

8.X.com秒杀系统:静态化 1

      秒杀商品 list 和 Detail 是静态 HTML 页面

9.X.com秒杀系统:静态化 2

解决问题:1.控制秒杀开始;2.阻止跳过秒杀页面直接下单。     

秒杀商品列表/秒杀商品介绍页面,如何判断秒杀开始。

  • 答案:valid-offer.js---------> var valid_offerIds=3345234523,43523262,75467457,846234244,35656789

                                                          var order_url="XXX.com/oder/url.jsp"; 

                      

      JS 生成流程:

         1.访问缓存计数器,获取可拍产品 ID 列表

         2.生成 JS 文件

         3.INotify 同步 Linux  INotify 机制。检查到.js 文件变更,调用 Async 同步到 Style.XXX.com

         4.商品列表和 Detail 页面加载 JS 文件,JS 带随机版本号,不走浏览器缓存。

         5.判断秒杀是否开始。检查当前商品的 ID 是否在 js 数组中,如果不在,“购买”按钮置灰。

         6.finished。

10.X.com秒杀系统:三道阀门

      解决问题:控制流量

      阀门:基于 TT 的计数器

      1.限制进入秒杀界面,1000

      2.限制进入下单页面,100

      3.限制进入支付系统,56


10.X.com秒杀系统:秒杀器的预防

秒杀 Detail 页面:

  • URL:随机

  • 秒杀前 2 秒放出,脚本生成,秒杀前。

  • 1000 次访问上限控制[每件商品只能放入 1000 人浏览]

下单页面:

  • 订单 ID 随机。

  • 不能直接跳过秒杀 Detail 页面进入。

  • 每个秒杀商品,带预先生成的随机 Token 做 URL 参数。

  • 如果秒杀过,直接跳到秒杀结束页面。

  • 100 次访问上线控制【每件商品只能放入 1000 人下单】       

11.秒杀静态页面优化

图片合并:

  • 八张图片合成 1 张,CSS 偏移展示

  • 减少 HTTP 请求数,减少请求等待数。

  • 减少发送 Cookie 的量

HTML 内容压缩

  • 图片压缩:图片 Bytes<长*宽/2250

  • HTML header Cache-control 设置

  • CSS,JS 精简------CSS,JS 精简到极致,部分直接写在页面中,减少 HTTP 请求次数。         


用户头像

张荣召

关注

还未添加个人签名 2018.05.02 加入

还未添加个人简介

评论

发布
暂无评论
9.5系统性能优化案例:秒杀系统