设计一个秒杀系统之削峰填谷

为什么需要削峰h2>

如果你看过秒杀系统的流量监控图的话，你会发现它是一条直线，就在秒杀开始那一秒是一条很 直很直的线，这是因为秒杀请求在时间上高度集中于某一特定的时间点。这样一来，就会导致一 个特别高的流量峰值，它对资源的消耗是瞬时的。
但是对秒杀这个场景来说，最终能够抢到商品的人数是固定的，也就是说 100 人和 10000 人发 起请求的结果都是一样的，并发度越高，无效请求也越多，或者说，10000件商品10000个人抢购，但是不要让大家一起去抢，这样谁也受不了，让他们排队抢。

这就好比因为存在早高峰和晚高峰的问题，所以有了错峰限行的解决方案。削峰的存在，一是可 以让服务端处理变得更加平稳，二是可以节省服务器的资源成本。针对秒杀这一场景，削峰从本 质上来说就是更多地延缓用户请求的发出，以便减少和过滤掉一些无效请求，它遵从“请求数要 尽量少”的原则。

但是从业务上来说，秒杀活动是希望更多的人来参与的，也就是开始之前希望有更多的人来刷页 面，但是真正开始下单时，秒杀请求并不是越多越好。因此我们可以设计一些规则，让并发的请 求更多地延缓，而且我们甚至可以过滤掉一些无效请求。

流量削峰的思路

流量削峰的一些操作思路：排队、答题、分层过滤。这几种方式都是无损 （即不会损失用户的发出请求）的实现方案，当然还有些有损的实现方案，包括我们后面要介绍 的关于稳定性的一些办法，比如限流和机器负载保护等一些强制措施也能达到削峰保护的目的， 当然这都是不得已的一些措施，因此就不归类到这里了。

排队

要对流量进行削峰，最容易想到的解决方案就是用消息队列来缓冲瞬时流量，把同步的直接调用 转换成异步的间接推送，中间通过一个队列在一端承接瞬时的流量洪峰，在另一端平滑地将消息 推送出去。在这里，消息队列就像“水库”一样， 拦蓄上游的洪水，削减进入下游河道的洪峰流 量，从而达到减免洪水灾害的目的。

用消息队列来缓冲瞬时流量的方案，如下图所示：

第二个目的其实就是延缓请求，起到对请求流量进行削峰的作用，从而让系统能够更好地支持瞬 时的流量高峰。这个重要的功能就是把峰值的下单请求拉长，从以前的 1s 之内延长到 2s~10s。这样一来，请求峰值基于时间分片了。这个时间的分片对服务端处理并发非常重要，会大大减轻 压力。而且，由于请求具有先后顺序，靠后的请求到来时自然也就没有库存了，因此根本到不了 最后的下单步骤，所以真正的并发写就非常有限了。这种设计思路目前用得非常普遍，如当年支 付宝的“咻一咻”、微信的“摇一摇”都是类似的方式。

注意，这里面的验证逻辑，除了验证问题的答案以外，还包括用户本身身份的验证，例如是否已 经登录、用户的 Cookie 是否完整、用户是否重复频繁提交等。

除了做正确性验证，我们还可以对提交答案的时间做些限制，例如从开始答题到接受答案要超过 1s，因为小于 1s 是人为操作的可能性很小，这样也能防止机器答题的情况。

分层过滤

前面介绍的排队和答题要么是少发请求，要么对发出来的请求进行缓冲，而针对秒杀场景还有一 种方法，就是对请求进行分层过滤，从而过滤掉一些无效的请求。分层过滤其实就是采用“漏 斗”式设计来处理请求的，如下图所示。