消息队列RabbitMQ-使用过程中面临的问题与解决思路

消息队列在使用过程中会出现很多问题

首先就是消息的可靠性，也就是消息从发送到消费者接收，消息在这中间过程中可能会丢失

生产者到交换机的过程、交换机到队列的过程、消息队列中、消费者接收消息的过程中，这些过程中消息都可能会丢失。

这对上述过程，RabbitMQ分别对应的解决方案是生产者确认机制、持久化机制、消费者确认机制、消费者失败重试机制。

生产者确认机制，就是保证消息在生产者到交换机的过程、交换机到队列的过程不会丢失的机制。这种机制给每一个消息指定了唯一的ID，消息从生产者到交换机、从交换机到队列中的阶段都会返回一个结果，消息从生产者到交换机会通过返回一个布尔值来反馈消息是否送到了交换机，即发送者确认publisher-confirm。如果消息投递到了交换机但是没有到队列，就会返回ACK及路由失败原因，即发送者回执publisher-return。

持久化机制，就是保证消息在消息队列中不会丢失的机制。比如消息发送到RabbitMQ中，突然发生宕机，将会导致消息丢失。消息持久化机制包括：交换机持久化、队列持久化、消息持久化。默认情况下由SpringAMQP声明的交换机和队列都是持久化的。可以在RabbitMQ控制台上看到叫交换机和队列的features字段上标示D。利用SpringAMQP发送消息时，可以设置消息的属性MessageProperties，指定为delivery-mode。

消费者消息确认机制，在此机制下RabitMQ会根据消费者的回执来确认消费者是否成功处理消息，然后在确定是否删除消息。SpringAMQP确认模式默认是auto，由spring检测listenner代码是否出现异常，没异常返回ack，有异常返回nack。当然还有manual手动ack模式，和none无ack模式。unacked会在控制台queues中的messas中显示，并回复到Ready状态，不会被RabbitMQ删除、并且会重新投递。但是消息不断的重入队（发送消息、出现异常、在重入队），出现了死循环，这是就要依靠消费者失败重试机制了。

消费者失败重试机制主要实现靠两方面

1.将重入队利用Spring的retry机制改为本地重试，可以通过修改消费者服务模块的application.ym文件。

spring:
  rabbitmq:
    listener:
      simple:
        retry:
          enabled: true # 开启消费者失败重试
          initial-interval: 1000 # 初始的失败等待时长为1000毫秒=1秒
          multiplier: 2 # 每次重试尝试时间间隔增加因子
          max-attempts: 3 # 最大重试次数，达到最大重试次数后，消息默认会被丢弃
          stateless: true # true无状态；false有状态。如果业务中包含事务，这里改为false

上述配置完成，触发本地重试，在重试3次后，SpringAMQP会抛出异常AmqpRejectAndDontRequeueException，并且控制台上消息被删除了，意味着SpringAMQP返回的是ack，mq删除消息了。

2.指定消息重试失败的失败策略，默认的是直接丢弃消息，也可以设置将其失败后重新入队（不建议，没意义），推荐的是将失败的消息投递到指定的队列，这个队列专门存放异常消息，后续方便人工处理。