Комментарии 12
Вроде это стандартный подход. Разве что я добавлял retryNo
в payload, а не использовал заголовок.
+2
Почему не использовали готовое решение: github.com/rabbitmq/rabbitmq-delayed-message-exchange или celery (если только python)?
0
Честно говоря, мне кажется, мы не знали об этом плагине. Но думаю, мы бы не стали ставить «experimental yet fairly stable and potential suitable for production use» плагин на продовый кластер RabbitMQ.
Celery используем в python-проектах, но с ним бывали внезапные утечки памяти. Предложенное решение реализовано для golang-проекта. А примеры сделал на python из-за его большей популярности.
Celery используем в python-проектах, но с ним бывали внезапные утечки памяти. Предложенное решение реализовано для golang-проекта. А примеры сделал на python из-за его большей популярности.
+2
habr.com/ru/company/dreamkas/blog/332798
вот такое у меня было решение, совсем просто, без exchange
вот такое у меня было решение, совсем просто, без exchange
0
Если правильно понял, вы храните задачу в памяти приложения за счет
await Bluebird.delay(wait - estimatedTime);
Мы намеренно отказались от такого подхода.
Можно узнать, как себя показывает ваше решение? Есть ли проблемы? Какие примерно RPS и количество откладываемых задач?
0
Разные таймауты можно выставлять не на уровне очереди, а на уровне отдельного сообщения: заголовок expiration.
www.rabbitmq.com/ttl.html#per-message-ttl-in-publishers
www.rabbitmq.com/ttl.html#per-message-ttl-in-publishers
0
Да, можно. Но нужно держать в голове минусы такого подхода: по вашей ссылке чуть ниже есть Caveats. При разных таймаутах на сообщение может сложится ситуация, когда находящееся в голове очереди сообщение с бОльшим ttl блокирует уже "протухшие" сообщения, стоящие за ним.
+2
Не знаю, на всех версиях или нет, но пока предыдущее сообщение не отработает, таймаут следующего не будет вызван
т.е. кладем сообщение на 10 секунд и сразу еще одно на 5 секунд.
Второе сообщение умрет только после смерти первого (ну еще выборка количества сообщений на это может повлиять)
т.е. кладем сообщение на 10 секунд и сразу еще одно на 5 секунд.
Второе сообщение умрет только после смерти первого (ну еще выборка количества сообщений на это может повлиять)
0
Не описан вариант, когда сообщение попадаёт в dead_letter_queue из-за ошибки в формате самого сообщении. В таком случае оно будет утеряно после нескольких попыток возврата в Consumer?
0
alexey_and_kazakov у нас в проекте через реббит ретраи организованы с помощью следущего механизма:
если сообщение нужно исключить из очереди(возникла ошибка) — то оно попадёт в другую очередь с ttl и увеличенным на один счётчиком ретраев. через время из ttl очереди оно вернётся в основную. если же счётчик ретраев превышает какое то значение — то сообщение попадает в очередь отстойник для дальнейшего изучения. На очередь отстойник стоят алерты с нотификацией в телеграм
т е разница с описанной выше схемой — что есть третья очередь для разбора почему сообщение не получается обработать консюмером(причина — либо долго лежат другие сервисы, либо ошибка в коде. в обоих случаях сообщение можно вернуть в основную очередь после фикса)
если сообщение нужно исключить из очереди(возникла ошибка) — то оно попадёт в другую очередь с ttl и увеличенным на один счётчиком ретраев. через время из ttl очереди оно вернётся в основную. если же счётчик ретраев превышает какое то значение — то сообщение попадает в очередь отстойник для дальнейшего изучения. На очередь отстойник стоят алерты с нотификацией в телеграм
т е разница с описанной выше схемой — что есть третья очередь для разбора почему сообщение не получается обработать консюмером(причина — либо долго лежат другие сервисы, либо ошибка в коде. в обоих случаях сообщение можно вернуть в основную очередь после фикса)
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Отложенные ретраи силами RabbitMQ