RabbitMq中的生产者确认机制

在使用RabbitMq的时候，可以通过消息持久化操作来解决服务器异常崩溃导致的消息丢失，但是如何保证消息正常到达RabbitMq呢？
事务机制
RabbitMq中与事务相关的操作一共有三个：channel.txSelect，channel.txCommit，channel.txRollback。channel.txSelect用于将当前信道设置为事务模式，channel.txCommit用于事务提交，channel.txRollback用于事务回滚。在通过channel.txSelect将当前信道设置为事务模式后，我们就可以向RabbitMq发送消息了，如果消息正常发送并且被RabbitMq接收，那么事务提交成功，否则捕捉异常并进行事务回滚。

需要注意的是，开启事务后，性能影响可能会很大（因为比普通发送多了四个步骤Tx.select，Tx.select-OK，Tx.commit，Tx.commit-Ok / Tx.select，Tx.selectOK，Tx.Rollback，Tx.Rollback-Ok），建议使用发送者确认机制。
确认机制
生产者将信道设置成confirm（确认）模式，一旦信道进入confirm模式，所有在该信道上面发布的消息都被被指派一个唯一的ID，一旦消息被投递到匹配的队列后，RabbitMq会发送一个确认标志（Basic.Ack+消息的唯一ID）给生产者，生产者确认消息已经正确到达目的地（如果消息和队列是持久化的，确认消息会在消息写入磁盘后发出）。
事务机制在一条消息发送后会使发送端阻塞，以等待RabbitMq的回应然后才能继续下一条消息。相比之下发送发确认机制最大的好处是异步的，一旦发送一条消息，生产者应用程序可以一边等待信道返回确认（通过回调方法处理确认消息）一边发送下一条消息，如果RabbitMq因为自身内部错误导致消息丢失，就会发送一条nack（Basic.Nack）命令，生产者同样可以在回调方法中处理该命令。
确认机制相比事务机制性能提升的点有两处：

1. 命令帧报文的减少
   同步等待的方式下，正常发送一条消息，确认机制需要通信交互的命令有两条：Basic.Publish和Basic.Ack；事务机制是三条：Basic.Publish，Tx.Commit，Tx.Commit-Ok。事务机制多了一个命令帧报文的交互，所以QPS会略微下降。
2. 批量确认或者异步确认机制。
   确认机制的优势在于并不一定需要单条消息同步确认，可以使用批量确认或者异步确认机制。在批量确认方法中，客户端程序需要定期或者定量，亦或者两者结合起来调用channel.waitForConfirms来等待RabbitMq的确认返回，虽然可以极大的提升效率，但是问题在于出现Basic.Nack或者超时情况时，发布者需要将这一批量的消息全部重发，这会带来明显的重复消息数量，并且当消息经常丢失时，性能是不升反降的。
   
   异步确认需要在channel接口中的addConfirmListener方法中添加ConfirmListener这个回调接口，其中包括两个方法handleAck和handleNack，分别用来处理RabbitMq回传的Basic.Ack和Basic.Nack。