架构师之路(18)讲解秒杀系统设计

1 秒杀场景

秒杀场景

1. 登陆12306进行火车票抢座 

2. 1599元购入飞天茅台

3. 周董演唱会的门票

4. 双十一秒杀活动

秒杀场景关注点

1. 严格防止超卖：库存1000件卖了1020件，要杀个码农祭天了！防止超卖是秒杀系统设计最核心的部分。

2. 防止黑产：防止不怀好意的羊毛党薅羊毛。

3. 保证用户体验：高并发下，给用户提供友善的购物体验，尽可能支持比较高的QPS等等。

接下来就让我们按照关注点，不断细化秒杀场景。

2 第1版-裸奔

不加思考，上来直接按照 SpringBoot + MyBatis 模式进行秒杀系统的设计，流程如下：

1. Controller层获得用户秒杀请求后调用Service层。

2. Service层获得请求后要要检查已售数据跟库存总量是否一致，一致说明商品卖没了，不一致说明还有库存，那就调用DAO层对已售数量进行加1。

3. DAO层获得请求后直接通过MyBatis操作数据库实现已售数量加1跟订单创建。

如果你用Postman去测试会发现是OK的，但如果你用专业的并发测试工具JMeter模式多用户并发请求会发现订单创建数量 > 库存量 - 已售量。原因解释下，比如用户A、B并发进行秒杀请求，此时库存=100，已售=64。

1. A用户进行描述请求，此时调用到了Service层，发现已售不等于库存，此时拿到库存数是64，A将库存更新为63，然后创建订单。

2. B用户进行描述请求，此时调用到了Service层，发现已售不等于库存，此时拿到库存数是64，B将库存更新为63，然后创建订单。

3. 此时库存减少了1个但是订单创建多个，卖超了！

3 第2版-悲观锁

遇见 并发问题 很容易想到以前学过并发编程嘛，既然Controller默认是单例模式，那我用 synchronized 将Controller层调用Service层的代码进行加锁同步即可。

这样就可以解决卖超问题了，但是须知，既然是悲观锁，如果有1000个并发请求，那只有1个拿到锁了。有999个会去竞争这个锁的。

当然了你也可以用Spring自带的事务注解来实现悲观锁的操作，因为用了@Transactional就可以实现通过事务来控制，要么全部成功，要么全部失败，用事务时有两点需注意：

1. 尽可能将MySQL执行语句往方法体后面靠，因为MySQL事务的commit语句是在第一次执行MySQL相关语句开始，一直到方法的结束。

2. 设置事务的超时时间，如果不设置默认是-1是无限长。并且事务中设置的耗时timeout = 最后一个MySQL语句耗时 + 以及最后一个MySQL之前的所有耗时。

需注意：悲观锁状态下会保证商品卖出去，如果没拿到锁的线程会阻塞的等待拿锁。但是他的阻塞也会给用户带来非常不良好的体验

 4 第3版-乐观锁 

我们为每个数量的已售数据配备个版本号，在Service层调用时获得用户的已售数跟对应版本号，然后更新时将已售数跟版本号同时更新。因为 MySQL在更新时会自带乐观加速机制，如果更新成功则表示抢购成功，更新失败则表示抢购失败，此时你会发现不是手速越快就一定能抢到的哦，但起码保证了不会超卖，

需注意：乐观锁状态下，由于是随机性的秒杀失败，所以可能活动结束后还会有几个没售出去的！

5 第4版-限流 

最核心的超卖问题已经解决了，接下来就是各种优化手段了。在高并发请求中如果不对接口限流会对后台服务器造成极大压力，所以一般秒杀系统为了不影响其他业务会单独部署到个某个服务器上，同时还会设置好限流。

常用的限流方法有我们在 Redis 中曾经说过，主要有漏桶算法、令牌桶算法。而Google开源项目Guava中RateLimiter使用的就是令牌桶控制算法。在开发高并发系统时有三把利器用来保护系统：缓存、降级、限流

1. 缓存：缓存的目的是提升系统访问速度和增大系统处理容量。

2. 降级：降级是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。

3. 限流：限流的目的是通过对并发访问/请求进行限速，或者对一个时间窗口内的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务、排队或等待、降级等处理。

5.1 漏桶算法

漏桶算法思路：把水比作是请求，漏桶比作是系统处理能力极限，水先进入到漏桶里，漏桶里的水按一定速率流出，当流出的速率小于流入的速率时，由于漏桶容量有限，后续进入的水直接溢出（拒绝请求），以此实现限流。

 

5.2 令牌桶算法

令牌桶算法原理：可以理解成医院的挂号看病，只有拿到号以后才可以进行诊病。

流程大致：

1. 所有的请求在处理之前都需要拿到一个可用的令牌才会被处理。

