RabbitMQ的高级特性-消息确认机制

对于RabbitMQ发送消息到消费端的可靠性保障

引入:发送者发送消息后,到达消费端之后会出现一下两种情况:

①消息处理成功

②消息处理异常

RabbitMQ向消费者发送消息之后, 就会把这条消息删掉, 那么第两种情况, 就会造成消息丢失,要保证消费端能够成功接收到消息,于是RabbitMQ就引入了消息确认机制

在RabbitMQ中:

消费者在订阅队列时,可以指定 autoAck 参数, 根据这个参数设置, 消息确认机制分为以下两种:

① ⾃动确认: 当autoAck 等于true时, RabbitMQ 会⾃动把发送出去的消息置为确认, 然后从内存(或

者磁盘)中删除, ⽽不管消费者是否真正地消费到了这些消息. ⾃动确认模式适合对于消息可靠性要求不⾼的场景.

② ⼿动确认: 当autoAck等于false时,RabbitMQ会等待消费者显式地调⽤Basic.Ack命令, 回复确认信号后才从内存(或者磁盘) 中移去消息. 这种模式适合对消息可靠性要求⽐较⾼的场景.

注:

当autoAck参数置为false, 对于RabbitMQ服务端⽽⾔, 队列中的消息分成了两个部分:

⼀是等待投递给消费者的消息.

⼆是已经投递给消费者, 但是还没有收到消费者确认信号的消息.

如果RabbitMQ⼀直没有收到消费者的确认信号, 并且消费此消息的消费者已经断开连接, 则RabbitMQ会安排该消息重新进⼊队列,等待投递给下⼀个消费者,当然也有可能还是原来的那个消费者

手动确认的方法:

消费者在收到消息之后, 可以选择确认, 也可以选择直接拒绝或者跳过, RabbitMQ也提供了不同的确认应答的⽅式, 消费者客⼾端可以调⽤与其对应的channel的相关⽅法:

  1. 肯定确认: Channel.basicAck(long deliveryTag, boolean multiple) :RabbitMQ 已知道该消息并且成功的处理消息. 可以将其丢弃了.

参数说明:

  1. deliveryTag: 消息的唯⼀标识,它是⼀个单调递增的64 位的⻓整型值. deliveryTag 是每个通道

(Channel)独⽴维护的, 所以在每个通道上都是唯⼀的. 当消费者确认(ack)⼀条消息时, 必须使⽤对应的通道上进⾏确认.

  1. multiple: 是否批量确认. 在某些情况下, 为了减少⽹络流量, 可以对⼀系列连续的 deliveryTag 进

⾏批量确认. 值为 true 则会⼀次性 ack所有⼩于或等于指定 deliveryTag 的消息. 值为false, 则只确认当前指定deliveryTag 的消息.

  1. 否定确认: Channel.basicReject(long deliveryTag, boolean requeue):RabbitMQ在2.0.0版本开始引⼊了 Basic.Reject 这个命令, 消费者客⼾端可以调⽤channel.basicReject⽅法来告诉RabbitMQ拒绝这个消息.

参数说明:

requeue: 表⽰拒绝后, 这条消息如何处理. 如果requeue 参数设置为true, 则RabbitMQ会重新将这条消息存⼊队列,以便可以发送给下⼀个订阅的消费者. 如果requeue参数设置为false, 则RabbitMQ会把消息从队列中移除, ⽽不会把它发送给新的消费者.

  1. 否定确认: Channel.basicNack(long deliveryTag, boolean multiple,boolean requeue)Basic.Reject命令⼀次只能拒绝⼀条消息,如果想要批量拒绝消息,则可以使⽤Basic.Nack这个命令. 消费者客⼾端可以调⽤ channel.basicNack⽅法来实现.

multiple参数设置为true则表⽰拒绝deliveryTag编号之前所有未被当前消费者确认的消息.

SpringBoot中的确认机制:

  1. AcknowledgeMode.NONE

这种模式下, 消息⼀旦投递给消费者, 不管消费者是否成功处理了消息, RabbitMQ 就会⾃动确认

消息, 从RabbitMQ队列中移除消息. 如果消费者处理消息失败, 消息可能会丢失.(消费者正常/异常处理:MQ删除相应的消息)

  1. AcknowledgeMode.AUTO(默认)

这种模式下, 消费者在消息处理成功时会⾃动确认消息, 但如果处理过程中抛出了异常, 则不会确认消息.(消费者正确处理:消息自动确认,消费者异常处理:消费会不停重试)

  1. AcknowledgeMode.MANUAL

⼿动确认模式下, 消费者必须在成功处理消息后显式调⽤ basicAck ⽅法来确认消息. 如果消

息未被确认, RabbitMQ 会认为消息尚未被成功处理, 并且会在消费者可⽤时重新投递该消息, 这

种模式提⾼了消息处理的可靠性, 因为即使消费者处理消息后失败, 消息也不会丢失, ⽽是可以被

重新处理.

配置代码:

java 复制代码
spring:
  rabbitmq:
    addresses: 
    listener:
      simple:
        acknowledge-mode: none/auto/manual
相关推荐
微三云 - 廖会灵 (私域系统开发)2 小时前
电商系统微服务拆分实战:从单体到Spring Cloud的分布式事务踩坑与补偿方案
分布式·spring cloud·微服务
ACP广源盛139246256735 小时前
破局 PCIe 4.0 交换瓶颈@ACP#IX8024 / ASM58024参数及应用对比
大数据·人工智能·分布式·嵌入式硬件
淡然的煎蛋6 小时前
开始使用RabbitMQ
分布式·rabbitmq·ruby
笨鸟先飞的橘猫1 天前
skynet——分布式支持
分布式·skynet
ACP广源盛139246256731 天前
GSV6155 @ACP#工业车规 DP1.4 重定时器 Retimer
大数据·人工智能·分布式·嵌入式硬件
ACP广源盛139246256731 天前
GSV2221@ACP# DP1.4 MST 多流显示转换芯片国产工业多屏
大数据·人工智能·分布式·嵌入式硬件·spark
sukioe1 天前
从 0 到 1 构建城市公共设施智能报修与派单系统:FastAPI + Vue3 + RabbitMQ + Redis Geo + AI 工作流实践
redis·rabbitmq·fastapi
ACP广源盛139246256731 天前
GSV2231@ACP# 增强型 8K MST 多屏扩展芯片
大数据·人工智能·分布式·嵌入式硬件
虚心的百褶裙1 天前
远程调用服务架构设计及zookeeper技术详解(下篇)
分布式·zookeeper·云原生
清晨曦月1 天前
【从零构建分布式在线评测系统】二、Judge0服务器上的心跳程序
运维·服务器·分布式