Seckill

秒杀 / 抢购

When to Invoke

限时、库存少、瞬时 QPS 远大于日常下单。文旅抢票、酒店今夜特价、券秒杀同样适用。

When NOT

日常加购/下单 → inventory-occupy + concurrency-sell。不要把每个商品详情当秒杀。

风险（面试考点）

秒杀不是「Redis 锁 + 下单」。核心是 把无效流量拦在数据库之外，有效请求才扣库存。只靠 DB 行锁会打挂；只靠锁不带 stock>=n 会超卖。面试要能画出分层，而不是堆中间件名词。

分层（从外到内，默认全要，由外到内变严）

预扣失败直接售罄。禁止预扣失败还去锁 DB。

扣减细节读 concurrency-sell，热点拆段读 hot-account，关单读 delay-job。本文件不重复那些 SQL。本次最多再加 1–2 个，不要把上面三个全读进来。

默认方案

活动前把库存写入 Redis，按 SKU 分片（见 hot-account）。

-- KEYS[1] stock  KEYS[2] boughtSet  ARGV[1] userId  ARGV[2] n
if redis.call('SISMEMBER', KEYS[2], ARGV[1]) == 1 then return -1 end
local s = tonumber(redis.call('GET', KEYS[1]) or '0')
if s < tonumber(ARGV[2]) then return 0 end
redis.call('DECRBY', KEYS[1], ARGV[2])
redis.call('SADD', KEYS[2], ARGV[1])
return 1

成功 → RocketMQ（keys=userId+sku+activity）→ 消费者本地事务创单 + DB 条件扣。重复消息靠唯一键。

独立线程池、独立 Redis、必要时独立库。不要和商详、后台报表混部。

反例

错误：请求一进来 RLock + select stock + update。 正确：Lua 预扣，DB 只接预扣成功的量级。

错误：DECR 成负数还创单。 正确：Lua 里判断再减。

错误：MQ 消费者扣库存不带 stock>=n，重试把库存打成负数。 正确：条件更新 + 影响行数。

验证

• 库存 100，5 万 QPS，成交 ≤100，DB QPS 远小于入口。
• 同一用户并发只成一单。
• Redis 预扣了但创单失败，有回补或对账。

评审清单

• 有分层拦截，不是一把锁打天下
• Lua 预扣 + DB 条件更新两道
• 一人一单唯一键
• 秒杀集群与普通交易隔离