MQ 分布式事务实践

概述

在微服务架构下，一个业务操作往往涉及多个服务的数据变更，分布式事务成为绕不开的难题。本文介绍三种基于 MQ 的分布式事务方案：本地消息表、RocketMQ 事务消息、Saga 模式，并给出 Go 代码实现。

正文

分布式事务问题

以电商下单为例，一个"创建订单"操作至少涉及三个服务：

订单服务：创建订单记录
库存服务：扣减库存
支付服务：发起支付

这三个操作需要保证最终一致性——不能出现订单创建了但库存没扣、或者库存扣了但支付没发起的情况。传统的 2PC/XA 方案在微服务架构下性能差、可用性低，MQ 成了更实用的选择。

[!question] 为什么 2PC 在微服务架构下不受欢迎？它的问题仅仅是性能差吗？

方案一：本地消息表 + MQ

这是最经典、最可靠的方案，核心思想是利用本地事务保证业务操作和消息写入的原子性。

graph TD
    A["开始本地事务"] --> B["写入业务数据 - 订单表"]
    B --> C["写入消息表 - 同一事务"]
    C --> D["提交事务"]
    D --> E["后台任务轮询消息表"]
    E --> F["发送消息到MQ"]
    F --> G["消费端处理 - 扣减库存"]
    G --> H["消费端幂等校验"]
    H --> I["更新消息状态为已完成"]

核心逻辑分三步：

写入阶段：在同一个数据库事务中，写入业务数据和消息表。这保证了两者的原子性。
发送阶段：后台任务（定时器或 binlog 监听）扫描消息表中未发送的记录，投递到 MQ。
消费阶段：消费端处理消息并做幂等校验（比如用消息 ID 去重），处理成功后回调更新消息状态。

// 本地消息表方案的核心实现
type MessageRecord struct {
    ID        string
    Topic     string
    Payload   string
    Status    string // pending, sent, completed
    RetryCount int
    CreatedAt time.Time
}

// 1. 本地事务：写业务数据 + 消息表
func CreateOrder(db *sql.DB, order Order, msg MessageRecord) error {
    tx, _ := db.Begin()
    defer tx.Rollback()

    // 写入订单
    _, err := tx.Exec("INSERT INTO orders ...", order.ID, order.Amount)
    if err != nil { return err }

    // 写入消息表，同一事务
    _, err = tx.Exec("INSERT INTO outbox_messages ...",
        msg.ID, msg.Topic, msg.Payload, "pending")
    if err != nil { return err }

    return tx.Commit() // 原子提交
}

// 2. 后台任务：轮询发送
func PollAndSend(db *sql.DB, producer MQProducer) {
    rows, _ := db.Query(
        "SELECT id, topic, payload FROM outbox_messages WHERE status='pending' LIMIT 100")
    for rows.Next() {
        var msg MessageRecord
        rows.Scan(&msg.ID, &msg.Topic, &msg.Payload)
        if err := producer.Send(msg.Topic, msg.Payload); err == nil {
            db.Exec("UPDATE outbox_messages SET status='sent' WHERE id=?", msg.ID)
        }
    }
}

// 3. 消费端：幂等处理
func HandleInventoryMsg(ctx context.Context, msg Message) error {
    // 幂等检查：消息是否已处理过
    exists, _ := db.Query("SELECT 1 FROM processed_messages WHERE id=?", msg.ID)
    if exists { return nil } // 已处理，跳过

    // 扣减库存
    err := inventoryService.Deduct(msg.ProductID, msg.Quantity)
    if err != nil { return err }

    // 记录已处理
    db.Exec("INSERT INTO processed_messages (id) VALUES (?)", msg.ID)
    // 回调更新消息状态
    db.Exec("UPDATE outbox_messages SET status='completed' WHERE id=?", msg.ID)
    return nil
}

方案二：事务消息（RocketMQ）

RocketMQ 原生支持事务消息，比本地消息表更优雅。核心流程分三个阶段：

阶段一：发送半消息

