Как стать автором
Обновить

Комментарии 4

Сейчас мы используем эту схему для выполнения только периодических последовательных задач, но ее можно использовать и тогда, когда важно начать выполнять задачу в определенной время, без смещения времени на само исполнение. Для этого достаточно повторно запланировать задачу после попадания сообщения в supervisor.

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

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

отправляем ack.

ack и noack в некоторых библиотеках реббита выполняются только в том же потоке, куда пришел пакет. Так что для некоторых задач не доходит, либо только сам факт доставки пакета. Обычно используем свою систему учета на любом кеш сервере (редис, мемкешд)

Эта схема у нас работает уже полгода

почти 4 года работаем по этой схеме, больше чем на 20 проектах.
Только есть еще воркер-множитель, когда нужно сделать рассылку
1 пакет с эвенном множится на общее количество получателей и кладется в wait-dead-queue-5s (время жизни 5 секунд, под некоторые задачи 5 минут и т.д.)

Если с RabbitMQ что-то случилось и сообщения пропали, тогда нужно вручную смотреть, что потерялось,

полный лог решает эту проблему.
Да и log-queue при уже полных фатальных ошибках никто не отменял
Также про durable очереди не надо забывать.

а также про Supervisor.

это который supervisord на питоне?

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

Вместо dead letter можно ещё рассмотреть https://github.com/rabbitmq/rabbitmq-delayed-message-exchange
В таком случае вы можете совсем избавиться от hatchery queues и использовать topic routing как полагается. Он правда:


This plugin is considered to be experimental yet fairly stable and potential suitable for production

Мы всерьез рассматривали его для production, но потом потребность исчезла.

На нашем кластере RabbitMQ такой плагин стоит, но для критичных сервисов мы его не используем, так как при обновлении кластера, есть риск, что плагин на новую версию не подойдет, или будет работать не корректно.
Тоже рассматривали для онайн игры под эмуляцию ботов, то один jar файл заменяет его на 100% при минимальных затратах на разработку. Уже больше 4х лет работает без перезапуска с возможностью бесконечно множить воркеры. Это если говорить про шедулы, жизнь которых не превышает 5 минут.

А для долгосрочных (сутки-месяц) быстрее свой написать на любой атомарной БД формата ключ-значение (можно найти на ютубе первые попытки реализации инстаграмма, очень интересные решения там)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий