一次 4 万元资损事故复盘：并发竞态如何让优惠券被重复领取

作者温砚舟-109

并发安全竞态条件幂等数据一致性分布式锁

一、现象：1000 张券，被"领"了 2371 次

去年双 11 前的预热活动，我们上一张满 200 减 50 的优惠券，计划只发 1000 张。活动开抢后 3 分钟，客服后台就炸了：发券流水 2371 条，其中同一个 user_id 重复出现的占了 800 多条。按面值算，直接资损约 4 万元。监控上，发券接口 QPS 峰值 820，后端 8 个应用实例、MySQL 8.0.32、Redis 7.2 集群。复盘时最扎心的一句是：我们明明在代码里加了锁。

二、根因：先查后改不是原子的，锁也只在单实例内有效

把链路拆开看，发券逻辑是这样的：

int remain = couponStockDao.selectRemain(campaignId);      // 1. 查
if (remain > 0) {
    couponStockDao.updateRemain(campaignId, remain - 1);    // 2. 改
    couponOrderDao.insert(...);                             // 3. 落流水
}

问题出在"查"和"改"之间隔着一次网络往返，两个请求可以同时读到 remain=1，然后各自减一、各自落流水——这是典型的 TOCTOU（Time-Of-Check to Time-Of-Use）竞态。我们最初以为加了 synchronized 就解决了，但 8 个实例各自一把锁，跨进程根本互斥不了；更关键的是数据库层面没有任何唯一约束兜底，coupon_order 表对 (user_id, campaign_id) 完全允许重复插入。所以这道防线其实是"应用层锁（失效）+ DB 无约束（裸奔）"，两层都没真正起作用。

三、做法：把"唯一性"交给数据库，把"原子扣减"交给一条 UPDATE

1. 加幂等键 + 唯一索引，让重复领取在 DB 层直接撞墙：

ALTER TABLE coupon_order
  ADD COLUMN idempotency_key VARCHAR(64) NOT NULL,
  ADD UNIQUE INDEX uk_user_idem (user_id, campaign_id, idempotency_key);

2. 把"查 + 改"合并成一条带条件的原子 UPDATE，靠 affectedRows 判断成败：

UPDATE coupon_stock
   SET remain = remain - 1, version = version + 1
 WHERE campaign_id = ? AND remain > 0;

应用层拿到返回行数：affectedRows == 1 才继续发券，0 直接返回"已抢完"。这一条 SQL 自带 remain > 0 的乐观校验，不需要再单独 SELECT 一次。

3. 落流水时生成幂等键（客户端 token 优先，兜底用雪花 ID），插入时若撞唯一索引就捕获 DuplicateKeyException，翻译成"您已领取"而非 500。

4. 跨实例互斥用 Redis 锁做"粗粒度挡枪"，DB 唯一约束做"细粒度兜底"：

SET lock:coupon:{userId}:{campaignId} 1 NX PX 3000

锁只挡 99% 的重复请求，真正的正确性始终由 DB 唯一索引保证——锁可以丢，数据不能错。

四、踩过的坑

synchronized 在多实例下等于没加，这是最反直觉的一点：单测、单机压测全过，一上集群就穿帮。
Redis 锁必须带过期时间。第一版忘了 PX，一次网络抖动后锁没释放，后续所有请求卡 30s 超时。
幂等键别用时间戳。同毫秒内并发会撞键，把"不同请求"误判成"重复请求"，反而漏发。
唯一索引冲突是业务正常分支，要专门捕获，不能让它冒泡成系统异常。
压测数据：8 实例、单实例 3 线程打 100 张券，改造前领出 107 张，改造后精确 100 张、多出的 7 条全部被唯一索引挡下并正确返回"已领取"。

五、结论与可复用清单

并发写场景，正确性的最后一道防线永远落在存储层的约束上，应用层锁只是性能优化。可复用清单：

凡是"判断 + 修改"，优先改写成一条带 WHERE 条件的原子 UPDATE，用 affectedRows 判定；
业务唯一性（一人一券、一单一次）必须落到唯一索引，不要只信代码；
幂等键要有确定性来源，别用时间戳；
分布式锁要带过期时间，且把它当"挡枪"而非"保证"；
压测要按"多实例 + 多线程"打，别拿单机结果当结论；
把"资源耗尽""重复操作"这类冲突显式建模成业务状态，而不是异常。

赞 3 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。