如何设计一个秒杀系统

一：前言

1.在双十一或618期间电商平台会出一些秒杀活动来增加用户活跃带动其余商品销量。
2.秒杀系统面临三个问题：数据一致性、服务高性能、服务高可用。
3.针对一致性、高性能、高可用的思考

1）在高并发的情况下库存一致性怎么保证、库存什么时候扣减、库存什么时候回退，缓存和数据库的一致性怎么保证。
2）高性能要求下如何承接瞬时流量压力保证服务的性能，库表如何设计、缓存如何设计、接口什么逻辑。
3）高可用要求下瞬时流量很大如何保证服务的稳定性，如何保证服务器、缓存、数据库不被打崩、如何保证瞬时流量的时候不影响其他业务。

 

二：秒杀系统设计的14个关键问题

三：问题解决方案

 

1.瞬时流量
1）页面静态化
2）CDN缓存加速
3）限流
4）商品信息提前缓存
5）下单MQ异步削峰
5）分布式锁

2.页面静态化
1）活动页面是用户流量的第一入口，所以是并发量最大的地方。活动页面绝大多数内容是固定的，比如：商品名称、商品描述、图片等。为了减少不必要的服务端请求，通常情况下，会对活动页面做静态化处理。用户浏览商品等常规操作，并不会请求到服务端。只有到了秒杀时间点，并且用户主动点了秒杀按钮才允许访问服务端。
2）这些静态资源可以借助CDN缓存起来、减少网络传输、提升响应速度。

3.限流问题
1）为了保证服务的稳定性需要提前预估出秒杀场景有多少并发量，然后通过压测验证接口性能，限流可以分为查询限流和秒杀按钮限流。
2）查询限流：Nginx限流、网关接口限流
3）秒杀限流：前端按钮随机限流、Nginx随机限流、网关接口限流，用户点击时也可以增加人机验证（验证码、旋转滑块、答题）进行瞬时流量的降低。

 

4.读多写少

1）在秒杀的过程中，系统一般会先查一下库存是否足够，如果足够才允许下单，写数据库。如果不够，则直接返回该商品已经抢完。由于大量用户抢少量商品，只有极少部分用户能够抢成功，所以绝大部分用户在秒杀时，库存其实是不足的，系统会直接返回该商品已经抢完。

 

5.缓存问题
1）提前将商品信息刷到缓存中，然后给缓存设置超时时间、当查询时根据商品Id查询，如果缓存中有数据不存在，在进行数据库查询，查询后再缓存redis中。

 

2）商品库存要单独做一个缓存，主要原因是将商品对应的库存单独刷新进缓存，商品基础信息包含名称、描述、价格等等都是变更不频繁的信息，而库存在秒杀系统中叫频繁的获取修改，将两者分开可以提升查询效率。

3）因为使用缓存了秒杀的商品信息肯定要考虑，缓存击穿、缓存穿透。
　　3.1）缓存击穿：当查询商品A的时候，商品A不在缓存中，但是在数据库中，在高并发的情况下大量的请求会直接打到数据库上，导致数据库扛不住压力奔溃掉，解决防刷就是加商品维度分布式锁。

 

　　3.2）缓存穿透：当查询商品A的时候，缓存和数据库都不存在，这写请求每次都会打打数据库上，导致数据库扛不住压力奔溃掉，解决方案就是把不存的商品也进行缓存　　　　     {"goodId",12345,"goodExist":false}，当获取商品信息的时候现根据缓存判断商品是否存在，存在则返回信息，不存在响应异常码。

　　3.3）缓存雪崩：所有的商品设置了相同的失效时间，导致缓存同时失效，导致所有商品的查询同时打到数据库上，导致数据库扛不住压力奔溃掉，解决方案是针对不同的商品，设置分散的过期时间，避免缓存同时过期。

 

 

6.秒杀按钮：
1）按钮置灰：大部分用户怕错过秒杀时间点，一般会提前进入活动页面。此时看到的秒杀按钮是置灰，不可点击的。只有到了秒杀时间点那一时刻，秒杀按钮才会自动点亮，变成可点击的。

2）秒杀按钮需要前端做防重拦截，避免用户多次点击频繁触发后端接口。

 

 

