事务简介
就像我们了解的MySQL中的事务一样，RabbiMQ的事务也具备原子性和一致性，并且RabbiMQ的事务是针对消息从生产者发送到RabbitMQ中提供的支持，因此不同事务可以同时给同一个队列发送信息。
可通过channel.txSelect，channel.txCommit，channel.txRollback三个方法实现事务机制。它们分别对应开启事务，提交事务以及事务回滚。如果事务提交成功，则消息一定到达了Rabbimq中，但并不能证明消息一定能入队！
如上图所示，待事务提交后，所有该事务内接收到的消息进行统一入队。
事务的使用
事务的使用java实现如下代码所示：
try{// 该信道开启事务channel.txSelect();channel.basicPublish(EXCHANGE_NAME,ROUTING_KEY + 1,null,message.getBytes());// 事务提交channel.txCommit();}catch (Exception e){e.printStackTrace();// 发生异常时进行事务回滚channel.txRollback();}
上述代码针对开启事务、提交事务、回滚事务进行了展示。在发送消息之前开启事务，当消息发送完成后进行事务提交，如果发生异常则进行事务回滚。
在使用事务的过程中需要注意以下问题：
- 事务提交之前，RabbiMQ接收到消息并不会针对消息进行分发入队操作，也就是说事务提交之前消费者是接收不到事务中的消息的。
- 一旦事务提交成功，则仅能证明消息发送给RabbitMQ过程中没有发生问题，换句话说就是RabbitMQ成功的接收到了消息，并且存在可以处理该消息的交换机。但并能保证该消息一定可以入队，也可能会存在消息无法路由到队列中的情况。
- 连接异常、信道关闭、交换机不存在会导致消息发送出现异常，这种异常可以被生产者接收并处理，然后进行消息回退。
- 事务机制在一条消息发送之后会使发送端阻塞，以等待RabbitMQ的回应，之后才能继续放下一条消息。
- 从测试的角度而言：如果可以入队，则入队成功后算是事务提交成功，如果需要持久化则入队持久化后返回事务成功，如果不能入队则入队失败后返回事务成功。只要交换机可以接收到消息，则一定返回事务成功，但具体返回的时机受消息入队和持久化的影响。
事务能解决的问题
根据上述对RabbitMQ的描述，可知在实际使用过程中事务机制可以为我们解决以下问题：
- 确保RabbitMQ接收到消息，并且存在可以处理该消息的交换机。也就是说一旦事务提交成功，则消息一定可以交由其指定的交换机进行处理；事务机制是从AMQP协议层面确保了消息一定合法的到达了RabbitMQ中。
- 保证消息们的原子性和一致性，事务内发送的消息要么全都成功，要么全都失败。
事务虽然能给我们解决一些问题，但是使用事务的过程中消息的发送需要增加一次事务开启和事务提交请求，如果仅仅使用事务确保消息合法的到达RabbitMQ中，那么每次发送一条消息都将开启事务和提交事务，这无疑会浪费资源，因此不建议使用事务确保消息合法发送，可使用发送方确认机制确保消息到达了RabbitMQ。事务更适合的场景是：多条消息期望要么都成功发送要么都不发送的业务需求。
