多数据源事务的最终一致：本地消息表能否替代分布式事务

订单库扣了库存，库存库却更新失败；支付已经成功，积分和优惠券却迟迟不到账。只要系统从单库走向多数据源，这类问题就会反复出现。于是团队里常有两种声音：一种说上分布式事务，一种说加本地消息表就够了。后者听起来更轻、更可控，但它真的能替代分布式事务吗？

本地消息表的本质：把分布式事务拆成可靠消息

本地消息表的核心思路并不复杂：在业务数据所在的同一个数据库中，用同一个本地事务写入业务数据和一条“待发送消息”。随后由异步任务或独立线程把消息投递到消息队列，下游消费成功后进行确认或删除。这样，本地事务保证了“业务成功”和“消息一定存在”是一致的，剩下的就是至少一次投递和消费端幂等。

它解决的其实不是“多个数据源同时提交”的问题，而是把一次跨库写操作，转化为“一个本地事务 + 一条可靠消息 + 下游最终执行”。这更像是一种最终一致性架构，而不是传统意义上的分布式事务。

它替代不了什么

如果业务要求多个数据源在同一个事务里原子生效，本地消息表无能为力。比如一个请求必须同时写 A 库和 B 库，B 库失败后要立刻回滚 A 库，这种强一致和隔离性需求，本地消息表给不了。它只能保证 A 库提交后，消息最终被下游处理，中间存在可见的延迟和中间态。

此外，它也无法天然解决并发隔离、脏读、幻读等问题。分布式事务方案如 XA/2PC 提供强一致，但性能和可用性代价高；TCC 通过 Try-Confirm-Cancel 实现业务级两阶段，侵入性强但可控；Saga 用一系列本地事务加补偿来换最终一致；事务消息则把消息投递和本地事务绑定在消息中间件层面。本地消息表只是这些方案中的一种，且偏向最终一致。

多数据源下的三个硬约束

第一，本地消息表必须和业务数据在同一个数据源。如果消息表和业务表分属不同库，那“本地事务”就不本地了，原子性无从谈起。

第二，消费端必须幂等。至少一次投递意味着重复消息不可避免。去重表、唯一键、版本号、状态机，至少要有一种机制兜底。

第三，必须有补偿和对账。消息可能丢失、消费可能失败、顺序可能错乱。定时扫描、死信处理、人工对账，这些不是可选项，而是生产级最终一致的标配。

选型不是二选一，而是看一致性边界

一个务实的判断标准是：业务能否接受中间态？能否在失败后补偿？读路径能否容忍延迟？如果答案都是“能”，本地消息表往往比分布式事务更简单、更可用。如果答案里有“不能”，那就别用最终一致去硬扛强一致需求。

更合理的做法是分层：核心链路尽量收敛到单库，或者用 TCC/Saga 处理跨库写；非核心、可补偿、可延迟的链路，用本地消息表或事务消息做最终一致。多数据源本身也可以通过单元化、数据同步、服务合并来减少，而不是一上来就找框架。

本地消息表不是分布式事务的替代品，它是最终一致性的一种工程实现。它把问题从“跨库原子提交”转化为“可靠消息 + 幂等 + 补偿”，适合能接受最终一致的场景。真正的替代与否，取决于你的业务能否容忍中间态，而不是取决于技术名词有多新。