谷粒商城实战笔记-260-商城业务-消息队列-可靠投递-消费端确认

一，Ack消息确认机制简介

消费者端的确认机制（ACK/NACK）是RabbitMQ中一种重要的特性，它允许消费者告知Broker它们是否成功处理了接收到的消息。

1，简介

1. basic.ack：
   当消费者成功处理了一条消息时，它可以发送一个basic.ack（肯定确认）给Broker，指示这条消息可以安全删除。基本语法如下：

   channel.basicAck(deliveryTag, false); // deliveryTag是消息的唯一标识符，multiple参数设为false表示仅确认这一条消息
   

2. basic.nack：
   如果消费者无法处理消息，它可以发送一个basic.nack（否定确认）。这可以让Broker重新分发消息，或者直接丢弃它。基本语法如下：

   channel.basicNack(deliveryTag, false, false); // deliveryTag是消息的唯一标识符，multiple参数设为false表示仅确认这一条消息，requeue参数设为false表示直接丢弃
   

3. 默认行为：
   在默认情况下，消费者一旦接收到消息，消息就会从队列中移除。然而，如果你希望在处理完成后再确认消息，可以关闭自动确认模式，然后手动发送ack/nack信号。

4. 手动确认模式：
   可以通过设置channel.basicQos(0, true)来开启手动确认模式。在这种模式下，消费者必须显式地发送ack或nack信号，否则消息不会从队列中移除。

5. nack/reject：
   basic.nack和basic.reject都可以用来否定确认消息。它们的主要区别在于，reject可以指定重试次数，而nack则没有这个选项。reject还可以指定是否重新排队，而nack只能重排或丢弃。

6. 示例：

   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消费者是否成功处理了接收到的消息。它们的主要区别在于：

1. 基本用途：

   • basicAck：用于确认消息已被成功处理，告诉Broker可以从队列中删除该消息。
   • basicNack：用于否定确认消息，告诉Broker消息处理失败，可能需要重新分发或丢弃。

2. 重排消息：

   • basicAck：不会引起消息重排，因为它只是确认消息已被成功处理。
   • basicNack：可以选择让Broker将消息重新放回到队列中，供其他消费者尝试处理。

3. 丢弃消息：

   • basicAck：不会导致消息被丢弃。
   • basicNack&#x