你如何设计一个高性能的秒杀系统

秒杀系统场景特点

• 秒杀时大量用户会在同一时间同时进行抢购，网站瞬时访问流量激增。
• 秒杀一般是访问请求数量远远大于库存数量，只有少部分用户能够秒杀成功。
• 秒杀业务流程比较简单，一般就是下订单减库存。

整体思考

首先从高维度出发，整体思考问题。秒杀无外乎解决两个核心问题，一是并发读，一是并发写，对应到架构设计，就是高可用、一致性和高性能的要求。关于秒杀系统的设计思考，本文即基于此 3 层依次推进，简述如下

高性能。 秒杀涉及高读和高写的支持，如何支撑高并发，如何抵抗高IOPS？核心优化理念其实是类似的：高读就尽量"少读"或"读少"，高写就数据拆分。

 

一致性。 秒杀的核心关注是商品库存，有限的商品在同一时间被多个请求同时扣减，而且要保证准确性，显而易见是一个难题。如何做到既不多又不少？

 

高可用。 大型分布式系统在实际运行过程中面对的工况是非常复杂的，业务流量的突增、依赖服务的不稳定、应用自身的瓶颈、物理资源的损坏等方方面面都会对系统的运行带来大大小小的的冲击。

 

如何保障应用在复杂工况环境下还能高效稳定运行，如何预防和面对突发问题，系统设计时应该从哪些方面着手？

 

架构方案

一般秒杀系统架构如下图

 

 

设计思路

高性能

1 动静分离

大家可能会注意到，秒杀过程中你是不需要刷新整个页面的，只有时间在不停跳动。这是因为一般都会对大流量的秒杀系统做系统的静态化改造，即数据意义上的动静分离。动静分离三步走：1、数据拆分；2、静态缓存；3、数据整合。

1.1 数据拆分

动静分离的首要目的是将动态页面改造成适合缓存的静态页面。因此第一步就是分离出动态数据，主要从以下 2 个方面进行：

1. 用户。用户身份信息包括登录状态以及登录画像等，相关要素可以单独拆分出来，通过动态请求进行获取；与之相关的广平推荐，如用户偏好、地域偏好等，同样可以通过异步方式进行加载

    

2. 时间。秒杀时间是由服务端统一管控的，可以通过动态请求进行获取

这里你可以打开电商平台的一个秒杀页面，看看这个页面里都有哪些动静数据。

1.2 静态缓存

分离出动静态数据之后，第二步就是将静态数据进行合理的缓存，由此衍生出两个问题：1、怎么缓存；2、哪里缓存

1.2.1 怎么缓存

静态化改造的一个特点是直接缓存整个 HTTP 连接而不是仅仅缓存静态数据，如此一来，Web 代理服务器根据请求 URL，可以直接取出对应的响应体然后直接返回，响应过程无需重组 HTTP 协议，也无需解析 HTTP 请求头。

而作为缓存键，URL唯一化是必不可少的，只是对于商品系统，URL 天然是可以基于商品 ID 来进行唯一标识的，比如淘宝的 https://item.taobao.com/item....。

1.2.2 哪里缓存

静态数据缓存到哪里呢？可以有三种方式：1、浏览器；2、CDN ；3、服务端。

浏览器当然是第一选择，但用户的浏览器是不可控的，主要体现在如果用户不主动刷新，系统很难主动地把消息推送给用户（注意，当讨论静态数据时，潜台词是 “相对不变”，言外之意是 “可能会变”），如此可能会导致用户端在很长一段时间内看到的信息都是错误的。对于秒杀系统，保证缓存可以在秒级时间内失效是不可或缺的。

服务端主要进行动态逻辑计算及加载，本身并不擅长处理大量连接，每个连接消耗内存较多，同时 Servlet 容器解析 HTTP 较慢，容易侵占逻辑计算资源；另外，静态数据下沉至此也会拉长请求路径。

因此通常将静态数据缓存在 CDN，其本身更擅长处理大并发的静态文件请求，既可以做到主动失效，又离用户尽可能近，同时规避 Java 语言层面的弱点。需要注意的是，上 CDN 有以下几个问题需要解决：

1. 失效问题。任何一个缓存都应该是有时效的，尤其对于一个秒杀场景。所以，系统需要保证全国各地的 CDN 在秒级时间内失效掉缓存信息，这实际对 CDN 的失效系统要求是很高的

    

2. 命中率问题。高命中是缓存系统最为核心的性能要求，不然缓存就失去了意义。如果将数据放到全国各地的 CDN ，势必会导致请求命中同一个缓存的可能性降低，那么命中率就成为一个问题

