可靠发布专题 04｜Outbox：先写下要做的事，再安排执行

简短导语：在分布式系统中，业务写操作与对外异步投递往往无法在同一事务中原子完成。持久化 Outbox 模式把“要做的事”先写进可靠存储，再由独立投递进程负责发送，从而在很大程度上消除丢失消息的窗口期。本文说明模式的工作原理、落地步骤与常见误区，并提醒它不能替代的若干关键工作。

什么是持久化 Outbox（概念与核心价值）

持久化 Outbox 是一种设计模式：在执行业务事务时，除了修改业务表，还在同一事务内向一个“Outbox 表”插入待发送事件的记录。事务提交后，这条“要做的事”就持久化在系统的强一致存储中。随后，一个或多个独立的投递器（dispatcher）会轮询或订阅这个 Outbox，从中读取未发送或待重试的记录，尝试把事件投递到目标系统（消息中间件、第三方 API、邮件服务等），并在成功后更新 Outbox 状态或删除记录。

核心价值在于将“业务提交”和“投递意图持久化”放入同一原子边界，避免在事务提交与异步发送之间出现丢失或重复的不可控窗口。这样可以把系统的可恢复性从网络和中间件的不稳定性中解耦出来，使得失败恢复更确定、监控与补偿更可控。

Outbox 如何把业务提交和异步投递连接起来（流程与保证）

基本流程包括三步：写入、投递、确认。第一步，业务代码在数据库事务内写入业务数据并插入 Outbox 记录。第二步，投递器读取 Outbox 记录并实际发送事件（HTTP、AMQP、Kafka 等）。第三步，投递器在确认发送成功后标记该条记录为已发送或删除它。

这种设计提供的基本保证是“持久性之后至少一次投递”（persist-then-deliver），即在事务成功提交后，系统会保证事件可以最终被投递（在投递器正常运行或经人为干预后）。为了避免消费端重复处理，通常需要在消息中包含幂等 ID 或版本，要求消费方具备幂等处理能力。注意，Outbox 本身通常不能在跨多个独立数据库之间提供全局事务，它依赖于“业务修改与 Outbox 写入在同一数据库事务内”这一前提。

实施步骤与实践要点

• 设计 Outbox 表结构：包含作业 ID、类型、序列化载荷、目标地址或目标类型、状态（pending/sent/failed）、重试计数、可见时间（available_at）及创建/更新时间戳等字段。记录应尽量紧凑，避免单条过大。
• 在业务事务内写入 Outbox：务必保证业务变更与 Outbox 插入在同一数据库事务边界内。不要把 Outbox 写入放在事务外部或以异步回调方式执行。
• 投递器的可靠性：投递器需要支持重试策略、退避、幂等重放检测（对外部目标）与故障报警。投递器通常以单实例或多实例配合领导者选举运行，或者借助作业调度/队列框架来避免重复投递冲突。
• 幂等与去重：消费方必须支持幂等处理，或者投递方在消息中携带可去重的唯一 ID。即使 Outbox 能保证投递，网络重试或投递器并发也会导致重复发送。
• 清理与归档：长期保留 Outbox 会增长存储并影响扫描性能。需要设计删除策略、归档流程或分区策略以便定期清理已发送的记录。
• 监控与可观测性：对未发送、发送失败和重试次数异常的记录设置告警。投递失败的报警往往比投递成功更具意义，因为它提醒需要人为干预或回滚补偿。
• 性能与批量化：投递器应支持批量读取与批量发送，减少事务与网络开销，但批量化会带来部分失败时的部分重试复杂性，设计时要权衡。
• 事务隔离与可见性：不同数据库的隔离级别会影响读到 Outbox 的时间点。投递器应结合 available_at 字段避免读取到尚未对外暴露的事件。

Outbox 不能替代的工作与常见误区

Outbox 能减少消息丢失风险和协调复杂度，但它不是万灵药。常见误区和它不能替代的工作包括：

• 不能自动实现跨服务的全局一致性：如果业务变更涉及多个独立存储（两套数据库或外部系统），Outbox 只保证单库事务内的写入原子性，跨库一致性仍需补偿事务或分布式事务方案。
• 不能消除消费端幂等性需求：Outbox 提供“至少一次”投递语义，不能保证端到端的“恰好一次”，消费方必须设计幂等逻辑或去重机制。
• 不能替代消息中间件的所有功能：诸如高吞吐、分区一致性、跨消费者顺序保证、订阅模型和长期持久化由具体消息系统提供，Outbox 更像是“到消息系统的可靠出口”。
• 不能减少监控与运维工作：Outbox 带来额外的表增长、索引维护和投递器运行成本，仍需要监控、报警和容量管理。
• 不能避免语义复杂的补偿业务：如果投递失败导致客户体验不可接受，仅靠重试并不总能解决，可能需要人工或自动补偿流程（撤销、退款、重试逻辑外的业务回滚等）。
• 不能隐式解决隐私与合规问题：Outbox 中保存的事件可能包含敏感数据，必须审视保存期限、加密与访问控制，不能把它当成临时缓存随意写入。

常见误区示例与边界判断（如何决定是否适用）

当系统已经使用稳定的消息中间件并且业务允许在业务事务外发起消息时，Outbox 的收益可能有限。相反，对于下列场景，Outbox 通常是有力工具：数据库为主数据源；对丢失事件敏感但可以接受“至少一次”语义；系统希望避免复杂的两阶段提交或外部事务管理。

在判断是否引入 Outbox 时，关键考虑项包括：是否能把业务写入与 Outbox 写入放在同一事务；消费方是否能容忍重复；运维团队是否能承担额外表的维护与投递器的运行开销；是否有合适的监控和补偿流程。

Outbox 的价值在于把“意图持久化”变成可观测且可补救的实体，但它不替代正确的幂等设计、错误补偿策略与运维保障。

延伸阅读

• Celery Documentation: https://docs.celeryq.dev/en/stable/
• Redis Persistence Documentation: https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/