Безотказные очереди в RabbitMQ: Гарантированная доставка сообщений

[unstopppable]

Так из коробки же, если коньюмер упал, сообщение вернется в ready и его подхватит другой, или оно останется ждать

[Foxion]

Тут же вопрос не совсем в consumer, а в других системах, которые могут не отвечать n количество времени. Ну и в данном механизме так же нет задержки, т.е. сообщение будет моментально попадать в другой consumer

[zubrbonasus]

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

[savostin]

А не надо его туда возвращать. Делайте ack и в лог ошибку. Или сообщение в другую очередь, которую слушает приложение и обрабатывает. Зачем возвращать туда, где его некому обрабатывать?

[savostin]

С мобилки не смог найти, но помню что такой вопрос решался через ttl, оттуда во вторую очередь с большим ttl и оттуда обратно в первую. Не помню как с количеством раз решалось, наверное количеством очередей. Но в Вашем случае решение на уровне приложения, а не очереди. Те в каждом консьюмере надо решать вопрос отдельно.

[Foxion]

Да, в моём случае очереди полностью управляются со стороны приложения. Соответственно есть "Базовый Consumer" от которого наследуются остальные.

[savostin]

Это пока у Вас относительный монолит и одна команда.

[posledam]

Схема работы механизма безотказных очередей

Скорее, это схема как создать себе явно лишних проблем.

Ретраить можно (и нужно) на стороне консюмера. Пока консюмер ретраит, очевидно, он не может обрабатывать другие события. Решается увеличением консюмеров. Консюмеры можно увеличивать в рамках одного физического соединения, открывая множество каналов.

По существу же, сам по себе ретрай может помочь только если ошибка является транзиентная: потеря связи с БД, сервисами, временная загруженность канала или той же БД. Просто так ретраить: довольно наивное решение, если что-то сломано в самом сообщении, то ретраи не помогут. И с другой стороны, если временно сломалась БД, то абсолютно все сообщения будут заретраены, но.. зачем? Новые сообщение будут поступать и поступать, а старые висеть в ожидании на 120 сек, окей! Но скоро вся эта лавина сообщений повалится обратно, просто со смещением.

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

Механизм поражает своей наивностью и обманчивостью. Правильный подход: взял сообщение? Обработай! Правильный файловер, мониторинг, расчёт нагрузки -- это профессиональные грамотные решения. "Ретрай-очереди" распространённый самообман.

Очереди ошибочных сообщений, по факту намного хуже, чем transaction inbox/outbox. Они -- мёртвый груз, и следствие кривого мониторинга. Если проблему можно обнаружить только наличием сообщений в некой очереди-отстойнике, это плохой мониторинг. И что делать администраторам в данном случае? Из одной очереди внезапно родилось целых три, и со всеми надо как-то работать. А если у нас бизнесовых очередей десятки, сотни? Умножай на 3?

Взял сообщение -- обработай. Не городи огород :) Поверь, лучше воевать с качеством и скоростью обработки сообщений, грамотно продумать, что делать с ошибками. В очереди может появиться действительно кривое сообщение, положи его в базу, не надо заставлять таскаться инвалида по разным очередям в надежде, что оно волшебным образом исправиться. В основном, проблемы возникают именно в логике обработки. Если логика поломанная, то никакой повтор её не исправит. Если проблемы на среде, то они скорее всего массовые для данного типа сообщений, и до устранения причин также не имеет ни малейшего смысла переливать из пустого в порожнее.