1、课程导学：为什么需要 Outbox Pattern？它解决了什么问题？

大家好，我是这门课的主讲人。先聊点实在的——你做过分布式系统吗？如果做过，那你大概率遇到过这个场景：业务操作刚写完数据库，消息还没发出去，服务就挂了。等重启一看，数据库里订单状态是“已支付”，但消息队列里空空如也。下游系统压根不知道这回事。

嗯，这就是典型的“分布式事务不一致”问题。我当年第一次踩这个坑，是在一个电商订单系统里。用户付了钱，积分没加上，物流没通知，客服被投诉电话打爆了。从那以后，我就开始认真研究：到底怎么保证“数据库操作”和“发消息”这两个动作要么都成功，要么都失败？

答案之一，就是今天要讲的 Outbox Pattern。

1.1 一个经典问题：数据库与消息队列的不一致

先看一个最简单的场景。你的服务收到一个请求，要做两件事：

  1. 把订单状态更新为“已支付”
  2. 向消息队列发送一条“订单已支付”的事件

代码写出来大概是这样：

// 伪代码：传统做法
void processPayment(Order order) {
    order.setStatus("PAID");
    orderDao.update(order);          // 1. 写数据库
    messageQueue.send(event);        // 2. 发消息
}

看起来没问题？但仔细想想：

  • 如果第 1 步成功，第 2 步失败——数据库里订单已支付，消息没发出去。
  • 如果第 1 步成功，第 2 步成功，但消息队列响应超时——你以为失败了，实际上消息可能已经投递了。
  • 如果第 1 步成功，服务在发消息前崩溃——重启后，消息永远丢失。

说白了，数据库和消息队列是两个独立的系统，它们之间没有全局事务。你没法用一条 SQL 同时提交数据库和发消息。

我曾经在一个金融项目中见过更严重的后果：因为消息丢失，对账系统少算了一笔交易，最终导致资金差了几十万。虽然事后补上了，但那个通宵排查的夜晚，我至今记忆犹新。

1.2 Outbox Pattern 的核心思想

Outbox Pattern 的思路其实很简单：把“发消息”这个动作，也变成一次数据库写入。

具体做法是：

  1. 在业务数据库里建一张 outbox 表
  2. 业务操作和写 outbox 表放在同一个数据库事务里
  3. 另一个独立的进程（或线程）去读取 outbox 表，把消息发出去
  4. 发送成功后，删除或标记 outbox 表中的记录

你想想看，这样一来，业务操作和消息记录就在同一个事务里了。要么都提交，要么都回滚。消息的可靠性，从“网络传输”转移到了“数据库持久化”上——而数据库的可靠性，我们是有信心的。

// 伪代码：Outbox Pattern 做法
@Transactional
void processPayment(Order order) {
    order.setStatus("PAID");
    orderDao.update(order);                    // 1. 写业务表
    outboxDao.insert(new OutboxMessage(        // 2. 写 outbox 表
        aggregateId = order.getId(),
        eventType = "OrderPaid",
        payload = serialize(event)
    ));
}

注意看，这里没有发消息的代码。发消息的逻辑被移到了另一个地方——我们通常叫它 Message Relay 或 CDC（Change Data Capture）进程。

1.3 它解决了哪些问题？

我总结了一下，Outbox Pattern 主要解决三个核心痛点：

问题 传统做法 Outbox Pattern
消息丢失 写库成功，发消息时服务崩溃 消息先落库，Relay 进程保证最终投递
消息重复 发消息超时重试，导致重复投递 Relay 进程可做幂等控制，或业务端去重
分布式事务 需要 2PC、TCC 等复杂方案 用本地事务替代分布式事务，简单可靠

核心价值：Outbox Pattern 把“至少一次投递”的保证，从消息中间件转移到了数据库。数据库的 ACID 特性，成了消息可靠性的基石。

1.4 课程目标与前置知识

这门课的目标很明确：让你能独立设计、实现、部署一套基于 Outbox Pattern 的可靠消息系统。

具体来说，学完这门课你会掌握：

  • Outbox Pattern 的三种主流实现方式（轮询、CDC、事务日志追踪）
  • 如何与 Kafka、RocketMQ、RabbitMQ 等消息中间件集成
  • 幂等性、顺序性、去重等进阶话题的实战方案
  • 生产环境下的监控、告警、故障恢复策略

前置知识方面，我希望你具备：

  • 基本的 Java 或 Go 编程能力（课程示例以 Java 为主）
  • 了解关系型数据库（MySQL/PostgreSQL）的基本操作
  • 对消息队列有基础认知（知道什么是 producer/consumer）
  • 理解分布式系统的基本概念（CAP、一致性等）

如果你对上面这些还不太熟，也别慌。每章我都会从基础讲起，结合我自己的项目经验，把坑和弯路都指出来。

1.5 整体架构一览

下面这张图，展示了 Outbox Pattern 在 CDC 架构中的位置。你可以把它当作整门课的“地图”。

Outbox Pattern + CDC 整体架构 业务服务 写业务表 + Outbox 表 业务数据库 订单表 用户表 outbox 表 CDC 组件 Debezium / Canal / 轮询 消息队列 Kafka / RocketMQ 下游消费者 积分 / 物流 / 通知 关键流程： 1. 业务服务在同一个本地事务中写入业务表和 outbox 表 2. CDC 组件捕获 outbox 表的新增记录，发送到消息队列 3. 下游消费者从消息队列获取事件，执行各自的业务逻辑

从这张图你能看到，整个链路分三层：

  • 业务层：负责写业务数据和 outbox 记录，保证原子性
  • CDC 层：负责捕获 outbox 表的变化，把消息投递到消息队列
  • 消费层：下游系统订阅消息，做各自的事情

每一层都有它的设计要点和坑。比如 CDC 组件怎么保证不丢消息？消息投递到队列后，消费端怎么处理重复？这些我们都会在后面的章节逐一展开。

我个人习惯把 Outbox Pattern 看作“用空间换可靠性”的典型例子。多了一张 outbox 表，多了一个 CDC 进程，但换来了整个系统的数据一致性。这笔账，算下来是划算的。

好了，第一章就到这里。你已经知道了 Outbox Pattern 要解决什么问题，也看到了整体架构。接下来，我们会一步步深入每个环节的实现细节。

← 上一章 📖 返回目录 下一章 →