Ack или Nack в rabbitMQ

Я использую rabbitMQ, я беру каждое сообщение из очереди с помощью basic_get без автоматической процедуры acking, что означает, что сообщение остается в очереди до тех пор, пока я не напишу или не напишу сообщение.

Иногда у меня есть сообщения, которые не могут быть обработаны из-за какого-то исключения, которое не позволяет им полностью обрабатываться.

Вопрос в том, что имеет значение, если я обойду сообщения в успехе и исключение, я имею в виду, что сообщения о результатах всегда будут выходить из очереди, так что имеет значение, если я использую ack или nack в этом сценарии? Может быть, я пропущу что-то о том, когда использую каждое письмо?

Ответ 1

Команда basic.nack, по-видимому, является расширением RabbitMQ, которое расширяет функциональные возможности basic.reject, чтобы включить режим массовой обработки. Оба включают флаг "бит" (т.е. логический) requeue, поэтому у вас действительно есть несколько вариантов:

  • nack/reject с requeue=1: сообщение будет возвращено в очередь, из которой он пришел, как если бы это было новое сообщение; это может быть полезно в случае временного сбоя на стороне потребителя.
  • nack/reject с requeue=0 и настроенный Мертвый обмен письмами (DLX), опубликует сообщение на этот обмен, позволяя ему быть поднятым другой очередью
  • nack/reject с requeue=0 и ни один DLX не будет просто отбрасывать сообщение
  • ack удалит сообщение из очереди, даже если DLX настроен.

Если у вас нет DLX-конфигурации, всегда использовать ack будет то же самое, что и nack/reject с requeue=0; однако использование логически правильной функции с самого начала даст вам больше гибкости для настройки по-разному позже.

Ответ 2

Ack и Nack оба удаляют сообщение из очереди, разница в том, что когда вы наберете сообщение, оно переходит в DLX (очередь мертвых букв), если для этой очереди есть один.