Отложенные ретраи силами RabbitMQ

[mark_ablov]

Вроде это стандартный подход. Разве что я добавлял retryNo в payload, а не использовал заголовок.

[alexey_and_kazakov]

Подход, действительно, не уникальный. Но, как показывает практика, не все о нём знают.
Изменение payload — тоже вариант. Мы выбрали заголовок, потому что предпочли не изменять тело сообщения, и заголовки обновляются «кроликом» за нас.

[spions]

Почему не использовали готовое решение: github.com/rabbitmq/rabbitmq-delayed-message-exchange или celery (если только python)?

[alexey_and_kazakov]

Честно говоря, мне кажется, мы не знали об этом плагине. Но думаю, мы бы не стали ставить «experimental yet fairly stable and potential suitable for production use» плагин на продовый кластер RabbitMQ.
Celery используем в python-проектах, но с ним бывали внезапные утечки памяти. Предложенное решение реализовано для golang-проекта. А примеры сделал на python из-за его большей популярности.

[ilnuribat]

habr.com/ru/company/dreamkas/blog/332798
вот такое у меня было решение, совсем просто, без exchange

[alexey_and_kazakov]

Если правильно понял, вы храните задачу в памяти приложения за счет

await Bluebird.delay(wait - estimatedTime);

Мы намеренно отказались от такого подхода.
Можно узнать, как себя показывает ваше решение? Есть ли проблемы? Какие примерно RPS и количество откладываемых задач?

[ilnuribat]

не совсем
мы мы берем задачу в память приложения и ждем, когда наступит его время. в случае чего-то плохого, отказа, падения приложения — rabbit заберет задачу обратно к себе в очередь, поэтому не теряется

[Yerkwell]

Разные таймауты можно выставлять не на уровне очереди, а на уровне отдельного сообщения: заголовок expiration.
www.rabbitmq.com/ttl.html#per-message-ttl-in-publishers

[alexey_and_kazakov]

Да, можно. Но нужно держать в голове минусы такого подхода: по вашей ссылке чуть ниже есть Caveats. При разных таймаутах на сообщение может сложится ситуация, когда находящееся в голове очереди сообщение с бОльшим ttl блокирует уже "протухшие" сообщения, стоящие за ним.

[Calc]

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

[shishmakov]

Не описан вариант, когда сообщение попадаёт в dead_letter_queue из-за ошибки в формате самого сообщении. В таком случае оно будет утеряно после нескольких попыток возврата в Consumer?

[SeekerOfTruth]

alexey_and_kazakov у нас в проекте через реббит ретраи организованы с помощью следущего механизма:
если сообщение нужно исключить из очереди(возникла ошибка) — то оно попадёт в другую очередь с ttl и увеличенным на один счётчиком ретраев. через время из ttl очереди оно вернётся в основную. если же счётчик ретраев превышает какое то значение — то сообщение попадает в очередь отстойник для дальнейшего изучения. На очередь отстойник стоят алерты с нотификацией в телеграм

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