rabbitmq:消费者可以在 nack 之前持久化消息更改吗?

rabbitmq: can consumer persist message change before nack?

在消费者 nacks 消息之前,消费者是否可以通过任何方式修改消息的状态,以便当消费者在重新传递时使用它时,它会看到已更改的状态。 我宁愿不拒绝 + 重新排队新消息,但如果这是完成此操作的唯一方法,请告诉我。

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

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

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

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

没有办法像你想的那样做(1)。您将需要更改消息,因此该消息将成为另一条消息。如果你想做那样的事情(你可能是用 I'd rather not reject + reenqueue new message 来表达这个意思)——你应该确认消息,增加其中的一个字段并再次发布它(同样,也许这就是你的意思,当你说 reenqueue it)。因此,您的消息有效负载将具有一些 ID、计数器和再次(明显不同的)有效负载,即内容。

出于多种原因,显然更好的方法是 (2):

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

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

Quorum queues 提供设置重新投递限制的选项:

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

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