9.5 系统性能优化案例：秒杀系统
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 加入
还未添加个人简介
评论