2. Outbox 模式原理：本地消息表设计、事件发布流程、幂等性保证与 CDC 关系

Outbox 模式是解决分布式事务中“本地事务与消息发送一致性”问题的经典方案。其核心思想是将“发送消息”这一操作，降级为在业务数据库内写入一条本地记录，从而将跨网络的消息发送转化为单机 ACID 事务。本节将深入剖析其设计细节与关键保障机制。

2.1 本地消息表设计

本地消息表（Outbox Table）是 Outbox 模式的基石。它通常与业务表位于同一个数据库中，通过本地事务保证业务操作与消息记录的原子性。

2.2 事件发布流程

事件发布流程分为“写入”与“投递”两个阶段，通过本地事务与异步轮询/CDC 解耦。

1. 业务操作 + 消息写入（本地事务）：业务服务在同一个数据库事务中，先执行业务 SQL（如创建订单），再向 Outbox 表插入一条状态为“待发送”的事件记录。两者要么同时成功，要么同时回滚。
2. 消息投递（异步进程）：一个独立的后台进程（Message Relay）或 CDC 组件，轮询 Outbox 表中 status = 0 的记录，将其发送到 Kafka 指定 Topic。
3. 状态更新：消息成功发送到 Kafka 并收到 Broker 确认后，将对应记录的 status 更新为“已发送”。若发送失败，则保留状态，等待重试。

2.3 幂等性保证

在分布式系统中，网络抖动或 Broker 重试可能导致消息重复投递。消费端必须实现幂等性，确保同一条消息被多次处理时，业务状态只变更一次。

以下是消费端幂等处理的伪代码示例：

// 消费端幂等处理示例
public void handleOrderCreated(Message message) {
    String messageId = message.getId();
    
    // 1. 检查幂等表
    if (idempotentService.isProcessed(messageId)) {
        log.info("消息已处理，跳过: {}", messageId);
        return;
    }
    
    // 2. 开启本地事务
    transactionTemplate.execute(status -> {
        // 3. 执行业务逻辑（如更新订单状态）
        orderService.updateStatus(message.getAggregateId(), "CONFIRMED");
        
        // 4. 记录已处理消息 ID
        idempotentService.recordProcessed(messageId);
        
        return null;
    });
}

2.4 Outbox 与 CDC 的关系

CDC（Change Data Capture，变更数据捕获）是 Outbox 模式的一种高效实现方式。传统 Outbox 依赖 Message Relay 轮询数据库，而 CDC 则通过解析数据库事务日志（如 MySQL Binlog、PostgreSQL WAL）来捕获 Outbox 表的新增记录，从而实时推送事件。