2. 根据限流大小，设置按照一定的速率往桶里添加令牌。

3. 设置桶最大可容纳值，当桶满时新添加的令牌就被丢弃或者拒绝。

4. 请求达到后首先要获取令牌桶中的令牌，拿着令牌才可以进行其他的业务逻辑，处理完业务逻辑之后，将令牌直接删除。

5. 如果用户无法获得令牌可以选择一直阻塞等待，也可以选择设置好timeout机制。

6. 令牌桶有最低限额，当桶中的令牌达到最低限额的时候，请求处理完之后将不会删除令牌，以此保证足够的限流。

工程中一般用令牌桶算法为多，一般用Google的Guava 中 RateLimiter 即可。

 

6 第5版- 细节优化 

有了乐观锁跟限流，接下来再思考写细节问题。

1. 秒杀要有时间范围限制的，不能再任意时刻都可以接受秒杀请求，要实行限时抢购。

2. 如果有懂IT人员通过抓包获取了秒杀接口地址，在秒杀开始时，不通过按钮，直接通过脚本秒杀咋办？要实行秒杀接口隐藏。

3. 每个用户单位时间内访问次数要做频率限制。

6.1 限时抢购

很简单，将秒杀商品放入Redis并设置超时，比如我们以kill + 商品id作为key，以商品id作为value，设置180秒超时。

加入时间校验：

6.2 秒杀接口隐藏

1. 用户秒杀前先通过getMd5方法获得一个请求秒杀URL的MD5值。

2. 请求getMd5算法，Key = 商品id + 用户id，value = 商品id + 用户id + 盐 。将KV存入redis并且设置过期时间，最终返回value作为md5值。

3. 用户请求秒杀URL的时候需携带MD5值，然后Service层会根据商品id + 用户id从redis中获取下对应的value，看这个value跟MD5值是否一致，绝对下一步操作。

   

   此时如果用户直接请求秒杀接口就会被限制了，但如果黑客技术升级，将请求MD5跟请求秒杀接口写到一起，还是无法防止被薅羊毛！咋办呢？再限制下用户访问频率。

 6.3 访问频率限制

1. 通过前面请求后根据用户id生成个redis中的key，value为访问次数，默认为0，并且设置好该KV的过期时间。

2. 用户在验证是否通过秒杀隐藏接口验证前，先看下他的单位时间内访问次数是多少，如果超过阈值则直接拒绝，没超过再进行隐藏接口的验证。

3. 这里只是举例为用户访问次数限制，IP访问次数限制类似。

   

   7 第6版-众多细节优化 

1. CDN加速：为何京东物流快，因为人在全国各地配置了多个仓库。同理，我们可以将前端的一些静态东西配置在全国各个不同的地方，用户请求时，直接请求距离自己最近的前端资源即可。

2. 前端按钮灰色化：如果参与过秒杀活动会发现，没到秒杀时间时秒杀按钮是灰色状态的，只有时间到了才是可点击状态。并且秒杀开始咯也不是一直可以点的，可能只允许1秒内点10次那种的。

3. Nginx负载均衡：一个tomcat的QPS一般在200~1000左右，如果淘宝或京东性质的秒杀，就需要搞个Nginx负载均衡来支持几万级别的并发了。

4. 信息存储Redis化：单独的MySQL是无法支撑上万的QPS的，既然Redis号称可支持10W级的QPS，我们把数据信息存到Redis中就好咯嘛！有人可能会说MySQL有乐观锁跟事务性啊，Redis不是没有事务性么，其实我们可以通过 Lua 脚本来实现并发情况下Redis的事务性操作。

5. 消息中间件-流量削峰：秒杀成功后，如果秒杀的成功量过大，全部订单直接写入MySQL也是不太恰当的，可以把秒杀成功的用户信息写入消息中间件。比如RabbitMQ、Kafka，给用户返回抢购成功信息，然后专门代码消费中间件信息(生成订单，数据持久化)，因为是异步消费，为防止用户秒杀成功后无法看到订单信息，在订单生成前给用户提示订单提交排队中，啥时候订单异步消费成功了再告知用户成功。

6. 辅助手段：秒杀前做个预演练是必须的吧，系统上线后QPS监控、CPU监控、IO监控、缓存监控也是必须要搞的。同时一旦服务真的扛不住了熔断跟限流也要考虑进去。

7. 短URL：有时你别人发给你个超短的URL你打开后就直接跳转为日常看到的购物页面了，这就涉及到短URL映射了，大致思路就是做个链接映射，在此基础上也可以玩出各种花样。

8. 工业化秒杀：真正工业化的秒杀绝对不止我前面说的那么简单哦，起码你会接触到 MQ、SpringBoot、Redis、Dubbo、ZK 、Maven、lua等知识点