在电商、计费等分布式系统中，"扣库存生成计费单"和"向第三方系统推送计费单"是两个典型场景，其一致性选择需结合业务容忍度和技术实现成本综合考虑：

---

一、扣库存生成计费单场景 1. 一致性要求 • 核心矛盾：高并发下的系统性能 vs 库存准确性

• 业务容忍度：允许短暂超卖/少卖（如秒杀场景需最终一致），但最终需保证不超卖（如实际库存≥0）

2. 方案选择

方案	适用场景	技术实现	引用依据
最终一致性	高并发秒杀、促销活动	- 预扣Redis库存，支付成功后通过MQ异步扣减MySQL库存 - 失败时回退Redis库存，补偿MySQL库存
强一致性	低并发普通商品购买	- 数据库乐观锁（版本号/库存数） - 事务内执行扣减与计费单生成，失败则整体回滚

3. 典型实现 • Redis预扣+异步落库（最终一致）：

用户下单时先扣减Redis缓存库存，生成"预订单"；支付成功后，通过MQ触发MySQL库存扣减和计费单生成。若MySQL扣减失败，通过补偿任务返还Redis库存并取消预订单。 • 数据库行锁+本地事务（强一致）：

使用SQL语句UPDATE inventory SET stock = stock - 1 WHERE stock >= 1配合事务，确保扣减与计费单生成原子性。

---

二、向第三方系统推送计费单场景 1. 一致性要求 • 核心矛盾：计费准确性 vs 第三方系统可用性

• 业务容忍度：支付成功后必须保证计费单最终到达第三方（如银行、物流系统），但允许短暂延迟

2. 方案选择

方案	适用场景	技术实现	引用依据
最终一致性	非核心链路（如日志上报）	- 本地事务成功后，通过MQ异步推送 - 消费失败时依赖MQ重试机制和人工对账补偿
强一致性	金融交易、核心计费	- TCC模式：Try阶段预提交资源，Confirm阶段正式推送，Cancel阶段回滚 - 分布式事务协调器

3. 典型实现 • MQ异步推送+本地消息表（最终一致）：

本地事务提交后，将计费单写入本地消息表，通过定时任务或MQ消费者推送第三方，失败时重试至成功。 • TCC模式（强一致）：

• Try：预留计费单状态为"待推送"，调用第三方预接口

• Confirm：更新状态为"已推送"，第三方正式处理

• Cancel：状态回滚为"取消"，通知第三方撤销预操作。

---

三、关键差异总结

维度	扣库存生成计费单	推送第三方计费单
核心风险	超卖/少卖导致资损	计费遗漏/重复导致资金错账
典型一致性选择	最终一致性（高并发） 强一致性（普通场景）	强一致性（金融场景） 最终一致性（非核心）
技术成本	需设计Redis+MQ+补偿任务	需实现分布式事务或可靠消息投递

---

四、选型建议

1. 扣库存场景：优先采用最终一致性，通过分层设计（缓存预扣+异步落库）应对高并发，配合库存校对任务兜底。
2. 推送计费单场景：金融类交易强制使用强一致性（如TCC），非核心业务可接受最终一致性，但需保证至少一次投递和幂等处理。

通过分层策略（如缓存层最终一致 + 数据库层强一致）和补偿机制（MQ重试、人工对账），可在业务需求与技术成本间取得平衡。