P93 RabbitMQ 事务消息

面试题：RabbitMQ 的事务机制是什么？和 Confirm 模式有什么区别？

1. RabbitMQ 事务（AMQP 事务）

channel.txSelect();          // 开启事务
try {
    channel.basicPublish(exchange, routingKey, props, body);
    channel.txCommit();      // 提交
} catch (Exception e) {
    channel.txRollback();    // 回滚
}

原理：生产者发送消息后，Broker 返回 Tx.Commit-Ok 才代表事务成功；失败可回滚重发。

2. 事务的缺点

• 性能差：每条消息都要事务交互（同步、多次往返），吞吐大幅下降；
• 事务期间 Broker 要维护事务状态，阻塞/开销大；
• 生产环境基本不用事务模式，用 Confirm 发布确认替代。

3. 事务 vs Confirm

对比项	事务（tx）	Confirm
模式	开启事务、提交/回滚	发布后异步/同步等 ack
性能	差（同步往返）	好（支持批量/异步）
可靠性	保证发送成功	同样保证（ack）
生产推荐	不推荐	推荐

两者不能同时使用（事务模式下 Confirm 无效）。

4. 面试怎么答

1. 说出事务用法（txSelect / txCommit / txRollback）；
2. 指出性能差是硬伤；
3. 结论：生产用 Confirm（批量/异步）+ 消息落库 + 重试 保证生产端可靠，事务模式了解即可。

5. 加分点

• 追问"事务模式能保证不丢吗"：只能保证"发到 Broker 成功/失败"，服务端持久化和消费端 ack 还得另外配；
• 提到事务与本地消息表的取舍：本地消息表 + 定时补偿更灵活；
• 补充：Confirm 失败后重发，配合 mandatory + Return 处理路由不到的消息。

一句话总结

RabbitMQ 事务（txSelect/txCommit/txRollback）能保证消息发送成功，但同步往返导致性能差，生产基本不用；用 Confirm 发布确认（批量/异步）+ 持久化 + 手动 ACK 实现同等可靠性和更高吞吐。