RabbitMQ的高级特性(未完待续)

卑谦
98 阅读4分钟

消息可靠性问题

消息从生产者发送到exchange，再到queue，再到消费者，有哪些导致消息丢失的可能性？

  • 发送时丢失：
    • 生产者发送的消息未送达exchange
    • 消息到达exchange后未到达queue
  • MQ宕机，queue将消息丢失
  • consumer接收到消息后未消费就宕机

1.生产者确认机制

RabbitMQ提供了publisher confirm机制来避免消息发送到MQ过程中丢失。消息发送到MQ以后，会返回一个结果给发送者，表示消息是否处理成功。结果有两种请求：

  • publisher-confirm，发送者确认
    • 消息成功投递到交换机，返回ack
    • 消息未投递到交换机，返回nack
  • publisher-return，发送者回执
    • 消息投递到交换机了，但是没有路由到队列。返回ACK，及路由失败原因。

注意： 确认机制发送消息时，需要给每个消息设置一个全局唯一id，以区分不同消息，避免ack冲突。

SpringAMQP实现生产者确认

  1. 在publisher这个微服务的application.yml中添加配置：
spring:
    rabbitmq:
        publisher-confirm-type: correlated
        publisher-returns: true
        template:
            mandatory: true

配置说明：

  • publish-confirm-type: 开启publisher-confirm，这里支持两种类型：
    • simple:同步等待confirm结果，直到超时
    • correlated：异步回调，定义ConfirmCallback，MQ返回结果时会回调这个ConfirmCallback
  • publish-returns: 开启publish-return功能，同样是基于callback机制，不过是定义ReturnCallback
  • template,mandatory:定义消息路由失败时的策略。true，则调用ReturnCallback；false：则直接丢弃消息。
  1. SpringAMQP实现生产者确认

在项目启动过程中配置ReturnCallback，及ConfirmCallback:

2.消息持久化

3.消费者消息确认

RabbitMQ支持消费确认机制，即：消费者处理消息后可以向MQ发送ack回执，MQ收到ack回执后才会删除该消息。而SpringAMQP则允许配置三种确认模式：

  • manual：手动ack，需要在业务代码结束后，调用api发送ack
  • auto：自动ack，由spring监测listener代码是否出现异常，没有异常则返回ack；抛出异常则返回nack
  • none：关闭ack，MQ假定消费者获取消息后会成功处理，因此消息投递后立即被删除

配置方式是修改application.yml文件，添加下面配置：

spring:
    rabbitmq:
      listener:
         simple:
             prefetch: 1
             acknowledge-mode: none

我们可以利用Spring的retry机制，在消费者出现异常时利用本地重试，而不是无限制的requeue到mq队列。

4.失败重试机制

当消费者出现异常后，消息会不断requeue(重新入队)到队列，再重新发送给消费者，然后再次异常，再次requeue，无限循环，导致mq的消息处理飙升，带来不必要的压力；

spring:
    rabbitmq:
       listener:
          simple:
              prefetch: 1
              retry:
                 enabled: true # 开启消费者失败重试
                 initial-interval: 1000ms # 初始的失败等待时长为1秒
                 multiplier: 1 #下次失败的等待时长倍数，下次等待时长 = multiplier * last-interval
                 max-attemptes: 3 #最大重试次数
                 stateless: true # true无状态；false有状态。如果业务中包含事务，这里改为false

消费者失败消息处理策略

在开启重试模式之后，重试次数耗尽，如果消息依然失败，则需要有MessageRecoverer接口来处理，它包含三种不同实现：

  • RejectAndDontRequeueRecoverer:重试耗尽后，直接reject，丢弃消息。默认就是这种方式
  • ImmediateRequeueMessageRecoverer：重试耗尽后，返回nack，消息重新入队
  • RepublishMessageRecoverer：重试耗尽后，将失败消息投递到指定的交换机

延迟消息问题

高可用问题

消息堆积问题

当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。最早接收到的消息，可能就会成为死信，会被丢弃，这就是消息堆积问题。

解决消息堆积有三种思路：

  • 增加更多消费者，提高消费速度
  • 在消费者内开启线程池加快消息处理速度
  • 扩大队列容积，提高堆积上限

惰性队列

从RabbitMQ的3.6.0版本开始，就增加了Lazy Queue的概念，也就是惰性队列。

惰性队列的特征如下：

  • 接收到消息后直接存入磁盘而非内存
  • 消费者要消费消息时才会从磁盘中读取并加载到内存
  • 支持数百万的消息存储

而要设置一个队列为惰性队列，只需要在声明队列时，指定x-queue-mode属性为lazy即可。可以通过命令行将一个运行中的队列修改为惰性队列：

rabbitmqctl set_policy Lazy "^lazy-queue$" '{"queue-mode":"lazy"}' --apply-to queues
avatar
文章
阅读
粉丝