在RabbitMQ中，生产者为了确保消息发送成功，一种是使用 confirm 确认机制，另一种就是使用事务机制，事务机制就是允许生产者在发送消息时，将多个消息操作作为一个原子单元进行处理，要么所有操作都成功执行，要么都不执行。
AMQP 协议中事务操作的基本流程
- 开启事务：客户端发送
tx.select命令 - 执行消息操作：发布消息、确认消息等
- 提交或回滚：
- 提交(
tx.commit)：确认所有操作 - 回滚(
tx.rollback)：取消所有操作
- 提交(
RabbitMQ 中事务的核心方法
RabbitMQ是基于AMQP协议实现的，在 RabbitMQ中，事务是通过在Channel上开启的，其中核心方法有：
channel.txSelect()：开启事务模式。channel.txCommit()：提交事务，确认所有操作。channel.txRollback()：回滚事务，撤销所有未提交的操作。
生产者通过txSelect()开启一个事务块。在这个事务块内，所有发送到RabbitMQ的消息都不会立即被确认，而是处于一种“暂存”状态。只有当生产者调用txCommit方法提交事务时，这些消息才会被真正处理和确认。如果在事务块内发生错误，生产者可以调用txRollback方法回滚事务，所有暂存的消息将不会被处理。
public class RabbitMQTxSelectTest {
private static final String QUEUE_NAME = "tx_queue";
public static void main(String[] argv) throws Exception {
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("localhost");
Connection connection = factory.newConnection();
Channel channel = connection.createChannel();
channel.queueDeclare(QUEUE_NAME, false, false, false, null);
// 开启事务
channel.txSelect();
try {
String message = "第一条事务消息";
channel.basicPublish("", QUEUE_NAME, null, message.getBytes("UTF - 8"));
System.out.println(" [x] 发送消息: '" + message + "'");
// 模拟错误
int error = 1 / 0;
message = "第二条事务消息";
channel.basicPublish("", QUEUE_NAME, null, message.getBytes("UTF - 8"));
System.out.println(" [x] 发送消息: '" + message + "'");
// 提交事务
channel.txCommit();
System.out.println("事务提交成功");
} catch (Exception e) {
// 回滚事务
channel.txRollback();
System.out.println("事务回滚");
} finally {
channel.close();
connection.close();
}
}
}
代码中，开启事务后发送了第一条消息，接着模拟了一个错误。由于错误发生，txCommit不会执行，而是进入catch块执行txRollback，因为事务被回滚，两条消息都不会真正到达队列。
事务机制的优缺点
- 优点：
- 数据一致性：确保一组消息要么全部成功发送到RabbitMQ并被处理，要么全部不发送，保证了数据的一致性。这在一些对数据完整性要求极高的场景，如金融交易中的消息处理。
- 简单易用：RabbitMQ的事务机制提供了直观的编程模型，可以很容易地理解和实现消息的可靠发送。
- 缺点：
- 性能损耗：事务机制会带来显著的性能开销。因为在事务模式下，消息不能立即被确认和处理，而是要等到事务提交，这增加了消息在系统中的停留时间。同时，事务的开启、提交和回滚操作都需要与RabbitMQ服务器进行额外的交互，导致网络开销增加。
- 资源占用：事务模式下，消息在事务提交前一直处于暂存状态，这会占用更多的内存等资源。如果事务包含大量消息或者事务处理时间过长，可能会导致服务器资源耗尽。
所以，在实际开发中，需要根据业务场景权衡事务机制的使用。如果对消息的一致性要求极高，而对性能要求相对较低，那么事务机制是一个不错的选择；如果系统对性能要求较高，对消息的可靠性可以通过其他方式（如确认机制）来保证，那么可以考虑不使用事务机制。
事务与发布者确认（Confirm）机制对比
| 维度 | 事务模式 | Confirm 模式 |
|---|---|---|
| 可靠性 | 原子性保证（全成功/全失败） | 单条消息确认（无原子性） |
| 性能 | 差（同步阻塞） | 优（异步，接近非事务性能） |
| 适用场景 | 金融扣款、订单创建等关键操作 | 日志收集、实时监控等高吞吐场景 |
| 代码复杂度 | 简单（同步模型） | 较高（需处理异步回调） |
