Комментарии 7
Мы используем Redis как брокер сообщений. Я слышал много историй и слухов о том, что Redis теряет сообщения, что он не приспособлен быть брокером сообщений. На продакшен опыте это не подтверждается, а, как выясняется, Redis сейчас работает более производительно, чем RabbitMQ (именно с Celery, как минимум, видимо, проблема в коде интеграции с брокерами). В версии 4 починили брокер Redis, он действительно перестал терять задачи при рестартах и работает вполне стабильно. В 2016 году в Celery собирались отказаться от Redis и сконцентрироваться на интеграции с RabbitMQ, но, к счастью, этого не произошло.
Основная проблема с редисом в том, что если очередь не влазит в память, она теряется вообще вся. И это как бы by-design, решить с этим ничего нельзя. Разве что выдавать редису меньше памяти, чем на самом деле доступно и в случае аварии докидывать ему сверху.
По поводу примера, мне несколько сложно понять, что мешает сделать такую логику:
- Выкачать список нужных пользователей (только id) это не должно быть по идее настолько нагружено.
- Запустить задачи порциями при помощи
eta. - Ну и выделить это все в отдельную очередь.
То есть в статье этот вариант вроде рассматривается, но чем он вас не устроил кроме того, что сначала выполняется гигантский селект я не до конца понял. Разве что тем, что вся очередь не влазила в редис…
Основная проблема с редисом в том, что если очередь не влазит в память, она теряется вообще вся. И это как бы by-design, решить с этим ничего нельзя. Разве что выдавать редису меньше памяти, чем на самом деле доступно и в случае аварии докидывать ему сверху.
Можете подтвердить это ссылкой на источник? Все очень сильно зависит от настроек самого редиса и системы, например в дефолтном конфиге четвертой версии github.com/antirez/redis/blob/4.0/redis.conf, параметр maxmemory-policy noeviction – это значит что ни при каких обстоятельствах ни один ключ не потеряется, т.е. celery будет просто отваливаться с ошибкой при постановке новых задач, если они не влезают в память.
По поводу примера, мне несколько сложно понять, что мешает сделать такую логику:
Мне кажется на видео это момент разобран подробнее, проблемы которые мы хотели решить:
1. Маштабируемость решения: не завалить редис и решить нюансы с задачей деспечеризации.
2. Сэмулировать более подходящий для нас рейт лимит по задачам, потому что рейтлимит на воркер нас не устраивал.
Вариант засасывать все айди из базы и создавать все необходимые задачи в одной задаче диспетчеризации к сожалению не скейлится. Более того появляется одна большая точка отказа в виде задачи диспетчеризации – она долго выполняется, занимает время воркера и если с ней что-то случится во время ее работы система может оказаться в неопределенном состоянии.
Можете подтвердить это ссылкой на источник? Все очень сильно зависит от настроек самого редиса и системы, например в дефолтном конфиге четвертой версии github.com/antirez/redis/blob/4.0/redis.conf, параметр maxmemory-policy noeviction – это значит что ни при каких обстоятельствах ни один ключ не потеряется, т.е. celery будет просто отваливаться с ошибкой при постановке новых задач, если они не влезают в память.
Нет, все как вы сказали, если использовать этот ключ. то проблем никаких нет.
Мне кажется на видео это момент разобран подробнее, проблемы которые мы хотели решить:
То есть все-таки вы уперлись в редис, если я вас правильно понимаю. Просто rabbitmq такой кучей задач не завалить и не кажется подход с стандартными celery chunks бы сработал.
Но в целом большое спасибо за ответ :)
50 оттенков Celery