Зачем нужен celery?

Question

[Андрей Пронин]

Итак если брать сухую информацию из мануалов получаем опрделение:

Celery это ничто иное как распределённая очередь заданий, реализованная на языке Python.

Итак, что я тут понял, что это очередь.
Но очередь очень простая структура данных, зачем для неё celery, почему бы самому не создать?
Почему это оно только для заданий? Откуда такая специализация?
Какие реальные проблемы celery решало в вашей практике и почему именно оно? (интересно именно реальное применение у вас)

И извините новичка, если вопрос совсем глупый, но хотелось разобрать этот вопрос.
-----------
Спасибо!

Answer 1

[Руслан Гильфанов]

Например, очередь заданий по конвертации видео для веб-приложения на Django.

Попытка выполнять такую задачу в Django непосредственно при обработке запросов по-умолчанию будет приводить к 504 Gateway Timeout (слишком долгий запрос) со стороны Nginx или иного HTTP-сервера.

Попытка делать это с помощью Cron и произвольных команд Django -- немного неудобна. Допустим, Cron выполняет произвольную команду Django раз в 1 минуту:
python3 path/manage.py convert_next_video
, при этом первый видео файл будет конвертироваться 5 минут, после этого будет помечен в базе данных как is_converted (конвертирован) и команда на этом завершится. Через минуту cron снова запустит команду для конвертации следующего файла.

Но за 5 минут файл ещё не будет помечен как конвертированный, поэтому cron за 5 минут создаст 4-5 процессов, которые будут конвертировать один и тот же файл.

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

Но что будет если процесс упадёт? Отмечать время начала конвертирования в базе данных и если прошло больше n часов, конвертировать повторно -- так себе решение.

И что если пользователи загрузят 10 файлов каждый из которых будет конвертироваться 30 минут? Через 10-11 минут на сервере будут работать 10 процессов конвертирующих видео. Большая нагрузка на сервер. Можно завести в базе данных таблицу в которой отмечается сколько файлов конвертируется в данный момент.

Решив использовать cron для долгих по выполнении задач, нам придётся решать целый ряд проблем.

Comments

[Андрей Пронин]

Почему самому не создать эту очередь как обычный объект в python?

[Андрей Пронин]

Спасибо!

[Руслан Гильфанов]

Андрей Пронин, если Вы написали веб-приложение -- оно может работать в нескольких процессах. В таком случае, у вас будет несколько очередей.

Так же процессы с веб-приложением не принято делать вечными. В том же uwsgi обычно ставят настройки, чтобы процесс перезапускался через каждые 5-10 тысяч запросов.

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

В общем, для веб-приложений проще использовать celery, чем писать собственный аналог.

Если же у вас настольное (desktop) приложение, тогда celery может и не нужен. В настольном приложении можно и в обычном списке (list) хранить, скажем, кортежы (tuple) из имён функций и аргументов с которыми их надо вызвать.

Например, один поток (thread) настольного приложения кладёт туда задачи, а другой поток берёт и выполняет.

Answer 2

[Петр Васильев]

Стоит использовать фреймворки из-за того, что они создают унифицированную среду, которую смогут понять все, кто прочитал документацию. К своему решению вы не напишите документации. Фреймворки дают базовый и скучный код, который никто не любит писать.