架构师 0 期 | 秒杀系统面临的问题和挑战

设计一个秒杀系统，主要的挑战和问题有哪些？核心的架构方案或者思路有哪些？



啥是秒杀？

秒杀最早起源日本的综合格斗技团体Pancrase在1993年9月21日发行的WEEKLY PRO-WRESTLING杂志中出现的自创词，在2000年发行的一款回合制网络游戏【石器时代】传入中国并被发扬光大。



【石器时代】在战斗时会出现【合击】现象，就算大家敏捷素质不同，在倒计时28秒时，同时选择攻击一个目标，也会极大概率发动攻击群殴一个目标。特别是在玩家的PK战，经常出现群体合击或者人宠合击，造成强大的杀伤，瞬间打飞或者打晕对手。



由于游戏战斗采用的是倒计时模式，强大的杀伤往往只在一秒没过就结束，所以这类瞬间或几下击败对手就被称作：【秒杀】。



后来就慢慢被商家用于促销活动。

就是卖家发布一些超低价格的商品，吸引大量买家同一时间进行抢购的销售方式。

由于价格过于低廉，往往刚上架，就瞬间卖光，甚至不到一秒钟，所以就叫秒杀。



秒杀的特点

1. 并发量大，持续时间短。瞬间高并发。这会造成过后服务器会用不着这么多的情景。

2. 只用到少数服务及页面。

3. 安全要求高，由于价格低，很容易被刷单。自己给自己挖的DDoS攻击。



秒杀的挑战

1. 瞬间的高并发，可能会对现有服务造成影响，甚至全面崩溃。

2. 激增的网络带宽使用，导致网络带宽耗尽。

3. 会存在黑客攻击，绕过验证等，直接下单，提前把东西秒走。



秒杀的解决思路

1. 独立部署系统，使用独立域名，和老系统隔离。万一有问题，能隔离在可控范围内。

2. 准备万能报错页面，商品已秒杀完。出错则302重定向到此页面。

3. 将参加秒杀的商品提前全部缓存在内存中，直接读取，不是从数据库中读取。

4. 砍掉所有跟数据库相关的操作，比如支付、填写收货地址等操作，放到秒杀成功之后再操作。

5. 使用CND服务，把商品缓存在CND。

6. 商品详情页中，有个唯一需要更新的js文件，返回可以秒杀的商品id，如果有，则对应的下单按钮可点击。

7. 下单页面的URL，在可秒杀的前2秒使用脚本自动生成，通过js文件返回给前端。防止被攻击。



设计原则

1. 静态化，采用JS自动更新技术将动态页面转化为静态页面。为运营同事提供上传工具，自动转换页面。

2. 并发控制，设置阀门，只放最前面的一部分进入秒杀系统。

3. 简化流程，把不重要的分支流程都砍掉，各种数据库查询操作都砍掉。必要的存放到内存中。以下单成功为秒杀成功标志，支付流程后面慢慢处理。

4. 前端优化，Yslow原则调优。减少Http的请求，合并JS、CSS、图片，利用浏览器缓存。图片压缩，前端解压缩。



设计方案

静态化

1. 商品列表和秒杀页面使用静态页面。

2. 静态页面如何判断秒杀已经开始了。使用js文件更新能秒杀的商品ID列表。

并发控制（阀门）

1. 限制进入秒杀页面（1000人）

2. 限制进入下单页面（100人）

3. 限制进入支付系统（50人）



防秒杀外挂

秒杀页面

1. URL随机生成

2. 秒杀前2秒才放出来，使用脚本生成。无法提前攻击

3. 限制访问人数，使用计数器，够1000人，其他人访问的都统一302到秒杀完成界面。



下单页面

1. 订单ID随机生成

2. 不能直接进到订单界面，必须从秒杀界面进入

3. 每个秒杀商品，需要带一个预先生成的随机token作为URL参数

4. 如果参加过秒杀，则直接结束。一个人只有一次机会。

5. 每件商品只能有100人下单。

秒杀静态页面优化

1. 图片合成

2. 减少HTTP请求次数，合并一块请求

3. 减少发送Cookies的量。

4. 图片压缩，前端解压。

下单页面优化

1. 砍掉数据库操作

2. 流程精简，2种思路，一种是没用的，一种是文案提示。

3. 收货地址，放到秒杀成功后填写，没秒杀到填了也没多少用处。

4. 砍掉查询是否开通支付功能，放到首页文案提示必须开通。

5. 内存缓存

6. 秒杀数据，支付相关信息，都直接缓存到内存里。



应急预案

1. 域名分离、独立域名。

2. Style集群

3. 图片集群

4. 静态页面集群

5. 万能出错页面

6. 备用服务器

7. 拆东墙补西墙战略，把其他系统的冗余的服务器下线，拿过来用。

8. 壁虎断尾策略，临时停掉非核心服务。保住首页及秒杀页。

9. 万能出错页面。秒杀活动已结束。

10. 任意错误都302过来。

11. 放到别的集群上，防止当前集群挂了。