文章目录
- 一,Ack消息确认机制简介
-
- 1,简介
- 2,两个常用的Api
- 二,消费者端消息确认实战
- 三,RabbitMQ可靠性保障总结
-
- 1,生产者
- 2,消费者
一,Ack消息确认机制简介
消费者端的确认机制(ACK/NACK)是RabbitMQ中一种重要的特性,它允许消费者告知Broker它们是否成功处理了接收到的消息。
1,简介
-
basic.ack:
当消费者成功处理了一条消息时,它可以发送一个basic.ack(肯定确认)给Broker,指示这条消息可以安全删除。基本语法如下:channel.basicAck(deliveryTag, false); // deliveryTag是消息的唯一标识符,multiple参数设为false表示仅确认这一条消息
-
basic.nack:
如果消费者无法处理消息,它可以发送一个basic.nack(否定确认)。这可以让Broker重新分发消息,或者直接丢弃它。基本语法如下:channel.basicNack(deliveryTag, false, false); // deliveryTag是消息的唯一标识符,multiple参数设为false表示仅确认这一条消息,requeue参数设为false表示直接丢弃
-
默认行为:
在默认情况下,消费者一旦接收到消息,消息就会从队列中移除。然而,如果你希望在处理完成后再确认消息,可以关闭自动确认模式,然后手动发送ack/nack信号。 -
手动确认模式:
可以通过设置channel.basicQos(0, true)
来开启手动确认模式。在这种模式下,消费者必须显式地发送ack或nack信号,否则消息不会从队列中移除。 -
nack/reject:
basic.nack和basic.reject都可以用来否定确认消息。它们的主要区别在于,reject可以指定重试次数,而nack则没有这个选项。reject还可以指定是否重新排队,而nack只能重排或丢弃。 -
示例:
channel.basicConsume(queueName, false, consumerTag, autoAck, arguments, consumer); // ... channel.basicAck(deliveryTag, false); // 成功处理 channel.basicReject(deliveryTag, requeue); // 失败处理,requeue为true表示重排,false表示丢弃
通过消费者端的确认机制,可以确保消息得到正确的处理,并且在处理失败时能够重新分发。这有助于构建可靠的分布式系统,并防止消息丢失。
2,两个常用的Api
basicAck
和basicNack
都是RabbitMQ中的消息确认机制,用于告诉Broker消费者是否成功处理了接收到的消息。它们的主要区别在于:
-
基本用途:
basicAck
:用于确认消息已被成功处理,告诉Broker可以从队列中删除该消息。basicNack
:用于否定确认消息,告诉Broker消息处理失败,可能需要重新分发或丢弃。
-
重排消息:
basicAck
:不会引起消息重排,因为它只是确认消息已被成功处理。basicNack
:可以选择让Broker将消息重新放回到队列中,供其他消费者尝试处理。
-
丢弃消息:
basicAck
:不会导致消息被丢弃。basicNack
&#x