如何设计一个秒杀系统

一：前言

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

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

 

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

 

三：问题解决方案

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.缓存带来的问题：因为使用缓存了秒杀的商品信息肯定要考虑，缓存击穿、缓存穿透。

缓存击穿：当查询商品A的时候，商品A不在缓存中，但是在数据库中，在高并发的情况下大量的请求会直接打到数据库上，导致数据库扛不住压力奔溃掉，解决防刷就是加商品维度分布式锁。

 

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

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

 

 

6.秒杀按钮

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

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

 

7.黑产/防刷

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

 

8.库存扣减

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

-- KEYS[1]:库存key, KEYS[2]:预占key, ARGV[1]:扣减量
local total = tonumber(redis.call('GET', KEYS[1]))
local reserved = tonumber(redis.call('GET', KEYS[2]))
if total - reserved >= tonumber(ARGV[1]) then
    redis.call('INCRBY', KEYS[2], ARGV[1])
    return 1  -- 成功
else
    return 0  -- 库存不足
end

4.数据库库存同步：数据的库存更新，一般都是在订单生成后、用户付款前进行扣除。

 

9.消息中间表

1.最终一致性：在秒杀系统中消息中间表是保证系统最终一致性的核心组件，其在下单时生成、在下单完成和付款完成时更新状态，在防止消息丢失时也要进行扫描。
2.同一事务提交：消息中间表的生成要保证和下单相关数据推送MQ逻辑在同一个事务提交，保证消息中间表和订单数据强一致性，要么都成功要么都失败。
3.下单时推送：为什么要在下单时推送MQ时生成消息中间表呢？

1.当下单时如果服务奔溃了，此时订单已经生成了但是消息中间表没有数据，数据就不一致了。
2.如果下单消息丢失了，我们可以进行订单补偿。

 4.三大应用场景：消息丢失、重复消费、垃圾消息

 

10.异步削峰

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

 

11.异步问题

1.下单数据丢失：秒杀成功了，往mq发送下单消息的时候，有可能会失败。原因有很多，比如：网络问题、broker挂了、mq服务端磁盘问题等，我们可以加一张消息中间表。

下单丢失可以使用定时任务+消息中间表进行扫描进行解决，  在生产者发送mq消息之前，先把该条消息写入消息发送表，初始状态是待处理，然后再发送mq消息，消息中间表写入要和下单数据发送在一个事务中保证数据一致。

 

2.消息重复消费：消费者读到消息之后，先判断一下消息处理表，该消息状态是否已下单，如果是，表示重复消费，则直接返回。如果不是，则进行下单操作，接着将该消息标记已下单。

 

 

3.垃圾消息：出现消息消费失败的情况。比如：由于某些原因，消息消费者下单一直失败，导致job会不停的重试发消息，最后，会产生大量的垃圾消息，可以在消息中间表加一个重试次数，当次数达到一定梳理的时候不在进行重试，然后预警出来。

 

4.延迟消费：当用户下单后一直不支付，我们要把订单状态置为无效，解决方案，当生成定时我们发出一个延迟MQ，15分钟自动消费延迟MQ，根据MQ中的订单消息查询订单表，判断用户是否已经支付，如果没有则改为已取消，如果是则不进行处理。

 

12.库存回退

1.库存退回：有了库存扣减、那么在异常情况下肯定要进行库存回退，避免刷子或竞对下单后不付款，导致用户抢不到商品。
2.四处库存回退场景：

 

1.下单失败：由于调用下单接口网络问题、或用户自身风控稳定导致下单失败，需要将redis中库存进行回退
2.付款失败：由于网络问题或用户余额不足导致付款失败，需要将redis中库存进行回退。
3.用户主动取消：当用户在支付前主动取消订单时，需要将redis中库存进行回退。
4.超时未付款：通过延迟队列识别到用户超时未付款，需要将redis中库存进行回退。

备注：
库存回退：也使用redis的Lua脚本保证原子操作进行回退。
数据库的回退：考虑使用MQ异步回退。

 

13.用户通知

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

 

14.库表设计

1.六张关联表：用户表、商品表、秒杀商品表、秒杀活动表、秒杀订单表、消息中间表 

 

用户表

CREATE TABLE t_user (
  user_id BIGINT PRIMARY KEY COMMENT '用户ID，使用分布式ID',
  username VARCHAR(50) NOT NULL UNIQUE COMMENT '用户名',
  password VARCHAR(100) NOT NULL COMMENT '加密密码',
  phone VARCHAR(20) COMMENT '手机号',
  email VARCHAR(100) COMMENT '邮箱',
  status TINYINT DEFAULT 1 COMMENT '状态：0-禁用，1-正常',
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间'
) COMMENT '用户表';

索引设计‌：