Producer 先发送一条"半消息"（Half Message）到 Broker。这条消息对 Consumer 不可见。

阶段二：执行本地事务

Producer 收到半消息发送成功的确认后，执行本地业务逻辑（比如创建订单）。

阶段三：提交或回滚

根据本地事务的执行结果，向 Broker 发送 Commit（消息对 Consumer 可见）或 Rollback（丢弃消息）。

如果 Broker 没有收到 Commit/Rollback（比如 Producer 宕机），Broker 会主动回查Producer 的本地事务状态。这个回查机制是 RocketMQ 事务消息的精髓。

// RocketMQ 事务消息流程
func CreateOrderWithTxMsg(producer TxProducer, order Order) error {
    // 1. 发送半消息
    msg := mq.NewMessage("order-topic", order.ToJSON())
    result, err := producer.SendMessageInTransaction(msg, func(localMsg *mq.Message) mq.LocalTransactionState {
        // 2. 执行本地事务
        err := orderService.Create(order)
        if err != nil {
            return mq.RollbackMessage // 回滚，消息丢弃
        }
        return mq.CommitMessage // 提交，消息可见
    })
    return err
}

// 3. 事务回查（由 Broker 触发）
func CheckLocalTransaction(msg *mq.Message) mq.LocalTransactionState {
    orderID := extractOrderID(msg)
    order, err := orderService.Get(orderID)
    if err != nil {
        return mq.Unknown // 状态未知，稍后再查
    }
    if order.Status == "created" {
        return mq.CommitMessage
    }
    return mq.RollbackMessage
}

方案三：Saga 模式 + MQ

Saga 适用于长事务场景，核心思想是将一个大事务拆成一系列小事务，每个小事务有对应的补偿操作。

Saga 有两种协调方式：

编排式（Orchestration）：由一个中心协调器控制流程，按顺序调用各服务。
协同式（Choreography）：各服务通过事件驱动协作，没有中心协调器，通过 MQ 传递事件。

// Saga 协同式：通过事件驱动
type OrderSagaEvent struct {
    Type    string // OrderCreated, InventoryReserved, PaymentCompleted
    OrderID string
    Data    interface{}
}

// 订单服务：创建订单后发布事件
func CreateOrder(order Order) {
    db.Save(order)
    mq.Publish("order-events", OrderSagaEvent{
        Type: "OrderCreated", OrderID: order.ID, Data: order,
    })
}

// 库存服务：监听订单事件，扣减库存
func OnOrderCreated(event OrderSagaEvent) {
    err := inventory.Reserve(event.Data.(Order).Items)
    if err != nil {
        // 库存不足，发布失败事件触发补偿
        mq.Publish("order-events", OrderSagaEvent{
            Type: "InventoryReservationFailed", OrderID: event.OrderID,
        })
        return
    }
    mq.Publish("order-events", OrderSagaEvent{
        Type: "InventoryReserved", OrderID: event.OrderID,
    })
}

// 订单服务：监听库存失败事件，补偿取消订单
func OnInventoryReservationFailed(event OrderSagaEvent) {
    orderService.Cancel(event.OrderID) // 补偿操作
    mq.Publish("order-events", OrderSagaEvent{
        Type: "OrderCancelled", OrderID: event.OrderID,
    })
}

三种方案对比

维度	本地消息表	RocketMQ 事务消息	Saga + MQ
一致性保证	最终一致	最终一致	最终一致
性能影响	中（轮询 + DB 写入）	低（Broker 端处理）	低（事件驱动）
实现复杂度	中	低（SDK 支持）	高（需设计补偿链）
适用场景	通用场景	RocketMQ 技术栈	长事务、跨多服务
数据一致性边界	同一 DB 事务	本地事务 + MQ	跨多个独立服务

[!question] 本地消息表模式下，如果消息发送成功但消费端处理失败，如何实现最终一致性？提示：想想消息表的状态管理和重试机制。

7.7 KiB Raw Blame History Unescape Escape