KK
@cykooz Почитал твои хотелки про приоритеты.
На сколько я помню спеку AMQP 0.9. Там нет возможности помотреть время сколько висит задача, пока она тебе не прилетела по подписке.
Соответственно сказать можешь ты её выполнить или нет из-за загрузки ты сможешь только когда она тебе прилетит.
Тут я вижу несколько вариантов.
1. Агрессивно включать backpressure на основании метрик которые есть у воркера. Плохо работает в разрезе одной очереди, когда в ней может быть больше одного типа задачь.
2. Использовать выделенные ресурсы под обработку очередей dead letter, ставить каждой задачи маленький ttl, и в этих выделенный ресурсах, максимально быстро переназначать на новую очередь. Из плюсов - не пересекается с основными воркерами. Из минусов - часть ресурсов будет ждать беды и не будет заниматься обработкой основных задач.
3. Если подхода 2 недостаточно, можно написать плагин к RabbitMQ на Erlang и там уже в рантайме рулить тем, как работает рассылка сообщений по подписке.
Или смотри не в сторону RabbitMQ а чего-то более экзотического, где приоритет и работа с ним - часть протокола.
На сколько я помню спеку AMQP 0.9. Там нет возможности помотреть время сколько висит задача, пока она тебе не прилетела по подписке.
Соответственно сказать можешь ты её выполнить или нет из-за загрузки ты сможешь только когда она тебе прилетит.
Тут я вижу несколько вариантов.
1. Агрессивно включать backpressure на основании метрик которые есть у воркера. Плохо работает в разрезе одной очереди, когда в ней может быть больше одного типа задачь.
2. Использовать выделенные ресурсы под обработку очередей dead letter, ставить каждой задачи маленький ttl, и в этих выделенный ресурсах, максимально быстро переназначать на новую очередь. Из плюсов - не пересекается с основными воркерами. Из минусов - часть ресурсов будет ждать беды и не будет заниматься обработкой основных задач.
3. Если подхода 2 недостаточно, можно написать плагин к RabbitMQ на Erlang и там уже в рантайме рулить тем, как работает рассылка сообщений по подписке.
Или смотри не в сторону RabbitMQ а чего-то более экзотического, где приоритет и работа с ним - часть протокола.
Ну мы тут в целом придумали как это разрулить, если писать свой собственный таск-роутер в консьюмере. Проблема только в том, что не хочется всё писать с нуля, а в тот же Celery наверное не вклинится по нормальному.
