RabbitMQ-消费者确认机制

最新推荐文章于 2024-10-11 18:14:52 发布

何怀逸

最新推荐文章于 2024-10-11 18:14:52 发布

阅读量1.2k

点赞数 9

分类专栏： mq 文章标签： rabbitmq 分布式

本文链接：https://blog.csdn.net/qq_42251944/article/details/135718646

版权

mq 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

本文介绍了SpringAMQP中RabbitMQ的两种消息确认模式（自动模式和手动模式），以及如何在YML文件中配置自动模式以确保异常处理。还讨论了重试机制，包括如何设置重试次数和不同类型的MessageRecoverer接口以决定失败消息的处理方式。

摘要由CSDN通过智能技术生成

1、确认模式

none：不做任何处理，消息投递到消费者了之后，立即返回ACK，并且从MQ将消息删除，非常不安全，不建议使用。
manual：手动模式，需要在业务中调用api，ack或者reject。
auto：自动模式，SpringAMQP利用AOP对我们的消息处理做了环绕增强，当业务正常执行时返回ACK，执行异常时，根据异常的情况返回不同的结果：
如果是业务异常，会自动返回nack，nack会再次投递MQ消息。
如果是消息处理或校验异常，自动返回reject，拒绝之后不再投递MQ，删除MQ中的消息。一般是以错误的消息，就会这么错里

2、yml文件配置

spring:
  rabbitmq:
    listener:
      simple:
        acknowledge-mode: auto #开启自动模式

3、重试机制

消息失败之后会重新入队，然后再次异常，再次入队，无限循环，这会导致mq消息处理飙升，带来不必要的压力。为了缓解这种压力，利用Spring的retry机制，在消费者出现异常的情况下，利用本地重试，重试次数用完之后，再进行消息的投递或者消息的拒绝。

yml文件配置：

spring:
  rabbitmq:
    listener:
      simple:
        retry:
          # 是否启用
          enabled: true
          # 初始时间间隔
          initial-interval: 1000ms
          # 下次失败的等待时长的倍数
          multiplier: 1
          # 最大尝试次数
          max-attempts: 3
          # 无状态
          stateless: true

开启重试之后，当重试次数耗尽的时候，如果消息依然失败，则需要调用MessageRecoverer接口来处理，这个接口有三种实现：

RejectAndDontRequeueRecoverer：重试耗尽，直接reject，丢弃消息。默认方式。
ImmediateRequeueMessageRecoverer：重试耗尽后，返回nack，消息重新入队。
RepublishMessageRecoverer：重试耗尽后，将失败消息投递到指定的交换机。然后交给人工处理。