秒杀系统设计

背景

我之前写过一个秒杀系统的文章不过有些许瑕疵，所以我准备在之前的基础上进行二次创作，不过让我决心二创秒杀系统的原因是我最近面试了很多读者，动不动就是秒杀系统把我整蒙蔽了，我懵的主要是秒杀系统的细节大家都不知道，甚至不知道电商公司一个秒杀系统的组成部分。

我之前在某电商公司就是做电商活动的，所以这样的场景和很多解决方案我是比较清楚的，那我就从我自身去带着大家看看一个秒杀的设计细节以及中间各种解决方案的利弊，以下就是我设计的秒杀系统，几乎涵盖了市面上所有秒杀的实现细节：

正文

首先设计一个系统之前，我们需要先确认我们的业务场景是怎么样子的，我就带着大家一起假设一个场景好吧。

我们现场要卖1000件下面这个婴儿纸尿裤，然后我们根据以往这样秒杀活动的数据经验来看，目测来抢这100件纸尿裤的人足足有10万人。（南极人打钱！）

你一听，完了呀，这我们的服务器哪里顶得住啊！说真的直接打DB肯定挂，但是别急嘛，任何系统我们开始设计之前我们都应该去思考会出现哪些问题？这里我罗列了几个非常经典的问题：

问题

高并发：

是的高并发这个是我们想都不用想的一个点，一瞬间这么多人进来这不是高并发什么时候是呢？

是吧，秒杀的特点就是这样时间极短、 瞬间用户量大。

正常的店铺营销都是用极低的价格配合上短信、APP的精准推送，吸引特别多的用户来参与这场秒杀，爽了商家苦了开发呀。

秒杀大家都知道如果真的营销到位，价格诱人，几十万的流量我觉得完全不是问题，那单机的Redis我感觉3-4W的QPS还是能顶得住的，但是再高了就没办法了，那这个数据随便搞个热销商品的秒杀可能都不止了。

大量的请求进来，我们需要考虑的点就很多了，缓存雪崩，缓存击穿，缓存穿透这些我之前提到的点都是有可能发生的，出现问题打挂DB那就很难受了，活动失败用户体验差，活动人气没了，最后背锅的还是开发。

超卖：

但凡是个秒杀，都怕超卖，我这里举例的只是尿不湿，要是换成100个MacBook Pro，商家的预算经费卖100个可以赚点还可以造势，结果你写错程序多卖出去200个，你不发货用户投诉你，平台封你店，你发货就血亏，你怎么办？ （没事看了敖丙的文章直接不怕）

那最后只能杀个开发祭天解气了，秒杀的价格本来就低了，基本上都是不怎么赚钱的，超卖了就恐怖了呀，所以超卖也是很关键的一个点。

恶意请求：

你这么低的价格，假如我抢到了，我转手卖掉我不是血赚？就算我不卖我也不亏啊，那用户知道，你知道，别的别有用心的人（黑客、黄牛...）肯定也知道的。

那简单啊，我知道你什么时候抢，我搞个几十台机器搞点脚本，我也模拟出来十几万个人左右的请求，那我是不是意味着我基本上有80%的成功率了。

真实情况可能远远不止，因为机器请求的速度比人的手速往往快太多了，在贵州的敖丙我每年回家抢高铁票都是秒光</