rabbitmq：消费者可以在 nack 之前坚持消息更改吗？答案

【问题标题】：rabbitmq: can consumer persist message change before nack?rabbitmq：消费者可以在 nack 之前坚持消息更改吗？
【发布时间】：2017-02-05 23:10:58
【问题描述】：

在消费者 nacks 消息之前，消费者有什么方法可以修改消息的状态，以便消费者在重新传递时消费它时，它会看到改变的状态。 我不希望拒绝 + 重新排队新消息，但如果这是实现此目的的唯一方法，请告诉我。

我的目标是确定特定消息被重新传递的次数。我看到了两种方法：

(1) 如上所述的消息本身。该消息将是一个包含基本统计信息和应用程序负载消息的容器。

(2) 在一些外部存储中。我们将通过我们设置的消息 id 来唯一地标识消息。

我知道 2 是可能的，但我的问题是 1 是否可能。

【问题讨论】：

当你说修改消息的状态是否意味着它只是消息本身的另一个标志？比如在做 Nack 之前修改消息内容？
它必须是一个整数。通过标志，我假设您的意思是布尔值
Nah 只是想确保它的消息在我们做 Nack 之前得到更新。因为在做 Nack 之前你确实可以控制消息但不确定一旦你更新了消息它会是相同的消息或新的消息。因为如果 id 发生更改，则很难跟踪该消息。

标签： rabbitmq rabbitmq-exchange

【解决方案1】：

没有办法像你想要的那样做（1）。您需要更改消息，因此该消息将成为另一条消息。如果你想做这样的事情（你可能是用I'd rather not reject + reenqueue new message 表示这个） - 你应该确认消息，在其中增加一个字段并再次发布它（再次，也许这就是你说@时的意思987654322@)。因此，您的消息负载将具有一些 ID、计数器，以及作为内容的负载（显然不同）。

出于多种原因，绝对更好的方法是 (2)：

不干扰业务逻辑，即这个诊断部分是隔离的
您将重新排队留给rabbitmq（正如您应该做的那样），这意味着您不必担心丢失消息并处理一些对您的业务逻辑没有用的消息元信息
它实际上应该被使用 - ACKing 和 NACKing，这就是它在 AMQP 规范中的原因
由于您确实需要重新传递特定消息的次数，因此您可以在外部某处获取它，这意味着它独立于（rabbitmq 的）消息持久性、生命周期、潜在的队列持久性镜像等

【讨论】：

【解决方案2】：

即使这个问题在前一段时间被标记为已解决，我想提一下，至少有一种方法可以重新交付。它可能会在原始答案之后被整合。 RabbitMQ 中有一种不同类型的队列，称为Quorum queues。

Quorum 队列提供设置重新投递限制的选项：

Quorum queues support poison message handling via a redelivery limit. This feature is currently unique to Quorum queues.

为了存档，RabbitMQ 正在计算标题中的交付数量。 header 属性调用：x-delivery-count

【讨论】：