7.黑产/防刷
1）为了规避黑产或竞对通过软件或脚本攻击系统，前端需要进行人机验证，如：验证码、旋转滑块、答题等等。
2）后端也要进行防刷验证，如根据用户唯一标识、IP拦截、同时要做用户风控验证。

 

8.库存扣减
1）库存扣减是秒杀系统中防止库存超卖的，如果直接进行数据库操作，瞬间并发流量会直接打满数据库，导致整体服务卡顿或崩溃。
2）如果用缓存抗住压力，先查询再判断最后在进行库存扣减、这三步操作非原子的，会导致库存超卖问题。
3）可以借助redis的lua脚本，lua脚本可以保证多步操作是原子的，可以完美解决库存超卖问题
4）数据的库存更新，一般都是在订单生成后、用户付款前进行扣除。

9.消息中间表
1）在秒杀系统中消息中间表是保证系统最终一致性的核心组件，其在下单时生成、在下单完成和付款完成时更新状态，在防止消息丢失时也要进行扫描。
2）消息中间表的生成要保证和下单相关数据推送MQ逻辑在同一个事务提交，保证消息中间表和订单数据强一致性，要么都成功要么都失败。
3）为什么要在下单相关数据推送MQ时生成消息中间表呢？
3.1当下单时如果服务奔溃了，此时订单已经生成了但是消息中间表没有数据，数据就不一致了。
3.2.如果下单消息丢失了，我们可以进行订单补偿。

 

10.异步削峰
1）瞬间洪流：主要原因是秒杀的瞬间流量较大，远超常规系统的处理能力，如果同时处理下单、支付等操作，这个请求会导致数据库奔溃、进而导致服务雪崩。
2）保证核心系统：下单、支付等操作是核心业务，在进行秒杀的时候要保证这些业务的稳定性，使用MQ削峰可以保证请求量在稳定的可处理范围。
3）提升响应速度：下单、支付操作设计很多步骤、调用链路相对较长，通过MQ异步化，仅保留核心操作（更新订单状态、库存扣减），其他操作交给MQ异步处理，提升响应速度。

11.异步问题
1）下单数据丢失：当下单操作向MQ发送消息时消息有可能丢失，我们可以使用定时任务+消息中间表进行扫描，将扫描到的数据进行重试，由于是下单丢失我们应该及时扫秒，30秒、1分钟。在扫描时我们要结合上次的最大主键Id。
2）消息重复消费：消费者读到消息之后，先判断一下消息处理表，该消息状态是否已下单，如果是，表示重复消费，则直接返回。如果不是，则进行下单操作，接着将该消息标记已下单。
3）垃圾消息：出现消息消费失败的情况。比如：由于某些原因，消息消费者下单一直失败，导致job会不停的重试发消息，最后，会产生大量的垃圾消息，可以在消息中间表加一个重试次数，当次数达到一定梳理的时候不在进行重试，然后预警出来。
4）延迟消费：当用户下单后一直不支付，我们要把订单状态置为无效，解决方案，当生成定时我们发出一个延迟MQ，15分钟自动消费延迟MQ，根据MQ中的订单消息查询订单表，判断用户是否已经支付，如果没有则改为已取消，如果是则不进行处理。

12.库存回退
1）有了库存扣减、那么在异常情况下肯定要进行库存回退，避免刷子或竟对下单后不付款，导致用户抢不到商品。
2）三处库存回退场景：
1.下单失败：由于调用下单接口网络问题、或用户自身风控稳定导致下单失败，需要将redis中库存进行回退
2.付款失败：由于网络问题或用户余额不足导致付款失败，需要将redis中库存进行回退。
3.用户主动取消订单：当用户在支付前主动取消订单时，需要将redis中库存进行回退。
4.订单超时未付款：通过延迟队列识别到用户超时未付款，需要将redis中库存进行回退。
3）库存回退：也使用redis的Lua脚本保证原子操作进行回退。
4）数据库的回退：考虑使用MQ异步回退。

用户通知
1）立即通知用户场景：前端轮询查询、webSocket。
2）非实时场景：用户自己查询订单、短信通知

 

13.库表设计

 

14.活动结束处理：
活动结束后要清除缓存的库存数据，避免影响下一次秒杀活动。