RabbitMQ消息确认机制之事务机制。
RabbitMQ中，我们可以通过持久化数据 解决RabbitMQ服务器异常
的数据丢失问题。
问题：生产者将消息发送出去，消息到底有没有到达RabbitMQ服务器
默认的情况下是不知道的。
两种方式：
1.AMQP实现了事务机制，类似mysql的事务。
事务机制三个方法：
txSelect:用于将当前changel设置成transation模式。
txCommit：用于提交事务。
txRollback：回滚事务。
通过txSelect开启事务后，便可以发送消息给RabbitMQ服务器，通过
txCommit提交成功，如果提交之前出现了异常，就txRollback回滚。
问题：开启-提交-回滚，每次提交，都相当于一次请求，降低了消息的吞吐量，
因为走的通信太多，大量消息就会大量请求服务器，很耗时。
例：
生产者
消费者：
图中发送消息逻辑没有问题，所以发送的消息会成功
如果生产者代码中执行了错误的逻辑，比如：
这时候再发送消息，就会失败，并回滚。
2.confirm模式。
生产者端confirm实现原理：生产者将信道设成confirm模式，一旦信道进入到
confirm模式，所有在该信道发布的消息都会指派一个唯一消息id，一旦消息被投
递到所匹配的队列之后，就会发送一个确认给生产者（包含消息id），
这就使得生产者知道了这个消息已经正确到达了队列。如果消息和队列是可持久
化的，确认消息会将消息写到磁盘后在发出。
Confirm模式最大的好处在于它是异步的。
开启confirm模式：channel.confirmSelect();
编程模式：
2.1.普通：发过去（一条）后会调用waitForConfirms()（串行）。
2.2.批量：发过去（一批）后会调用waitForConfirms()（串行）。
2.3.异步confirm:提供一个回调方法，服务端confirm一条或多条后客户端会调用。
例：
Confirm普通模式 生产者：
消费者：
Confirm批量模式（普通模式+for循环） 生产者：
消费者：
confirm模式-异步
channel对象提供的confirmListener()回调方法只包含deliveryTag(当前channel发出
的消息序号)，我们需要自己为每一个channel维护一个unconfirm的消息序号集合，
每publish一条数据，集合中元素加1，每回调一次handleAck方法，unconfirm集
合删掉相应的一条（multiple=false）或多条（multiple=true）记录，从程序运行效
率上看，这个unconfirm集合最好采用有序集合SortedSed存储结构