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

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

А при чём тут Hatsune Miku? Или это просто картинка для привлечения внимания?
Не просто. Это очень хорошая картинка для привлечения внимания.
При сельдерее же :)
Мы используем Redis как брокер сообщений. Я слышал много историй и слухов о том, что Redis теряет сообщения, что он не приспособлен быть брокером сообщений. На продакшен опыте это не подтверждается, а, как выясняется, Redis сейчас работает более производительно, чем RabbitMQ (именно с Celery, как минимум, видимо, проблема в коде интеграции с брокерами). В версии 4 починили брокер Redis, он действительно перестал терять задачи при рестартах и работает вполне стабильно. В 2016 году в Celery собирались отказаться от Redis и сконцентрироваться на интеграции с RabbitMQ, но, к счастью, этого не произошло.

Основная проблема с редисом в том, что если очередь не влазит в память, она теряется вообще вся. И это как бы by-design, решить с этим ничего нельзя. Разве что выдавать редису меньше памяти, чем на самом деле доступно и в случае аварии докидывать ему сверху.


По поводу примера, мне несколько сложно понять, что мешает сделать такую логику:


  1. Выкачать список нужных пользователей (только id) это не должно быть по идее настолько нагружено.
  2. Запустить задачи порциями при помощи eta.
  3. Ну и выделить это все в отдельную очередь.

То есть в статье этот вариант вроде рассматривается, но чем он вас не устроил кроме того, что сначала выполняется гигантский селект я не до конца понял. Разве что тем, что вся очередь не влазила в редис…

В комменты призывается Bahusss
Основная проблема с редисом в том, что если очередь не влазит в память, она теряется вообще вся. И это как бы 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 бы сработал.


Но в целом большое спасибо за ответ :)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий