本文是「
大型网站技术架构 – 核心原理与案例分析
」 第 12 章的学习笔记，感兴趣的朋友可以去购买
目录：
- 秒杀活动的技术挑战
- 秒杀活动的应对策略
- 秒杀系统架构设计
一、秒杀活动的技术挑战
场景： 某网站秒杀活动推出 1 件商品，预计吸引 10000 人参加，及最大并发请求数 10000
1.1 对现有业务的冲击
秒杀活动作为网站业务的附加活动，具有持续时间短、并发访问量大的特点。
与主业务部署相同服务器，会对现有业务造成冲击。
1.2 高并发下的应用、数据库负载
参与秒杀活动的用户，会在秒杀开始前，不断刷新浏览器。
如果按照正常访问应用服务器、连接数据库将对它们造成极大负载压力。
1.3 突增的网路及服务器带宽
假定秒杀活动页面大小 200k ，则在活动期间需要的网络和服务器带宽为 2G(200k * 10000)。这超过网站平时使用的带宽。
1.4 直接下单
秒杀活动仅能在开始活动后下单，开始前仅能浏览商品，如果用户获取到直接下单页面 URL 则可以直接下单。
二、秒杀活动应对策略
2.1 秒杀系统独立部署
a. 秒杀活动独立部署应用服务器
b. 可以独立部署域名
2.2 秒杀页面静态化
秒杀活动不使用原商品页面，而是将商品描述、商品参数、成交记录、用户评论等全部写入静态页面，这样用户访问时无需经过应用服务器及连接数据库。
2.3 租借秒杀带宽
为减轻服务器压力
a. 将秒杀活动页面缓存在 CDN
b. 从 CDN 服务商临时租借出口带宽
2.4 动态生成随机下单页面 URL
三、 秒杀系统架构设计
3.1 「购买」按钮仅在秒杀开始后可用
活动开始前及结束后「购买」按钮置灰
3.2 简化下单页面
a. 购买数量不可修改，仅能购买 1 件
b. 收货地址及付款方式仅支持用户默认设置
c. 无默认设置的收货地址用户，支持下单后补填
3.3 挑战
- 如何控制秒杀活动的「购买」按钮点亮？
原因： 由于页面采用 CDN、反向代理及页面静态化策略。秒杀开始时用户刷新页面，请求无法到达应用服务器
解决： 使用 JavaScript 脚本控制
原理是在秒杀商品静态页面加入 JavaScript 文件引用，该 js 加入秒杀开始标志及下单页面 URL 的随机参数。
秒杀开始时生成新的 JavaScript为不见并被用户浏览器加载，打到控制秒杀页面展示的目的。
- 如何只允许第一个提交的订单被发送到订单子系统
原因： 参与活动用户多，秒杀商品数量有限，如何去报用户提交订单式检查是否已有订单提交
解决： 控制进入下单页面入口，仅允许少数用户进入下单页面，
其它用户直接进入秒杀结束页面