秒杀场景的设计思考

在学习Redis的之后，一个绕不开的话题就是秒杀系统的设计。本文将从下面👇🏻几个方面展开一下个人简单的理解：

秒杀场景的介绍
设计的核心思路
怎么限流、削峰、异步
planB
总结

‍

秒杀场景的介绍

秒杀场景是大家常说的高并发场景，但是实际上其与单纯的高并发还有一点不同，主要区别就是其流量来的猛增，几乎是一个垂直的增长，而非线性增长的并发。

其具有如下特点：

瞬时高并发
读多写少
不能超卖

设计的核心思路

在解决系统架构的问题上，我们设计可以参考三要和一不要的原则，从一些通用性的角度提高一些系统健壮性：

要：要减少请求数据量；要减少请求次数；要减少依赖
不要：不要有“单点”

要减少请求数据量：后台返回前台的数据一般分为动态数据和静态数据，对于秒杀场景，我们可以考虑动静分离，对于不怎么会变化的数据，我们可以用cache、cdn等手段来直接处理，避免对后端资源的占用；对于库存这样的动态数据，我们才真正的去调用关键的接口和服务器。

要减少请求的次数：减少请求数最常用的一个实践就是合并CSS和JavaScript文件，把多个JavaScript文件合并成一个文件。这种方式在服务端仍然是单个文件各自存放，只是服务端会有一个组件解析这个URL，然后动态把这些文件合并起来一起返回。

有些同学会感觉这个第二点和第一点不是冲突的吗？
第一点说要减少请求数据量，所以要使用动静结合，第二点又说要减少请求的次数，和第一点不是矛盾了吗？实际上确实有一些矛盾的地方，就看取舍了，不同场景的考虑不一样，在秒杀场景来说，动静分离的好处肯定是比动静合并一起返回的带来的收益更大的。

要减少依赖：这点很好理解。我们在设计系统的时候在能满足需求和拓展性等能力的基础上，系统的架构约简单越好。此外，在架构设计的时候，我们必须要很好的梳理清楚系统的强弱依赖，这样才能在发生系统瓶颈或者异常的情况下及时定位到问题并解决。

不要有“单点” ：在分布式的架构设计的时候，我们的一个大忌就是“单点”问题，而解决的方法就是一般来说就是服务无状态话。服务无状态之后，我们可以非常方便的进行服务的扩容和迁移等。当然，对于数据库这样保存数据的服务很难（没办法）做到无状态话，这时，我们一般会采用冗余备份等方法增强其可靠性。

如何防止瞬时高并发

主要三个措施：缓存预热、流量限制。

我们也可以从事前、事中、事后的时间轴的角度来理解：事前：缓存预热；事后：流量限制、以及一些常用手段（限流、削峰、异步）；事后：并发较低，主要考虑对库存的一些处理。

缓存预热

我们可以对热点数据进行预热，热点数据就是指那些被秒杀的商品的一些信息。可以在秒杀开始之前将这些热点数据提前加载在缓存中。

对于提前并不能得知哪些数据是热点的情况，我们可以考虑进行一些动态的数据分析来获取热key，比如京东开源的hotkey框架。

流量限制

在秒杀场景中，我们最有可能出现性能瓶颈的地方是用于控制库存的DB，因此需要尽量控制进入DB中的并发量。

可以从两个角度考虑：非后端角度降低并发量 + 后端角度降低并发量。

非后端角度限制并发

非后端角度降低并发量指的是在流量打到后端处理秒杀的服务器之前就降低并发量，常见的角度为：

1.人为增加流程：比如说答题系统。答题系统的增加一方面来说由于人的答题速度不一致，一定程度上是分散了并发数量，另一方面来说也可以一定程度上防止用户使用作弊器的行为；又比如说前端通过限频降低并发数量，让用户点击的时候实际上不是每次点击都真正有效。

2.分层过滤：通过分层的措施，每一层减少一部分流量。如下图所示，真正访问到DB中的并发量相对于用户访问量来说已经是一个很少的比例了。

后端角度限制并发

后端限制并发就是一些通用的手段了，常见的有：

使用mq进行异步削峰
使用线程池限制并发数量
使用缓存（使用缓存当然要考虑一致性问题，在秒杀场景就是“超卖"问题，文章后面关于超卖|库存如何扣减会讨论）

补充

库存何时扣减

库存的扣减一般来说有3种时机：

下单时扣减库存：买家只要完成下单，立即减扣商品库存，这种方式实现是最简单而且也是最精准的，通常可以在下单时利用数据库事务能力即可保证减扣库存的准确性，但需要考虑买家下单后不付款的情况。
付款时扣减库存：卖家下单的时候不扣减库存，付款的时候才扣减库存。好处是不需要考虑下单不付款的库存回填的情况，坏处则是并发量大会出现大量用户能下单，但是付款无法完成（显示库存不足）。
结合前2种方案，下单时保留一定时间的库存：下单的时候扣减库存，如果用户30min时间内没有完成付款，那么就释放库存，其它用户可以继续抢购。

‍

可以结合平时网上下单的步骤想一下，我们下单需要哪几个步骤：1.点击下单；2.填写地址并付款。

根据在淘宝购买商品的经验，综合用户体验和实际架构，一般来说选择方案3。

‍

关于超卖|库存如何扣减

库存是放在MySQL中进行处理的，因此库存扣减判断的最终参考指标是：利用数据库的本地事务机制进行对库存的减扣，比如使用 where 库存 >0不满足就回滚。

但是在实际的秒杀场景架构中，肯定是会引入 Redis这样的缓存。
在引入缓存之后，我们就必须考虑缓存的一致性问题，一个很有意思的一点是：在秒杀场景中一般来说我们不需要强保证缓存和数据库中关于库存数据的一致性。
即，我们可以允许一定量的在Redis这一层的“超卖”，Redis“超卖”后，超卖的请求的数量不会太大，这些数量可以交给MySQL进行处理。

上面一段中提到“这些数量可以交给MySQL进行处理”，那么究竟多少数据可以交给MySQL处理呢？
实际上这就体现出压测的重要性了，这些请求究竟并发量由多少，MySQL可以承载多少理论分析只能有个指导值，具体有多少必须跑一跑压测才知道！

planB

前面我们提到了很多关于秒杀场景的设计，包括如何减少后端压力、如何设计库存扣减等等来保证系统的高性能。
然而，无论再精细的设计也只能保证系统尽可能健壮，因此我们在设计的时候必须考虑高可用方案。

关于如何设计高可用的方案，就是一个比较复杂的话题了，而且需要根据不同的系统和性能指标要求有不同的取舍，这里大概列出需要考虑的方面：

防止单点问题
防止影响扩大：隔离
如何降级、熔断

总结

秒杀场景是一个高可用场景中的典型类型，其拥有：高并发、读多写少、严格数据保证（不能超卖）的特点。
首先的思路是降低直接打入DB的并发量，可以考虑分层降低流量和增加步骤等操作降低并发。
其次库存扣减时机和超卖问题也有很多值得讨论的地方。
最后，再复杂的设计也有可能发生意外，因此我们必须考虑高可用的方案（planb）。

此外，在实际的场景中，除了正常的请求之外，往往我们还要考虑一些其他东西，比如说：灰产、用户恶意锁单等情况。

‍

主要参考：