分布式事务有哪些解决方案？

详细解析#

2PC 和 3PC#

阶段一（准备）：协调者 ──prepare──> 参与者 A、B
               参与者执行事务、写 redo/undo 日志、锁住资源，但不提交，回复 yes/no
阶段二（提交）：全部 yes ──commit──> 所有参与者提交
               任一 no 或超时 ──rollback──> 所有参与者回滚

问题：

• 同步阻塞：从准备到提交，参与者一直持有锁，并发能力差
• 协调者单点：参与者回复 yes 后协调者宕机，参与者不知道该提交还是回滚，只能一直等
• 数据不一致：阶段二只有部分参与者收到 commit 时网络断了，各节点状态不一致

3PC 在中间加了一个预提交阶段，并让参与者在超时后自行提交，减少了阻塞；但网络分区时仍可能不一致，实际很少使用。MySQL 支持 XA 事务，Seata 的 AT 模式在 2PC 思路上做了改进：一阶段就提交本地事务、释放本地锁，靠自动生成的 undo 日志在需要时回滚。但它并不是没有锁：本地提交前要先拿到相关行的全局锁，并一直持有到全局事务结束，防止别的全局事务写同一行；默认的全局隔离级别是读未提交，需要读已提交时用 SELECT ... FOR UPDATE。

TCC#

把一个操作拆成三个业务接口，以扣库存为例：

TCC 不依赖数据库的锁，性能好，但每个服务都要写三套逻辑，侵入性强。有两个经典问题，都靠一张事务控制表（记录全局事务 ID 和各阶段状态）解决：

• 空回滚：Try 请求因网络问题没到，协调者超时后调用了 Cancel。Cancel 发现没有 Try 的记录，就直接返回成功，并记下"已取消"
• 悬挂：Cancel 先执行完，迟到的 Try 才到达，资源被预留后再也没人释放。Try 执行前先查控制表，已经取消过就拒绝执行

Saga#

把长事务拆成一串本地事务 T1、T2、T3，每个都有对应的补偿操作 C1、C2、C3。T3 失败时，依次执行 C2、C1。

正常：T1 创建订单 ──> T2 扣库存 ──> T3 扣余额
失败：T3 失败 ──> C2 恢复库存 ──> C1 取消订单

两种组织方式：编排（Orchestration）由一个中心协调者按顺序调用各服务，流程清晰、好监控；协同（Choreography）由各服务监听事件自己决定下一步，去中心化，但流程分散在各处，链路长了难以追踪。

Saga 没有 Try 阶段的资源预留，中间状态对外可见（比如库存已扣、余额还没扣），这叫缺乏隔离性，业务上要能接受，或用"待确认"之类的状态标记兜住。

本地消息表与事务消息#

最常用的最终一致方案，核心是让"改业务数据"和"记下要发的消息"在同一个本地事务里完成：

1. 本地事务：插入订单 + 插入消息表（状态：待发送）
2. 定时任务扫描待发送的消息，投递到 MQ，成功后标记已发送
3. 下游消费消息，处理成功后 ack；失败则重试（下游必须幂等）

事务消息是 MQ 内置的同类能力，例如 RocketMQ：先发一条下游不可见的"半消息"，执行本地事务后再提交或回滚；如果 Broker 迟迟收不到结果，会回查生产者的本地事务状态来决定。MQ 怎么保证可靠投递和幂等消费，见 消息不丢失 和 重复消费与幂等。

最大努力通知用于跨公司的场景，比如支付平台回调商户：按递增间隔重试通知若干次，同时提供查询接口，让对方主动查询结果。

方案对比#

代码示例#

本地消息表（Node.js + mysql2），mq 代表项目里的消息队列客户端：

async function createOrder(order) {
  const conn = await pool.getConnection()
  try {
    await conn.beginTransaction()
    await conn.query('INSERT INTO orders (id, user_id, amount) VALUES (?, ?, ?)', [order.id, order.userId, order.amount])
    // 和订单在同一个事务里写入消息，要么都成功，要么都回滚
    await conn.query("INSERT INTO outbox (id, topic, payload, status) VALUES (?, 'order-created', ?, 'PENDING')", [order.id, JSON.stringify(order)])
    await conn.commit()
  } catch (err) {
    await conn.rollback()
    throw err
  } finally {
    conn.release()
  }
}

// 定时任务：投递待发送的消息。投递成功但标记失败会导致重复发送，所以下游必须幂等
async function relayOutbox() {
  const [rows] = await pool.query("SELECT * FROM outbox WHERE status = 'PENDING' ORDER BY created_at LIMIT 100")
  for (const msg of rows) {
    await mq.publish(msg.topic, msg.payload, { messageId: msg.id })
    await pool.query("UPDATE outbox SET status = 'SENT' WHERE id = ?", [msg.id])
  }
}

面试官可能追问#

易错点#

• 认为用了分布式事务就"强一致"了，TCC、Saga、消息表都只是最终一致
• 本地消息表的投递是至少一次，下游不做幂等就会重复处理
• TCC 的 Confirm、Cancel 都可能被重复调用，必须幂等
• 先发 MQ 消息再提交本地事务，事务回滚时消息已经发出去了，这是最常见的错误写法