真正可靠的优惠券扣减失败补偿方案是嵌入业务层的轻量状态机补偿器，绑定业务单据ID和幂等键，分层识别失败类型，闭环执行查状态、原子回写、触发通知，并通过compensation_task表实现生命周期管理。
高并发大促中，优惠券扣减失败不能只靠“重试”或“人工修复”。真正可靠的方案，是在业务层嵌入一个轻量、可追踪、带状态机的异常补偿器，它不依赖外部调度，而是和主流程共生，自动识别失败、记录上下文、触发修正动作。
补偿器必须绑定业务唯一标识和操作幂等键
每次优惠券扣减请求，必须携带两个关键字段：业务单据ID（如订单号/领券请求ID） 和 幂等键（如 user_id + activity_id + timestamp_md5）。补偿器靠幂等键判断是否已处理过该次操作；靠单据ID关联原始上下文（比如优惠券ID、数量、用户信息），避免“补错券”或“重复补”。不要用时间戳或随机UUID做幂等依据——它们无法防重放、难追溯。
失败识别要分层：接口级失败 ≠ 业务级失败
补偿器需区分三类失败：
- 网络超时或服务不可用：立即进入延迟重试队列（如 RocketMQ 延迟等级 Level 3，约30秒后重投）
- 业务校验拒绝（如“券已领完”“用户不符合门槛”）：标记为终态失败，不补偿，仅记录审计日志
- 执行中异常（如 Redis 扣减成功但 DB 更新失败、MQ 发送失败）：这是补偿器核心盯防对象，必须落库记录“待补偿任务”，含完整请求快照和失败堆栈
补偿动作必须自带状态闭环与反向保护
补偿不是简单“再调一次扣减接口”。它要满足三个条件：
- 先查当前券状态：若已是“已使用”，跳过补偿，防止超发
- 再执行原子回写：用 Lua 脚本在 Redis 中校验+扣减，同时写入 DB 的 coupon_usage 表（带 version 字段）
- 最后触发通知：成功则发消息更新用户权益视图；失败则升级告警，并自动转入人工复核队列（带失败原因标签）
补偿任务要有生命周期管理
所有待补偿任务必须进一张轻量表（如 compensation_task），字段至少包括：task_id、biz_type（"coupon_deduct"）、biz_id、status（pending/executing/success/failed）、retry_count、next_retry_at、fail_reason。配合定时扫描（每分钟1次）+ 延迟消息兜底（如首次失败后30秒发延迟消息），避免单点卡死。超过3次失败的任务，自动冻结并推送至运营看板。
