分布式事务最终一致性：本地消息表与事务消息选型

强一致是奢侈品，最终一致是日用品

微服务拆分后，跨服务写操作（下单扣库存加积分）不可能都塞进一个数据库事务。XA/2PC 性能与可用性代价太高，绝大多数业务的正确选择是最终一致性：允许短暂的不一致，但保证系统最终收敛到正确状态。落地的两个主流方案是本地消息表与事务消息，选错方案是很多「数据不一致」事故的根因。一、本地消息表：简单可靠的默认选择

原理：业务操作与「待发布消息」在同一个本地事务里落库，再由后台任务扫描消息表投递到 MQ，投递成功后标记完成。

1. 优点：不依赖特定 MQ 特性，任何数据库 + 任何消息队列都能实现；消息与业务强绑定，绝不丢；实现一天可上线；
2. 缺点：业务库多一张消息表与扫描压力；投递有秒级延迟；扫描任务要处理并发抢占（多实例部署时用 FOR UPDATE SKIP LOCKED 或分布式锁）；
3. 适用：绝大多数中小规模业务、消息量中等（日均百万以内）、团队没有强中间件运维能力的场景——它是「默认选项」。

二、事务消息：高吞吐的进阶方案

以 RocketMQ 事务消息为代表：先发半消息（half message）→ 执行本地事务 → 提交/回滚消息 → Broker 定时回查本地事务状态兜底。

1. 优点：无本地消息表的扫描开销，吞吐高；回查机制保证「本地事务与消息发送」的原子性；
2. 缺点：绑定特定 MQ（RocketMQ/Kafka 无原生事务消息）；回查逻辑要求业务实现「事务状态查询」接口——这个接口本身要做幂等与防重；排查问题链路更长；
3. 适用：消息量大（日均千万级）、已深度使用 RocketMQ、有中间件运维能力的团队。

三、消费端才是最终一致性的半场

生产端保证「消息必达」只是前半场，消费端要保证「必达且不重复处理」：

1. 消费幂等：按业务键去重（详见幂等设计三板斧：唯一约束 + 条件更新 + Redis 前置去重）；
2. 死信与补偿：消费失败进重试队列，超过阈值进死信，死信要有告警与人工/自动补偿通路——没有死信处理的最终一致性是「假装一致」；
3. 对账兜底：核心链路（资金、库存）每日跑离线对账，发现不一致自动或人工修复。对账是最终一致性的最后防线，任何方案都不能省。

四、选型决策树

消息量 < 日均百万或团队小 → 本地消息表；深度 RocketMQ + 大消息量 → 事务消息；无论哪个，消费幂等 + 死信告警 + 定期对账三件套必须齐全。

最终一致性的工程本质：把「一次大事务」拆成「多次可重试的小事务」，每一步都幂等、可追溯、可补偿。做到这三点，数据不一致就从「生产事故」降级为「对账工单」。