2.4 小结
SpringAMQP中处理消息确认的几种情况：
- publisher-comfirm： 消息成功发送到exchange，返回Ack。 消息发送失败，没有到达交换机，返回Nack。 消息发送过程中出现异常，没有收到回执。
- 消息成功发送到exchange，但没有路由到queue
调用ReturnCallback。
3、消息持久化
生产者确认可以确保消息投递到RabbitMQ的队列中，但是消息发送到RabbitMQ以后，如果突然宕机，也可能导致消息丢失。
要想确保消息在RabbitMQ中安全保存，必须开启消息持久化机制。
- 交换机持久化
- 队列持久化
- 消息持久化
3.1 交换机持久化
RabbitMQ中交换机默认是非持久化的，mq重启后就丢失。
SpringAMQP中可以通过代码指定交换机持久化：
@Bean public DirectExchange simpleExchange(){ // 三个参数：交换机名称、是否持久化、当没有queue与其绑定时是否自动删除 return new DirectExchange("simple.direct", true, false); }
启动服务。
注：
事实上，默认情况下，由SpringAMQP声明的交换机都是持久化的。
3.2 队列持久化
RabbitMQ中队列默认是非持久化的，mq重启后就丢失。
SpringAMQP中可以通过代码指定交换机持久化：
@Bean public Queue simpleQueue(){ // 使用QueueBuilder构建队列，durable就是持久化的 return QueueBuilder.durable("simple.queue").build(); }
注：
事实上，默认情况下，由SpringAMQP声明的队列都是持久化的。
可以在RabbitMQ控制台看到持久化的队列都会带上D的标示：
3.3 消息持久化
利用SpringAMQP发送消息时，可以设置消息的属性（MessageProperties），指定delivery-mode：
- 1：非持久化
- 2：持久化
用java代码指定：
@Test public void testDurableMessage() { //准备消息 Message message = MessageBuilder.withBody("hell,spring".getBytes(StandardCharsets.UTF_8)) .setDeliveryMode(MessageDeliveryMode.PERSISTENT) .build(); // 2.发送消息 rabbitTemplate.convertAndSend("simple.queue",message); }
注：默认情况下，SpringAMQP发出的任何消息都是持久化的，不用特意指定。
3.4 小结
默认情况下，由SpringAMQP声明的交换机和队列还有发出的消息都是默认持久化的。
4、消费者消息确认
RabbitMQ是阅后即焚机制，RabbitMQ确认消息被消费者消费后会立刻删除。
而RabbitMQ是通过消费者回执来确认消费者是否成功处理消息的：消费者获取消息后，应该向RabbitMQ发送ACK回执，表明自己已经处理消息。
生产者消息确认可以确保消息投递到队列当中，而消息的持久化可以保证不会因为MQ的宕机而导致消息的丢失，经过这两个我们可以保证消息能投递到消费者。
但是这个消费者是不是一定能消费这个消息呢？如果消息投递到消费者的那一刻，消费者挂了，那这样消息还是没有消费，消息就丢失了。
RabbitMQ支持消费者确认机制，即：消费者处理消息后可以向MQ发送Ack回执，MQ收到Ack回执后才会删除该消息。而SpringAMQP则允许配置三种确认模式：
- manual：手动ack，需要在业务代码结束后，调用api发送ack。
- auto：自动ack，由spring监测listener代码是否出现异常，没有异常则返回ack；抛出异常则返回nack。
- none：关闭ack，MQ假定消费者获取消息后会成功处理，因此消息投递后立即被删除。
由此可知：
- none模式下，消息投递是不可靠的，可能丢失。
- auto模式类似事务机制，出现异常时返回nack，消息回滚到mq；没有异常，返回ack。
- manual：自己根据业务情况，判断什么时候该ack。
一般，我们都是使用默认的auto即可。
4.1.演示none模式
修改consumer服务的application.yml文件，添加下面内容：
spring: rabbitmq: listener: simple: acknowledge-mode: none # 关闭ack
我们在这个队列先发留有一条消息。
修改consumer服务的SpringRabbitListener类中的方法，模拟一个消息处理异常：
我们打个断点用 Debug运行。再回到浏览器查看，发现消息已经没了。
我们回到代码区往下执行。
测试可以发现，当消息处理抛异常时，消息依然被RabbitMQ删除了。
4.2.演示auto模式
再次把确认机制修改为auto:
然后我们再往队列发送一条消息。
再次用Debug运行程序。
可以发现此时消息状态为unacked（未确定状态）。这什么意思呢？就是我还没收到Ack,我在等着你给我发呢，所以消息还没有删除。
抛出异常后，因为Spring会自动返回nack，所以消息恢复至Ready状态，并且没有被RabbitMQ删除。
如果我们把断点去掉，就会发生一个恐怖的事情，它就会进去一个死循环，它发现你投递失败了，又给你重新投递，一直重复这个操作。
这个显然也不太好，但是最起码消息不会丢失。
5、消费失败重试机制
当消费者出现异常后，消息会不断requeue（重入队）到队列，再重新发送给消费者，然后再次异常，再次requeue，无限循环，导致mq的消息处理飙升，带来不必要的压力：
5.1 本地重试
我们可以利用Spring的retry机制，在消费者出现异常时利用本地重试，而不是无限制的requeue到mq队列。
修改consumer服务的application.yml文件，添加内容：
yaml
复制代码
retry: enabled:true# 开启消费者失败重试 initial-interval:1000# 初识的失败等待时长为1秒 multiplier:1# 失败的等待时长倍数，下次等待时长 = multiplier * initial-interval max-attempts:3# 最大重试次数，事不过三 stateless:true# true无状态；false有状态。如果业务中包含事务，这里改为false重启consumer服务，重复之前的测试。可以发现：
- 在重试3次后，SpringAMQP会抛出异常，说明本地重试触发了。
- 查看RabbitMQ控制台，发现消息被删除了，说明最后SpringAMQP返回的是ack，mq删除消息了
5.2.失败策略
在之前的测试中，达到最大重试次数后，消息会被丢弃，这是由Spring内部机制决定的。
在开启重试模式后，重试次数耗尽，如果消息依然失败，则需要有MessageRecovery接口来处理，它包含三种不同的实现：
- RejectAndDontRequeueRecoverer：重试耗尽后，直接reject，丢弃消息。默认就是这种方式。
- ImmediateRequeueMessageRecoverer：重试耗尽后，返回nack，消息重新入队。
- RepublishMessageRecoverer：重试耗尽后，将失败消息投递到指定的交换机。
比较好的一种处理方案是RepublishMessageRecoverer，失败后将消息投递到一个指定的，专门存放异常消息的队列，后续由人工集中处理。
1、在consumer服务中定义处理失败消息的交换机和队列
package com.jie.mq.config; import org.springframework.amqp.core.Binding; import org.springframework.amqp.core.BindingBuilder; import org.springframework.amqp.core.DirectExchange; import org.springframework.amqp.core.Queue; import org.springframework.amqp.rabbit.core.RabbitTemplate; import org.springframework.amqp.rabbit.retry.MessageRecoverer; import org.springframework.amqp.rabbit.retry.RepublishMessageRecoverer; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; @Configuration public class ErrorMessageConfig { /** * @description:异常消息交换机 * @author: jie * @time: 2022/2/26 18:39 */ @Bean public DirectExchange errorMessageExchange() { return new DirectExchange("error.direct"); } /** * @description:队列 * @author: jie * @time: 2022/2/26 18:39 */ @Bean public Queue errorQueue(){ return new Queue("err.queue"); } /** * @description:将交换机和队列绑定 * @author: jie * @time: 2022/2/26 18:39 */ @Bean public Binding errorMessageBinding(){ return BindingBuilder .bind(errorQueue()) .to(errorMessageExchange()) .with("error"); } /** * @description:异常消息处理器 * @author: jie * @time: 2022/2/26 18:41 */ @Bean public MessageRecoverer republishMessageReciverer(RabbitTemplate rabbitTemplate){ return new RepublishMessageRecoverer(rabbitTemplate,"error.direct","error"); } }
重新启动后我们向simple.queue发送消息。
6、总结
如何确保RabbitMQ消息的可靠性？
- 开启生产者确认机制，确保生产者的消息能到达队列。
- 开启持久化功能，确保消息未消费前在队列中不会丢失。
- 开启消费者确认机制为auto，由spring确认消息处理成功后完成ack。
- 开启消费者失败重试机制，并设置MessageRecoverer，多次重试失败后将消息投递到异常交换机，交由人工处理。
