RabbitMQ的消息确认

学而时习之，不亦说乎。今天总结一下常用的分布式事务的处理方法，一般有XA、TCC和消息中间件最终一致性三种解决方案。XA是采用二段提交的方法实现强一致性，现在基本没人用，简单点说就是一个应用操作多个数据源，常用方案就是springboot+JTA，有些数据连接池框架像druid之类的也支持，效率超低，还不如改微服务；TCC是指try、confirm、cancel，即执行、确认、回滚，比如A银行向B银行转账，发起转账请求后，先调A的接口扣钱，再调B的接口加钱，如果B出异常，A通过代码回滚，这个解决方案的缺点是要封装的回滚机制代码太多，不好维护，现在一般也不采用这种方法；消息中间件最终一致性方案是目前最常用的解决方案，原理与TCC类似，即业务模块先向A发送准备消息，如果A能收到并返回确认消息，A就执行扣款操作，待A执行完业务操作再向B，处理过程和A一样，全部正常返回，则返回完成信息，如发现异常，再通知A回滚业务，但这种方式的开发量要小得多，这种方式充分利用MQ的解耦作用和消息确认机制，降低了开发难度，开发者只需要处理生产者的准备消息和消费者的消费确认消息是否正常，就能实现最终一致性。

在实现层面上比较常用的是使用RabbitMQ消息中间件，当然其他的RocketMQ、Kafka等也能实现，只是RabbitMQ提供ConfirmCallback，开发起来更简单一些，所以本次主要总结一下RabbitMQ的消息确认。

RabbitMQ的消息确认。消息确认是保证消息传递可靠性的重要步骤，持久化只能保证消息不丢失，但是如果消息如果投递失败我们怎么进行补偿操作呢？解决办法就是实现回调函数进行操作，在消息的发送和消息的消费都可以进行补偿操作，下面我们就要讲解消息确认。

消息确认种类

消息的确认做有很多法，其中包括事务机制、批量确认、异步确认等。

事务机制：我们在channel对象中可以看到 txSelect(),txCommit(),txrollback() 这些方法，分别对应着开启事务，提交事务，回滚。由于使用事务会造成生产者与Broker交互次数增加，造成性能资源的浪费，而且事务机制是阻塞的，在发送一条消息后需要等待RabbitMq回应，之后才能发送下一条，因此事务机制不提倡，大家在网上也很少看到RabbitMq使用事务进行消息确认的。

批量确认：批量其实是一个节约资源的操作，但是在RabbitMq中我们使用批量操作会造成消息重复消费，原因是批量操作是使客户端程序定期或者消息达到一定量，来调用方法等待Broker返回，这样其实是一个提高效率的做法，但是如果出现消息重发的情况，当前这批次的消息都需要重发，这就造成了重复消费，因此批量确认的操作性能没有提高反而下降。

异步确认：异步确认虽然编程逻辑比上两个要复杂，但是性价比最高，无论是