Transactional Outbox 模式：微服务中可靠事件发布指南
在现代分布式微服务架构中，事件驱动架构 (Event-Driven Architecture) 已经成为实现系统解耦与高扩展性的核心基石。微服务会定期触发领域事件（如 OrderCreated、PaymentProcessed）以同步状态变更。
然而，如何保证事件发布的绝对可靠性却是一个关键挑战：如何确保数据库更新与对应的事件发布要么同时成功，要么同时失败？
如果微服务先更新本地数据库（如 PostgreSQL 或 MySQL），再通过网络将消息发送至消息中间件（如 Apache Kafka 或 RabbitMQ），一旦发生网络抖动或服务崩溃，就会导致数据不一致。
为彻底解决这一难题，系统架构师普遍采用 Transactional Outbox 模式。
核心痛点：双写问题 (Dual-Write Problem)
在传统的双写实现中，微服务按顺序执行两个独立操作：
- 将业务数据写入本地数据库。
- 将事件消息发送至 Kafka 消息队列。
如果数据库事务提交成功，但随后由于网络故障导致 Kafka 发送失败，数据库中保存了订单，但下游服务却永远无法收到通知。结果：数据严重不一致。
什么是 Transactional Outbox 模式？
该模式充分利用了关系型数据库原生的 ACID 局部事务 特性。
微服务不再在 HTTP 请求生命周期内直接向网络发送消息，而是将事件 Payload 写入同一个数据库中的 Outbox 表，该写入操作与业务实体的更新处于 同一个本地事务 中。
数据库 ACID 机制保证了：业务数据与 Outbox 事件记录要么同时提交成功，要么同时回滚。
随后，由独立的后台进程（Message Relay）轮询 Outbox 表或通过 CDC 捕获变更，再异步发布至消息中间件。
消息中继策略：Polling Publisher 与 CDC (Debezium)
1. 轮询发布者 (Polling Publisher)
通过定时任务定期查询未处理的事件记录 (SELECT * FROM outbox_events WHERE processed = FALSE)，发送至 Kafka 后更新状态。
- 优点：实现简单，无需额外基础设施。
- 缺点：轮询存在延迟，对数据库产生额外的 SQL 查询开销。
2. 变更数据捕获 (Change Data Capture / Debezium)
Debezium 直接解析数据库底层事务日志（如 PostgreSQL WAL），实时捕获插入 Outbox 表的变更并直接投递至 Kafka。
- 优点：近乎零延迟、极高吞吐量，对数据库应用层无额外开销。
- 缺点：需要部署与维护 Kafka Connect 及 Debezium 组件。
总结
Transactional Outbox 模式 是分布式微服务架构中保障最终一致性与系统容错能力的重要设计模式。