关于秒杀的那些事

前言

今天要分享的内容是关于秒杀的那些事，一些我所了解的秒杀设计的架构，希望对你有所帮助，另外，我会尽可能的精简语言，使你不需要花太多时间，就能读完这篇文章。

秒杀的本质

相信做过后台系统的朋友都知道，秒杀有很多不同业务场景，如电商平台的超低价秒杀，12306的放票秒杀等业务场景，电商类业务的本质，是为了吸引用户，促进业务发展，而12306的秒杀的本质，是为了让我们每个人买上出行的火车票，方便出乘。

秒杀的流程

1. 秒杀开始之前，用户打开客户端，可能是网页或是APP
2. 客户端会请求一次服务端，获取商品秒杀倒计时
3. 客户端轮询服务端，不停的问，开没开始，开没开始…
4. 每次轮询服务端都会返回一个时间，以用来校准客户端展示时间
5. 秒杀开始时，服务端返回Url
6. 客户端加载Url，让用户点击
7. 用户点击Url，请求服务端

我画了个图，帮助你更好理解

你可能会问，客户端请求一次不就行了吗，以第一次获取的时间为准，但你要知道，在服务端响应客户端时，可能会有网络延迟，或是服务不可用等情况导致获取的时间不准确或是失败，如果有时差，对用户体验不好放一边不说，这种设计严格来说已经不是秒杀了。

秒杀的技术难点

秒杀是用户所需，也是后端同学提升自己能力必须要去了解的一块技术领域，其主要技术挑战难点有以下几个方面

1. 实时在线用户规模是平时的几十倍甚至几百倍，TPS/QPS很高，对网络带宽、服务器性能带来成倍压力
2. 瞬时并发高，数据库会有被打挂的风险，可能会导致数据丢失、数据不一致、服务不可用等问题
3. 数据的修改是单条的，单点数据，无论怎么分库分表、读写分离、分布式数据库、表结构水平拆分、垂直拆分都无济于事

拿淘宝的秒杀来说，如果有100万用户同时秒杀200件商品，这100万的QPS轮询问服务端开没开始…理论上100万的QPS可以让带宽瞬间打爆，100万TPS可以让数据库瞬瞬间宕机…这简直是一场灾难，看起来无解了

秒杀的解决方案

结合上面的难点，我们大概会有以下思路

1. 分摊用户开始前的倒计时查询请求，让用户的查询请求分摊在不同的CDN上，并用负载均衡+服务集群+分布式缓存的模式
2. 使用CDN+边缘计算能力，在CDN上部署子服务，这些子服务提供计算在线用户量功能，并给出一个通过率，满足公式：用户数量*通过率=商品数量，比如淘宝100万用户在线抢200件商品，那通过率就是0.02%
3. 用户限流+单机限流，可以采用目前比较成熟的一些限流算法，如令牌桶算法、漏斗算法、计数算法
4. 客户端验证码，过滤掉机器或是脚本的请求

通过以上的一些策略，可以大幅度降低用户的请求，对于200的TPS，数据库怎么也能抗得住了

思考

秒杀场景是一个业务特例，商品数量有限制，所以需要对用户做过滤和限流。如果像双11那种，要卖出更多的商品的业务场景，就不需要对用户做限流了。而且是需要提升自身架构的吞吐量了，要对系统做大量的高并发测试和压测，找出系统的性能瓶颈，并改进。

在很多场景，我们应该跳出固有的传统的客户端+服务端+数据端的思维，站在不同的技术维度看待问题，像秒杀，就可以利用CDN做边缘计算，在外卖，打车，附近的人，等地域相关功能上，都有边缘计算的身影。

对于秒杀系统，如果你有其他的解决方案，欢迎给我留言~

本文参考陈皓老师的专栏：《61 | 性能设计篇之“秒杀”》