Rabbit MQ 消息确认和持久化机制

一：确认种类

RabbitMQ的消息确认有两种。一种是消息发送确认，用来确认生产者将消息发送给交换器，交换器传递给队列的过程中消息是否成功投递。发送确认分为两步，一是确认是否到达交换器，二是确认是否到达队列。第二种是消费接收确认。确认消费者是否成功消费了队列中的消息。

二：消息发送确认

（1）ConfirmCallback

通过实现ConfirmCallBack接口，消息发送到交换器Exchange后触发回调。

 使用该功能需要开启确认，spring-boot中配置如下：  spring.rabbitmq.publisher-confirms = true

（2）ReturnCallback

        通过实现ReturnCallback接口，如果消息从交换器发送到对应队列失败时触发，比如根据发送消息时指定的routingKey找不到队列时会触发。

 使用该功能需要开启确认，spring-boot中配置如下：  spring.rabbitmq.publisher-returns = true

三：消息接收确认

（1）确认模式

• AcknowledgeMode.NONE：不确认
• AcknowledgeMode.AUTO：自动确认
• AcknowledgeMode.MANUAL：手动确认

spring-boot中配置方法：spring.rabbitmq.listener.simple.acknowledge-mode = manual

（2）手动确认

图 未确认的消息数

上图为channel中未被消费者确认的消息数。通过RabbitMQ的host地址加上默认端口号15672访问管理界面。

（2.1）成功确认

void basicAck(long deliveryTag, boolean multiple) throws IOException;

deliveryTag:该消息的index

multiple：是否批量. true：将一次性ack所有小于deliveryTag的消息。

消费者成功处理后，调用channel.basicAck(message.getMessageProperties().getDeliveryTag(), false)方法对消息进行确认。

（2.2）失败确认

void basicNack(long deliveryTag, boolean multiple, boolean requeue) throws IOException;

deliveryTag:该消息的index。

multiple：是否批量。true：将一次性拒绝所有小于deliveryTag的消息。

requeue：被拒绝的是否重新入队列。

void basicReject(long deliveryTag, boolean requeue) throws IOException;

deliveryTag:该消息的index。

requeue：被拒绝的是否重新入队列。

channel.basicNack 与 channel.basicReject 的区别在于basicNack可以批量拒绝多条消息，而basicReject一次只能拒绝一条消息。

消息队列的基础知识可以参考：消息队列RabbitMQ基础知识详解

四：思考

（1）手动确认模式，消息手动拒绝中如果requeue为true会重新放入队列，但是如果消费者在处理过程中一直抛出异常，会导致入队-》拒绝-》入队的循环，该怎么处理呢？

第一种方法是根据异常类型来选择是否重新放入队列。

第二种方法是先成功确认，然后通过channel.basicPublish()重新发布这个消息。重新发布的消息网上说会放到队列后面，进而不会影响已经进入队列的消息处理。

void basicPublish(String exchange, String routingKey, boolean mandatory, boolean immediate, BasicProperties props, byte[] body) throws IOException;

（2）消息确认的作用是什么？

为了防止消息丢失。消息丢失分为发送丢失和消费者处理丢失，相应的也有两种确认机制。

（3）Redis和 rabbit MQ 都可以做消息队列，为什么选择了Rabbit MQ ？

        RabbitMQ和Redis都可以做队列，但是他们还是有区别的。比如，Redis的消息队列，如果在从队列pop出去的时候，worker处理失败的话，数据不会回到队列中，需要从业务中手动把失败的处理数据push到队列中，而RabbitMQ可以自动处理失败的worker使数据不丢失；RabbitMQ还可以保证数据在传输过程中持久化，在通道和队列中的数据可以设置为持久化。另外，Redis严格来说并不是消息队列，它是一个内存数据库，不过因为其某些特性适合用来充当队列，所以也多被用于做简单的MQ, Redis之父倒是开发了个真正的消息队列disque，有兴趣可以看看。 

       相比起Redis，RabbitMQ有更加完善的MQ机制，这里我们仅讨论消息的durable（持久性），后续一系列其他机制有时间再交流。 

      RabbitMQ有一个消息确认机制来保证消息的不丢失：客户端从队列中取出消息之后，可能需要一段时间才能处理完成，如果在这个过程中，客户端出错了，异常退出了，而数据还没有处理完成，那么非常不幸，这段数据就丢失了，因为RabbitMQ默认会把此消息标记为已完成，然后从队列中移除，消息确认是客户端从RabbitMQ中取出消息，并处理完成之后，会发送一个ack告诉RabbitMQ，消息处理完成，当RabbitMQ收到客户端的获取消息请求之后，或标记为处理中，当再次收到ack之后，才会标记为已完成，然后从队列中删除。当RabbitMQ检测到客户端和自己断开链接之后，还没收到ack，则会重新将消息放回消息队列，交给下一个客户端处理，保证消息不丢失，也就是说，RabbitMQ给了客户端足够长的时间来做数据处理。 

五：消息持久化 

1. RabbitMQ在服务端没有声明队列queue持久化(durable=True)时，队列是存在内存中的，服务端down机了，队列也随之消失。
2. RabbitMQ在服务端只声明queue持久化，但是在发送消息时，没有声明持久化(properties=pika.BasicProperties(delivery_mode=2,))，服务器down机，只保留队列，但是不保留消息。
3. RabbitMQ在服务端声明queue持久化，并且在发消息时也声明了持久化，服务down机重启后，队列和消息都能得到保存。
4. 服务端声明持久化，客户端想接受消息的话，必须也要声明queue时，也要声明持久化，不然的话，客户端执行会报错。

Reference：

https://www.cnblogs.com/nizuimeiabc1/p/9397326.html