高并发大促下库存扣减失败的补偿必须快、准、可追溯、不扰主链路：采用异步扫描+状态机驱动，三元状态标识（pending/confirmed/done），幂等回滚，超时熔断，分级降级。
高并发大促场景下，库存扣减失败不是“要不要补偿”的问题，而是“补偿必须快、准、可追溯、不扰主链路”的问题。业务层设计高阶异常补偿器，核心目标不是兜底重试，而是让失败请求快速退出、资源即时回收、状态精准对齐，避免因单次失败引发线程阻塞、连接池耗尽或下游雪崩式停顿。
补偿器必须与主流程解耦，且自带超时熔断
主扣减流程（如 Redis 预扣 + MQ 发送）一旦抛出非业务异常（网络抖动、序列化失败、MQ 拒绝投递），不能同步重试或等待回调。补偿器应独立运行，通过异步扫描+状态机驱动：
- 失败消息自动落库（含 request_id、product_id、count、timestamp、error_code），表带唯一索引防止重复插入
- 补偿服务每 500ms 扫描一次 2 秒前未标记“已处理”的失败记录，单次最多拉取 100 条
- 每条记录执行带 800ms 超时的原子补偿操作（如 Redis 库存回滚 + 清除预占标记），超时即标记为“补偿超时”，交由人工通道介入
- 连续 3 次补偿失败的记录，自动触发降级开关：暂停对该商品 ID 的所有新预扣请求，避免故障放大
状态闭环是补偿生效的前提，不能只靠“成功/失败”二值
传统补偿常卡在“到底扣没扣成功”——Redis 扣了但 MQ 没发？MQ 发了但 DB 没写？高阶补偿器必须引入中间态标识：
- 预扣时写入三元状态：pre_deduct:pending（Redis Hash Field）
- MQ 投递成功后，消费端更新为：pre_deduct:confirmed
- DB 最终扣减完成，再更新为：pre_deduct:done
- 补偿器只处理 pending 状态超过 3 秒的记录，直接执行 Redis 回滚 + 删除该 field，不查 DB、不等 MQ，秒级释放资源
补偿动作本身要幂等、可重入、带来源追踪
避免补偿器变成新的故障源。关键约束有三条：
- 所有补偿操作加唯一幂等 key（如 compensate:{request_id}:{action}），Redis SETNX + 过期时间 10s，确保同一补偿动作不会并发执行
- 回滚库存时，用 INCR 原子指令，并校验当前值是否 ≥0；若已为负，说明可能被其他补偿误操作，立即告警而非强行加回
- 每次补偿日志必须包含 trace_id、补偿触发原因（扫描？手动触发？）、原始错误堆栈片段、执行耗时，便于定位是网络抖动还是缓存穿透导致的批量失败
主动降级比被动重试更平滑
当某商品在 1 分钟内补偿失败率 >15%，补偿器不应继续硬扛，而应启动分级降级：
- L1（自动）：对该商品关闭 Redis 预扣，所有请求直走 DB 乐观锁（牺牲吞吐保一致性）
- L2（半自动）：若 DB 层也出现大量 version 冲突，则切到“排队模式”——返回“正在排队”，前端轮询，把瞬时压力摊到 30 秒窗口
- L3（人工）：触发钉钉告警并附上最近 10 条失败详情，由值班 SRE 判断是否需临时扩容 Redis 或重置库存缓存
