Основное восстановление RabbitMQ не работает

Question

У нас есть длительная очередь RabbitMQ.Когда потребитель получает элемент из очереди, он обрабатывает его и затем подтверждает его.Если потребитель не может обработать элемент, он печатает ошибку, ожидая, что кто-то решит проблему, и останавливается.Подтверждение не отправляется.Когда потребитель перезапускает элемент, который он получает, это следующий элемент в очереди, а не элемент без подтверждения.Basic.Recover () не помогает (использование клиента .NET).Любые идеи, как заставить его работать как очередь - всегда получать первый элемент, если он не подтвержден.

Answer 1

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

Так что Basic.Recover() не работает (сообщение было помещено обратно в очередь для дальнейшей обработки), просто не работает так, как вы ожидали.

Что-то в глубине моего сознания говорит мне, что вы можете быть в состоянии получить желаемое поведение, установив счетчик предварительной выборки, равный 1, и подключив к очереди не более одного потребителя.время, но я не могу гарантировать, что это так.Стоит попробовать.Однако даже если это сработает, не стоит полагаться на то, что дело останется навсегда, и при таком низком числе предварительной выборки, вероятно, пострадают сообщения вашего потребителя в секунду.

Answer 2

Сообщения могут использоваться двумя способами: noAck = false или noAck = true

noAck - это параметр для Model.BasicConsume и Model.BasicGet

Когда для noAck установлено значение true, сообщенияавтоматически удаляется из очереди после доставки.Если для noAsk установлено значение false, сообщения удаляются только при вызове basicAck.

Если noAck = false и вы не вызываете basicAck, сообщение останется, но вы не будете получать сообщения от других потребителей, пока не перезапустите приложение (или закройте соединение, которое потребляло его первым).Если вы позвоните в BasicReject, сообщение будет доставлено подписчику.

Надеюсь, это поможет.

Answer 3

RabbitMQ, кажется, исправил часть этой проблемы начиная с 2.7.0 , так как теперь сообщения будут помещаться в очередь в порядке публикации. Хотя, если у вас в очереди более одного подписчика, у вас все еще может быть сообщение, прибывающее из исходного заказа.

Answer 4

Вы можете получить это поведение, имея пару очередей, один высокий приоритет и один обычный приоритет.Установите количество предварительных выборок равным 1, а затем переключайтесь между очередями, используя basic.get.В большинстве случаев приоритетная очередь будет пустой, но когда вы захотите запросить, вместо этого снова опубликуйте сообщение в очереди с высоким приоритетом.

Это работает в сценарии, в котором несколько процессов используют поток сообщений,и один процесс решает выручить сообщение.Это сообщение будет почти сразу же обработано другим процессом.