网购秒杀系统架构设计

本文是「大型网站技术架构 - 核心原理与案例分析」 第 12 章的学习笔记，感兴趣的朋友能够去购买

目录：

• 秒杀活动的技术挑战
• 秒杀活动的应对策略
• 秒杀系统架构设计

1、秒杀活动的技术挑战

场景： 某网站秒杀活动推出 1 件商品，预计吸引 10000 人参加，及最大并发请求数 10000

1.1 对现有业务的冲击

秒杀活动做为网站业务的附加活动，具备持续时间短、并发访问量大的特色。
与主业务部署相同服务器，会对现有业务形成冲击。

1.2 高并发下的应用、数据库负载

参与秒杀活动的用户，会在秒杀开始前，不断刷新浏览器。
若是按照正常访问应用服务器、链接数据库将对它们形成极大负载压力。

1.3 突增的网路及服务器带宽

假定秒杀活动页面大小 200k ，则在活动期间须要的网络和服务器带宽为 2G(200k * 10000)。这超过网站平时使用的带宽。

1.4 直接下单

秒杀活动仅能在开始活动后下单，开始前仅能浏览商品，若是用户获取到直接下单页面 URL 则能够直接下单。

2、秒杀活动应对策略

2.1 秒杀系统独立部署

a. 秒杀活动独立部署应用服务器
b. 能够独立部署域名

2.2 秒杀页面静态化

秒杀活动不使用原商品页面，而是将商品描述、商品参数、成交记录、用户评论等所有写入静态页面，这样用户访问时无需通过应用服务器及链接数据库。

2.3 租借秒杀带宽

为减轻服务器压力
a. 将秒杀活动页面缓存在 CDN
b. 从 CDN 服务商临时租借出口带宽

2.4 动态生成随机下单页面 URL

3、 秒杀系统架构设计

3.1 「购买」按钮仅在秒杀开始后可用

活动开始前及结束后「购买」按钮置灰

3.2 简化下单页面

a. 购买数量不可修改，仅能购买 1 件
b. 收货地址及付款方式仅支持用户默认设置
c. 无默认设置的收货地址用户，支持下单后补填

3.3 挑战

• 如何控制秒杀活动的「购买」按钮点亮？

缘由： 因为页面采用 CDN、反向代理及页面静态化策略。秒杀开始时用户刷新页面，请求没法到达应用服务器

解决： 使用 JavaScript 脚本控制
原理是在秒杀商品静态页面加入 JavaScript 文件引用，该 js 加入秒杀开始标志及下单页面 URL 的随机参数。
秒杀开始时生成新的 JavaScript为不见并被用户浏览器加载，打到控制秒杀页面展现的目的。

• 如何只容许第一个提交的订单被发送到订单子系统

缘由： 参与活动用户多，秒杀商品数量有限，如何去报用户提交订单式检查是否已有订单提交

解决： 控制进入下单页面入口，仅容许少数用户进入下单页面，其它用户直接进入秒杀结束页面