@tumbler
бекенд-разработчик на python

Есть ли Стратегия борьбы со сбросом состояния RabbitMQ?

Всем привет!
В разных командах при использовании RabbitMQ в разработке ПО мы придерживались правила "RabbitMQ надежен как БД". Это позволяло ставить задачи для Celery, особо не заморачиваясь на тему того, что RabbitMQ может что-то потерять или как-то еще нарушить гарантии доставки. И в целом (при условии грамотной настройки Celery) этот подход себя оправдывает, однако есть нюансы.
  • Наши админы трижды упарывались на счет распределенного кластера кроликов, в результате получали аварии в стиле "проще перекатать кролик заново, чем разбираться в его эрланговских дампах"
  • С распространением Amazon/Kubernetes/Docker/вот-этого-всего stateful-кролик внезапно стал очень подвержен ошибкам администрирования вида "ой, а в нем данные что ли хранились? а он переехал"
  • Пару раз сталкивались с ситуациями, когда по непонятным причинам некоторые сообщения терялись. Сложно сказать, код виноват или контейнеризация, но факт - что-то нужное куда-то недолетело.


И вот вопрос: есть ли опыт по борьбе с таким поведением? Интересует общий подход к обеспечению гарантий доставки при использовании RabbitMQ в ненадежной среде.
  • Вопрос задан
  • 857 просмотров
Решения вопроса 2
@yarkin
1) Разработчики RabbitMQ ко всем потерям данных на стороне самого RabbitMQ относятся критично, так что, если в какой-то момент будете уверены, что теряет данные именно он, то смело создавайте баг (с подробностями как повторить).
2) Если админы не умеют настраивать стейтфул приложения в контейнерной среде или куча ручных операций, то это больше административная задача, чтобы научиться и, например, использовать шаблоны/чарты/т.п. для предотвращения сюрпризов. Но также RabbitMQ в контейнере нужно настраивать, чтобы не получать деградации и дампов.
3) Со стороны самого RabbitMQ есть зеркалирование очередей (queue mirroring) для дублирования данных, что позволит внезапно терять ноды (но восстановление может обойтись высоким потреблением процессора).
4) Также рекомендую логировать и идентифицировать каждое отправленное и полученное сообщение, чтобы оценивать проблему. Для большей достоверности можно включить логирование ещё и на уровне RabbitMQ (если позволяют ресурсы). На прошлой работе у нас был свой плагин для RabbitMQ, который получал копию всех полученных и отправленных сообщений, выгребал из них нужную метаинформацию и отправлял в Graylog.
5) Ну и конечно нужно делать отправку и приём с подтверждением, но это, я думаю, Вы и без меня уже делаете.
Ответ написан
dkrylov
@dkrylov
а держать очередь в бд в каком либо виде если? И оттуда цеплять, перенаправлять на раббита. А по истечении проставлять статус. Экосистема небольшая, зато, я думаю, стабильно.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
@tumbler Автор вопроса
бекенд-разработчик на python
Ну и напоследок вовремя появившаяся статья от Мегафона: https://habr.com/post/434016/
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
20 апр. 2019, в 16:31
500 руб./в час
20 апр. 2019, в 15:00
10000 руб./за проект
20 апр. 2019, в 14:48
30000 руб./за проект