3. Outbox 模式原理：将业务操作与消息发送解耦，通过本地事务写入 Outbox 表

在微服务架构中，当业务操作（如订单创建、用户注册）与消息发送（如通知下游服务、触发事件）需要保持一致性时，传统做法往往面临分布式事务的难题。Outbox 模式提供了一种优雅的解决方案：将业务操作与消息发送解耦，利用本地事务保证两者的原子性。

3.1 核心思想：本地事务的“一石二鸟”

Outbox 模式的核心在于，业务操作和消息记录在同一个本地事务中完成。业务数据写入业务表的同时，将待发送的消息写入一个专门的“发件箱”（Outbox）表。这样，要么业务数据和消息同时写入成功，要么同时回滚，从根本上避免了“业务成功但消息丢失”或“消息发送但业务失败”的不一致问题。

3.2 标准流程：三步走

一个标准的 Outbox 模式流程包含以下三个关键步骤：

1. 本地事务写入： 在业务服务中，开启一个本地数据库事务。在该事务内，同时执行两条 SQL：一条写入业务表（如 orders），另一条写入 Outbox 表（如 outbox_events）。
2. 异步消息发布： 一个独立的“消息发布器”（Message Relay）进程或线程，定期轮询 Outbox 表，读取状态为“待发送”的消息记录。
3. 发送与确认： 消息发布器将消息发送到消息队列（如 Kafka、RabbitMQ），并在发送成功后，更新 Outbox 表中对应记录的状态为“已发送”或直接删除该记录。

3.3 核心组件与数据模型

Outbox 模式涉及几个核心组件，其数据模型设计也至关重要。

3.3.1 核心组件

3.3.2 Outbox 表结构示例

一个典型的 Outbox 表包含以下字段：

CREATE TABLE outbox_events (
    id              UUID PRIMARY KEY,          -- 全局唯一标识
    aggregate_id    VARCHAR(255) NOT NULL,     -- 业务聚合根 ID (如订单ID)
    aggregate_type  VARCHAR(100) NOT NULL,     -- 业务聚合根类型 (如 "order")
    event_type      VARCHAR(255) NOT NULL,     -- 事件类型 (如 "OrderCreated")
    payload         JSONB NOT NULL,            -- 事件体 (JSON 格式)
    created_at      TIMESTAMP NOT NULL,        -- 创建时间
    status          VARCHAR(20) DEFAULT 'PENDING', -- 状态: PENDING, SENT, FAILED
    version         INT DEFAULT 1,             -- 乐观锁版本号
    PRIMARY KEY (id)
);
-- 为轮询效率创建索引
CREATE INDEX idx_outbox_status_created ON outbox_events (status, created_at);

3.4 解耦的实质：从“同步发送”到“异步持久化”

Outbox 模式的核心价值在于改变了消息发送的时机和方式。下图清晰地展示了这种解耦关系：

3.5 与传统方式的对比

为了更直观地理解 Outbox 模式的优势，我们将其与传统的“先业务后消息”和“2PC”方案进行对比：

3.6 在鉴权拦截场景中的价值

在分布式事务鉴权拦截的开发中，Outbox 模式的价值尤为突出。例如，当用户发起一个需要鉴权的操作（如“创建订单”）时：

• 业务操作： 创建订单记录。
• 鉴权事件： 需要发送一个“鉴权通过”或“鉴权失败”的事件，用于审计、风控或触发后续流程。

使用 Outbox 模式，我们可以将“创建订单”和“写入鉴权事件”放在同一个本地事务中。即使消息队列暂时不可用，鉴权事件也不会丢失，消息发布器会在恢复后自动重试。这确保了鉴权行为的可追溯性和系统状态的一致性。