rabbitmq: может ли потребитель сохранить сообщение об изменении до nack?

Question

Перед тем, как потребитель выталкивает сообщение, есть ли способ, которым потребитель может изменить состояние сообщения, чтобы потребитель потреблял его при повторной доставке, он видит это измененное состояние. Я бы предпочел не отклонять + повторное появление нового сообщения, но, пожалуйста, дайте мне знать, если это единственный способ добиться этого.

Моя цель - определить, сколько раз пересылаются конкретные сообщения. Я вижу два способа сделать это:

(1) В самом сообщении, как описано выше. Сообщение будет контейнером базовой статистики и сообщением полезной нагрузки приложения.

(2) В некоторых внешних хранилищах. Мы однозначно идентифицируем сообщение с помощью идентификатора сообщения, который мы установили.

Я знаю, что 2 возможно, но мой вопрос в том, возможно ли 1.

Answer 1

Нет способа сделать (1), как вы хотите. Вам нужно будет изменить сообщение, таким образом сообщение станет другим сообщением. Если вы хотите сделать что-то подобное (и, возможно, вы имели в виду это с I'd rather not reject + reenqueue new message) - вы должны ЗАПИСАТЬ сообщение, добавьте в него одно поле и опубликуйте его снова (опять же, возможно, это именно то, что вы имели в виду, когда вы сказали reenqueue it). Таким образом, ваша полезная нагрузка для сообщения будет иметь идентификатор, счетчик и снова (явно различную) полезную нагрузку, которая является содержимым.

Definitvly намного лучше путь (2) по нескольким причинам:

• это не мешает бизнес-логики, то есть эта диагностическая часть изолирована
• вы уезжаете повторно очереди к RabbitMQ (как вы должны делать это), что означает, что вы не беспокоитесь о потере сообщений и обработке некоторой мета-информации о сообщениях, которая не имеет для вас никакой коммерческой логики
• ее на самом деле предполагается использовать - ACKing и NACKing, вот почему она находится в Спецификация AMQP
• , так как вам нужно количество раз, сколько раз были отправлены определенные сообщения, вы имеете его где-то извне, что означает, что он не зависит от стойкости сообщения (rabbitmq), времени жизни, потенциального зеркального отражения в очереди и т. Д.