消息驱动的分布式事务：本地消息表 + 四大模式

TL;DR（30 秒扫完）

• 共同本质：MQ 是分布式事务最主流的落地手段（不是"有资源浪费"的替代品）
• 共同前提：①消费端必须幂等（MQ 至少投递一次）②必须有对账/补偿兜底
• 模式 1 本地消息表（Outbox）：业务 SQL + 写消息表在同一本地事务，定时扫表投递；灵魂是"业务成功=消息存在"
• 模式 2 事务消息（RocketMQ）：half message + 回查机制，MQ 内置保证"业务与消息强绑定"
• 模式 3 可靠消息 + 幂等消费：Producer acks=all + 重试 + Consumer 业务唯一键幂等；最简单但最弱（业务与消息不绑定）
• 模式 4 Kafka 事务（2.5+）：KafkaTransaction 跨 topic 原子写 + offset 一并提交；依赖幂等 Producer + 事务 Producer + read_committed
• 实现的是最终一致：不是强一致，与 2PC/XA 的本质差异

关键结论

完整讲解（费曼四步）

STEP 1 · 概念

STEP 2 · 大白话

• 业务成功 → 消息一定存在（同一本地事务，要么都成功要么都失败）
• 消息存在 → 一定能被扫表投递（定时任务保证）
• 消息投递 → 消费端一定能处理（消费端幂等保证）

STEP 3 · 底层

核心思想

• 本质：把"分布式事务"拆解为"本地事务 + 异步消息"
• 核心思想：业务数据和消息在同一本地事务里写入，保证"业务成功 = 消息存在"
• 为什么能解决分布式事务：
• 业务成功 → 消息一定存在（同一事务，要么都成功要么都失败）
• 消息存在 → 一定能被扫表投递（定时任务保证）
• 消息投递 → 消费端一定能处理（消费端幂等保证）

完整状态机

INIT (本地事务已提交，消息待发送)
  ↓ 定时扫表 + MQ 投递
SENT (消息已发送，等待消费)
  ↓ 消费端 ACK
DELIVERED (消费端已确认)
  ↓ 业务处理完成
ACKED (业务已完成)

核心组件

• 消息表：存业务消息（msg_id、biz_id、payload、status、retry_count、next_retry_time）
• 扫表任务：定时扫描 status=INIT 的消息，发 MQ，更新状态
• 消费端：消费 MQ 消息，幂等处理业务，更新消息状态

可靠性保证（三大目标）

与 RocketMQ 事务消息对比

工程实现要点

• 消息表字段：msg_id（唯一键）、status、retry_count、next_retry_time、create_time
• 扫表 SQL：SELECT * FROM msg_table WHERE status = 'INIT' AND next_retry_time < NOW() LIMIT 100 FOR UPDATE SKIP LOCKED
• 消费端幂等：基于 msg_id 建唯一键，重复消息直接返回成功
• 死信队列：超过最大重试次数的消息转入死信队列，人工处理

消息表 DDL 示例

CREATE TABLE local_message (
    msg_id BIGINT PRIMARY KEY,        -- 消息唯一 ID（业务单号）
    biz_id VARCHAR(64) NOT NULL,      -- 业务 ID
    topic VARCHAR(128) NOT NULL,      -- MQ Topic
    payload TEXT,                      -- 消息内容（JSON）
    status ENUM('INIT','SENT','DELIVERED','ACKED') DEFAULT 'INIT',
    retry_count INT DEFAULT 0,
    next_retry_time DATETIME,
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    UNIQUE KEY uk_msg_id (msg_id),
    KEY idx_status_retry (status, next_retry_time)
);

扫表任务示例

@Scheduled(fixedDelay = 1000)
public void scanAndSend() {
    List<Message> messages = messageMapper.selectInitMessages(100);
    for (Message msg : messages) {
        try {
            // 发送 MQ 消息
            mqProducer.send(msg.getTopic(), msg.getPayload());
            // 更新状态为 SENT
            messageMapper.updateStatus(msg.getMsgId(), "SENT");
        } catch (Exception e) {
            // 更新重试次数和下次重试时间
            messageMapper.updateRetry(msg.getMsgId(), 
                msg.getRetryCount() + 1, 
                calculateNextRetryTime(msg.getRetryCount()));
        }
    }
}

消费端幂等示例

public void consume(Message msg) {
    // 基于 msg_id 检查是否已消费
    if (consumeRecordMapper.existsByMsgId(msg.getMsgId())) {
        return; // 已消费，直接返回成功
    }
    
    try {
        // 业务处理
        doBusiness(msg);
        // 记录消费记录（幂等键）
        consumeRecordMapper.insert(msg.getMsgId());
        // 更新消息状态为 DELIVERED
        messageMapper.updateStatus(msg.getMsgId(), "DELIVERED");
    } catch (Exception e) {
        throw new RetryException(e); // 消费端重试
    }
}

STEP 4 · 简化

一句话总结：本地消息表的灵魂是"本地事务+异步消息"——业务方在本地事务里把消息写进去，靠定时扫表和消费端幂等保证最终一致。

常见误区

延伸追问

速查表

关联题目

• ⚠️ 《如何基于本地消息表实现分布式事务？》— 2026-09-23 Round 2 Q7, ⭐⭐⭐, 未明确"同一本地事务"和状态机
• ⚠️ 《如何基于 MQ 实现分布式事务》— 2026-10-10 Round 1 Q5, ⭐⭐, 把 MQ 与分布式事务当对立概念，四大模式完全没提

关联知识

• 分布式事务概览与模式分类
• TCC 与三大坑
• 跨境支付方案设计