• 主键：user_id

 

商品表

CREATE TABLE t_goods (
  goods_id BIGINT PRIMARY KEY COMMENT '商品ID，使用分布式ID',
  goods_name VARCHAR(100) NOT NULL COMMENT '商品名称',
  goods_img VARCHAR(200) COMMENT '商品图片',
  price INT NOT NULL COMMENT '商品价格(单位：分)',
  stock INT NOT NULL DEFAULT 0 COMMENT '商品库存',
  description TEXT COMMENT '商品描述',
  status TINYINT DEFAULT 1 COMMENT '状态：0-下架，1-上架',
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间'
) COMMENT '商品表';

‌索引设计‌：

• 主键：goods_id

 

秒杀商品表

CREATE TABLE seckill_goods (
  id BIGINT PRIMARY KEY COMMENT '主键ID',
  activity_id BIGINT NOT NULL COMMENT '活动ID',
  goods_id BIGINT NOT NULL COMMENT '商品ID',
  seckill_price INT NOT NULL COMMENT '秒杀价格(单位：分)',
  stock_count INT NOT NULL COMMENT '秒杀库存',
  start_date DATETIME NOT NULL COMMENT '秒杀开始时间',
  end_date DATETIME NOT NULL COMMENT '秒杀结束时间',
  version INT DEFAULT 0 COMMENT '版本号，用于乐观锁',
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间'
) COMMENT '秒杀商品表';

‌索引设计‌：

• 主键：id
• 联合索引：(activity_id, goods_id)
• 联合索引：(start_date, end_date)

 

秒杀活动表

CREATE TABLE seckill_activity (
  activity_id BIGINT PRIMARY KEY COMMENT '活动ID，使用分布式ID',
  activity_name VARCHAR(100) NOT NULL COMMENT '活动名称',
  start_time DATETIME NOT NULL COMMENT '活动开始时间',
  end_time DATETIME NOT NULL COMMENT '活动结束时间',
  status TINYINT DEFAULT 0 COMMENT '状态：0-未发布，1-未开始，2-进行中，3-已结束，4-已关闭',
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间'
) COMMENT '秒杀活动表';

索引设计‌：

• 主键：activity_id
• 联合索引：(start_time, end_time)
• 普通索引：status

 

秒杀订单表

CREATE TABLE seckill_order (
  order_id BIGINT PRIMARY KEY COMMENT '订单ID，使用分布式ID',
  user_id BIGINT NOT NULL COMMENT '用户ID',
  goods_id BIGINT NOT NULL COMMENT '商品ID',
  activity_id BIGINT NOT NULL COMMENT '活动ID',
  goods_name VARCHAR(100) NOT NULL COMMENT '商品名称(冗余字段)',
  seckill_price INT NOT NULL COMMENT '秒杀价格(单位：分)',
  quantity INT NOT NULL DEFAULT 1 COMMENT '购买数量',
  order_status TINYINT DEFAULT 0 COMMENT '订单状态：0-未支付，1-已支付，2-已取消',
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  pay_time DATETIME COMMENT '支付时间'
) COMMENT '秒杀订单表';

 

‌索引设计‌：

• 主键：order_id
• 联合索引：(user_id, goods_id)
• 普通索引：activity_id, order_status

 

消息中间表 

 

CREATE TABLE local_transaction_log (
  id BIGINT PRIMARY KEY COMMENT '主键ID',
  transaction_id VARCHAR(64) NOT NULL COMMENT '事务ID',
  business_type VARCHAR(50) NOT NULL COMMENT '业务类型',
  business_key VARCHAR(100) NOT NULL COMMENT '业务键',
  message_content TEXT NOT NULL COMMENT '消息内容',
  status TINYINT DEFAULT 0 COMMENT '状态：0-待发送，1-已发送，2-已完成',
  retry_count INT DEFAULT 0 COMMENT '重试次数',
  next_retry_time DATETIME COMMENT '下次重试时间',
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间'
) COMMENT '本地事务表';

‌索引设计‌：

• 主键：id
• 联合索引：(business_type, business_key)
• 普通索引：status, next_retry_time

 

14.活动结束处理

1.资源释放：活动结束后要清除缓存的库存数据，避免影响下一次秒杀活动。

2.对账：对因系统异常导致的订单状态不一致问题（如已扣库存但未生成订单），需通过补偿任务或人工介入进行修复，确保数据最终一致性‌

 

15.秒杀活动降级处理

1.前端处理：前端应该能够快速对秒杀页面或活动进行快速上下线，后端服务异常时要有兜底页面。

2.服务降级：服务应做好限流，熔断等处理，保证服务的稳定。

3.业务开关：秒杀活动要有降级开关，在产生异常时可进行快速上下线。