如何设计一个秒杀系统？

秒杀是电商系统中常见的业务，用于吸引用户，刺激留存及消费所做的一种活动。经典的秒杀包含限时秒杀和限量秒杀。很多公司有专门的秒杀系统。哪个业务要做活动，就来对接这个系统。

系统特点

1、瞬时流量极大，过了秒杀时间点流量结束。

2、秒杀商户库存极少，例如百万用户去抢2个iphone。

3、秒杀时间点没到的时候，刷新量大，静态资源访问量剧增。

一般流程

事前：运营侧建活动，并将秒杀数据、库存等信息写入缓存。技术侧预估资源等情况是否能支撑。

事中：秒杀快开始时，用户可能会疯狂刷新。开始后用户秒杀。

事后：履约。

映射到技术层面，有如下考虑点

1、高并发、快响应：除了秒杀开始后的流量激增，还要防止机器人刷单、页面访问量大和秒杀前防止请求打到后端。

2、防超卖。

3、订单履约。

4、应急处理。

高并发、快响应

严格准入，比如手机验证、真人验证手段防止机器人刷单。

使用页面静态化、CDN加速、静态资源缓存及压缩对应页面访问量大。

秒杀按钮置灰、秒杀真链接隐藏来防止秒杀前请求打到后端，同时也可以防止一些机器人、黄牛提前知道链接，使得真正的用户抢不到。还可以针对同一用户、同一IP做限流，比如10QPS，这已经基本不是人可以做到的手速了。

对于秒杀开始后的流量激增，首先要做好压测，找出薄弱点进行代码优化、服务支撑优化。如果公司支持弹性扩缩，要提前测试。如果公司不支持，容量要提前扩容到位并压测。

防超卖

技术上一般采用redis+热数据缓存+MQ。库存一般会在秒杀前同步到redis中。秒杀时判断库存是否充足，充足则可进行扣减。可以借助Redis+lua脚本来保证原子性，防止数据不准确造成超卖。

订单履约

秒杀可以采用两阶段处理，第一阶段如果秒杀成功，则将这个消息放入消息队列来做履约。这样可以提高响应速度，也可以减少秒杀并发的压力。这个消息要做成可靠消息，如果消费失败，需要有重试。重试失败则需要持久化到数据库等方式保存，定时扫描重新处理。同时要有告警机制，确保成功。

应急处理

要有降级开关来保证确实出了问题的情况下及时止损。