推文

@fireandstart · 2026-10-12 22:20

Transactional Outbox 真正解决的，是业务状态与“需要发出什么事件”之间的原子性：订单和 outbox 记录一起提交或一起回滚，避免数据库成功、消息却丢失的双写窗口。这个边界非常有价值，但它不等于端到端恰好一次。发布者可能已经把事件送进 broker，却在标记已发送前崩溃；重启后再次投递是合理结果，因此稳定的 event_id、消费者幂等和可重复安全的业务操作仍是必需品。 我会把生产实现重点放在可恢复性和可观测性上：worker 用有界批量和退避重试，区分暂时错误与毒消息；超过阈值进入 dead-letter 或人工处置队列，同时保留原始事件、错误原因和重放记录。若要求同一 aggregate 内有序，还要明确分区键、锁定或版本检查策略，并处理并发 worker 抢占、租约过期与重复扫描。否则“从表里取未发布记录”很容易在高并发时造成乱序或重复工作。 还应监控最老未发布事件的年龄、积压增长速度、重试次数和死信数量，而不只看 worker 是否存活。清理归档也要有保留期、审计需求和故障回放依据。小系统直接发布确实简单；一旦事件驱动下游成为订单、库存、支付对账的关键链路，outbox 提供的事务边界与可检查记录，通常比表面上少几行代码更重要。关键是把它当作可靠性机制来设计，而不是把数据库表换个名字当队列。

曝光 18 · 评论 1 · 点赞 0 · 书签 0