因此，将数据放到全国所有的 CDN 节点是不太现实的，失效问题、命中率问题都会面临比较大的挑战。更为可行的做法是选择若干 CDN 节点进行静态化改造，节点的选取通常需要满足以下几个条件：

1. 临近访问量集中的地区

2. 距离主站较远的地区

3. 节点与主站间网络质量良好的地区

基于以上因素，选择 CDN 的二级缓存比较合适，因为二级缓存数量偏少，容量也更大，访问量相对集中，这样就可以较好解决缓存的失效问题以及命中率问题，是当前比较理想的一种 CDN 化方案。部署方式如下图所示：

 

 

1.3 数据整合

分离出动静态数据之后，前端如何组织数据页就是一个新的问题，主要在于动态数据的加载处理，通常有两种方案：ESI（Edge Side Includes）方案和 CSI（Client Side Include）方案。

1. ESI 方案：Web 代理服务器上请求动态数据，并将动态数据插入到静态页面中，用户看到页面时已经是一个完整的页面。这种方式对服务端性能要求高，但用户体验较好

    

2. CSI 方案：Web 代理服务器上只返回静态页面，前端单独发起一个异步 JS 请求动态数据。这种方式对服务端性能友好，但用户体验稍差

1.4 小结

动静分离对于性能的提升，抽象起来只有两点，一是数据要尽量少，以便减少没必要的请求，二是路径要尽量短，以便提高单次请求的效率。具体方法其实就是基于这个大方向进行的。

一致性

秒杀系统中，库存是个关键数据，卖不出去是个问题，超卖更是个问题。秒杀场景下的一致性问题，主要就是库存扣减的准确性问题。

1 减库存的方式

电商场景下的购买过程一般分为两步：下单和付款。“提交订单”即为下单，“支付订单”即为付款。基于此设定，减库存一般有以下几个方式：

1. 下单减库存。买家下单后，扣减商品库存。下单减库存是最简单的减库存方式，也是控制最为精确的一种

    

2. 付款减库存。买家下单后，并不立即扣减库存，而是等到付款后才真正扣减库存。但因为付款时才减库存，如果并发比较高，可能出现买家下单后付不了款的情况，因为商品已经被其他人买走了

    

3. 预扣库存。这种方式相对复杂一些，买家下单后，库存为其保留一定的时间（如 15 分钟），超过这段时间，库存自动释放，释放后其他买家可以购买

能够看到，减库存方式是基于购物过程的多阶段进行划分的，但无论是在下单阶段还是付款阶段，都会存在一些问题，下面进行具体分析。

2 减库存的问题

2.1 下单减库存

优势：用户体验最好。下单减库存是最简单的减库存方式，也是控制最精确的一种。下单时可以直接通过数据库事务机制控制商品库存，所以一定不会出现已下单却付不了款的情况。

劣势：可能卖不出去。正常情况下，买家下单后付款概率很高，所以不会有太大问题。但有一种场景例外，就是当卖家参加某个促销活动时，竞争对手通过恶意下单的方式将该商品全部下单，导致库存清零，那么这就不能正常售卖了——要知道，恶意下单的人是不会真正付款的，这正是 “下单减库存” 的不足之处。

2.2 付款减库存

优势：一定实际售卖。“下单减库存” 可能导致恶意下单，从而影响卖家的商品销售， “付款减库存” 由于需要付出真金白银，可以有效避免。

劣势：用户体验较差。用户下单后，不一定会实际付款，假设有 100 件商品，就可能出现 200 人下单成功的情况，因为下单时不会减库存，所以也就可能出现下单成功数远远超过真正库存数的情况，这尤其会发生在大促的热门商品上。如此一来就会导致很多买家下单成功后却付不了款，购物体验自然是比较差的。

2.3 预扣库存

优势：缓解了以上两种方式的问题。预扣库存实际就是“下单减库存”和 “付款减库存”两种方式的结合，将两次操作进行了前后关联，下单时预扣库存，付款时释放库存。

劣势：并没有彻底解决以上问题。比如针对恶意下单的场景，虽然可以把有效付款时间设置为 10 分钟，但恶意买家完全可以在 10 分钟之后再次下单。

2.4 小结

减库存的问题主要体现在用户体验和商业诉求两方面，其本质原因在于购物过程存在两步甚至多步操作，在不同阶段减库存，容易存在被恶意利用的漏洞。

3 实际如何减库存

业界最为常见的是预扣库存。无论是外卖点餐还是电商购物，下单后一般都有个 “有效付款时间”，超过该时间订单自动释放，这就是典型的预扣库存方案。但如上所述，预扣库存还需要解决恶意下单的问题，保证商品卖的出去；另一方面，如何避免超卖，也是一个痛点。

卖的出去：恶意下单的解决方案主要还是结合安全和反作弊措施来制止。

