暗无天日 ·

读：双写问题——@Transactional 给不了的跨系统一致性

💡 原文中文，约3900字，阅读约需10分钟。

📝

内容提要

双写问题源于分布式系统中数据库与消息队列无法共享事务协调。解决方案包括事务性发件箱、变更数据捕获、事件溯源和自己监听自己。核心思想是将双写转为单写加异步分发，以确保数据一致性。选择合适模式需考虑复杂度和场景需求。

🎯

🔎

双写问题的本质在于分布式系统中，数据库与消息队列之间缺乏事务协调。传统的 @Transactional 只能保证数据库操作，而无法确保消息队列的状态一致性。这种物理约束使得在一个事务中同时处理数据库和消息队列变得不可能，导致数据不一致的风险。

在解决双写问题时，选择合适的模式至关重要。Transactional Outbox 适合大多数场景，复杂度低且易于实现。而 CDC 和 Event Sourcing 虽然能提供更高的灵活性和一致性，但其复杂性和维护成本也相应增加。团队需根据具体需求和技术栈做出明智选择。

虽然 XA 分布式事务提供了一种理论上的解决方案，但其在现代架构中的应用受到限制。由于其引入的协调者机制导致的延迟和脆弱性，使得在高并发和事件驱动的环境中难以有效实施。因此，开发者应谨慎考虑其适用性。

❓

双写问题是指在分布式系统中，数据库和消息队列无法共享事务协调，导致数据不一致的情况。

传统的 @Transactional 只能保证数据库操作，无法协调消息队列，因为它们是独立的系统，没有共享的事务协调器。

解决双写问题的四种模式包括：事务性发件箱、变更数据捕获、事件溯源和自己监听自己。

事务性发件箱是一种模式，在同一数据库事务中写入一个 outbox 表，后台进程定期扫描并发送未发送的事件。

事件溯源取消了业务数据库，只保存事件，当前状态由回放事件历史得出，而事务性发件箱依赖于数据库的 outbox 表。

选择合适的模式需考虑复杂度和场景需求，Transactional Outbox 适合大部分场景。

🏷️