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

Question

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

我的目标是确定重新传递特定消息的次数。我看到有两种方法可以做到这一点:

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

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

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

Answer 1

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

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

不干扰业务逻辑，就是这个诊断部分是隔离的

您将重新排队到rabbitmq(正如您应该做的那样)，这意味着您不必担心丢失消息和处理一些对您业务逻辑没有用的消息元信息

它实际上应该被使用 - ACKing 和 NACKing，这就是它在 AMQP 规范中的原因

因为您确实需要重新传递特定消息的次数，所以您在外部某处拥有它，这意味着它独立于(rabbitmq 的)消息持久性、生命周期、潜在的队列持久性镜像等