比如，识别频繁下单不付款的买家并进行打标，这样可以在打标买家下单时不减库存；

再比如为大促商品设置单人最大购买件数，一人最多只能买 N 件商品；又或者对重复下单不付款的行为进行次数限制阻断等

 

避免超卖：库存超卖的情况实际分为两种。对于普通商品，秒杀只是一种大促手段，即使库存超卖，商家也可以通过补货来解决；

而对于一些商品，秒杀作为一种营销手段，完全不允许库存为负，也就是在数据一致性上，需要保证大并发请求时数据库中的库存字段值不能为负。

 

一般有多种方案：

一是在通过事务来判断，即保证减后库存不能为负，否则就回滚；

二是直接设置数据库字段类型为无符号整数，这样一旦库存为负就会在执行 SQL 时报错；

三是使用 CASE WHEN 判断语句：

 

业务手段保证商品卖的出去，技术手段保证商品不会超卖，库存问题从来就不是简单的技术难题，解决问题的视角是多种多样的。

 

高可用

盯过秒杀流量监控的话，会发现它不是一条蜿蜒而起的曲线，而是一条挺拔的直线，这是因为秒杀请求高度集中于某一特定的时间点。

这样一来就会造成一个特别高的零点峰值，而对资源的消耗也几乎是瞬时的。所以秒杀系统的可用性保护是不可或缺的。

1 流量削峰

对于秒杀的目标场景，最终能够抢到商品的人数是固定的，无论 100 人和 10000 人参加结果都是一样的，即有效请求额度是有限的。

并发度越高，无效请求也就越多。但秒杀作为一种商业营销手段，活动开始之前是希望有更多的人来刷页面，只是真正开始后，秒杀请求不是越多越好。

因此系统可以设计一些规则，人为的延缓秒杀请求，甚至可以过滤掉一些无效请求。

1.1 答题

早期秒杀只是简单的点击秒杀按钮，后来才增加了答题。为什么要增加答题呢？主要是通过提升购买的复杂度，达到两个目的：

1. 防止作弊。早期秒杀器比较猖獗，存在恶意买家或竞争对手使用秒杀器扫货的情况，商家没有达到营销的目的，所以增加答题来进行限制

    

2. 延缓请求。零点流量的起效时间是毫秒级的，答题可以人为拉长峰值下单的时长，由之前的 <1s 延长到 <10s。这个时间对于服务端非常重要，会大大减轻高峰期并发压力；另外，由于请求具有先后顺序，答题后置的请求到来时可能已经没有库存了，因此根本无法下单，此阶段落到数据层真正的写也就非常有限了

需要注意的是，答题除了做正确性验证，还需要对提交时间做验证，比如<1s 人为操作的可能性就很小，可以进一步防止机器答题的情况。

答题目前已经使用的非常普遍了，本质是通过在入口层削减流量，从而让系统更好地支撑瞬时峰值。

1.2 排队

最为常见的削峰方案是使用消息队列，通过把同步的直接调用转换成异步的间接推送缓冲瞬时流量。除了消息队列，类似的排队方案还有很多，例如：

1. 线程池加锁等待

2. 本地内存蓄洪等待

3. 本地文件序列化写，再顺序读

排队方式的弊端也是显而易见的，主要有两点：

1. 请求积压。流量高峰如果长时间持续，达到了队列的水位上限，队列同样会被压垮，这样虽然保护了下游系统，但是和请求直接丢弃也没多大区别

    

2. 用户体验。异步推送的实时性和有序性自然是比不上同步调用的，由此可能出现请求先发后至的情况，影响部分敏感用户的购物体验

排队本质是在业务层将一步操作转变成两步操作，从而起到缓冲的作用，但鉴于此种方式的弊端，最终还是要基于业务量级和秒杀场景做出妥协和平衡。

1.3 过滤

过滤的核心结构在于分层，通过在不同层次过滤掉无效请求，达到数据读写的精准触发。常见的过滤主要有以下几层：

1. 读限流：对读请求做限流保护，将超出系统承载能力的请求过滤掉

2. 读缓存：对读请求做数据缓存，将重复的请求过滤掉

3. 写限流：对写请求做限流保护，将超出系统承载能力的请求过滤掉

4. 写校验：对写请求做一致性校验，只保留最终的有效数据

过滤的核心目的是通过减少无效请求的数据IO保障有效请求的IO性能。

1.4 小结

系统可以通过入口层的答题、业务层的排队、数据层的过滤达到流量削峰的目的，本质是在寻求商业诉求与架构性能之间的平衡。

另外，新的削峰手段也层出不穷，以业务切入居多，比如零点大促时同步发放优惠券或发起抽奖活动，将一部分流量分散到其他系统，这样也能起到削峰的作用。