Как правильно организовать работу длительных запланированных задач?

Question

[shibanovan]

Добрый день! Для самообучения хочу написать приложение с вебинтерфейсом, котороя проходило бы по серверам и собирала бы с них файлы себе в архив.
Делать думаю на фласке, но суть не в этом. Не знаю как правильно организовать часть по сбору файлов с серверов. Как я сам представляю - это должен быть какой-то пул воркеров (отдельный процесс для каждого сервера), при этом в веб-интерфейсе хотелось бы смотреть текущее состояние воркера - т.е. от него нужно получать инфо.
Пока идея такая - веб-приложение на фласке - по сути интерфейс для базы данных с заданиями. И отдельно приложение, читающее эту БД. Но вот как организовать мультипоточность и обратную связь для веб-интерфейса?

Comments

[Модератор]

shibanovan дорогой пользователь, настоятельно рекомендуем еще раз обратить самое пристальное внимание на п. 3.1 регламента работы сервиса (и, в особенности, на его последний абзац).
В противном случае ваши вопросы будут удаляться по причине тег-спама, а систематические нарушения приведут к блокировке учетной записи.

[shibanovan]

Модератор, А почему вы решили, что остальные теги не подходят? И почему оставили только тэг python, если flask упоминался лишь вскользь? Вопрос именно теоретический - с точки зрения архитектуры и алгоритмов. Поэтому я поставил тэги алгоритмы и программирование

Answer 1

[Антон Коновалов]

Если хотите именно Фласк, или иной фреймворк с WSGI-интерфейсом - у вас два пути.
1) Упороться с Celery, который нереально монструозен и в ряде случаев приводит к неизбежной кастомизации "под себя". Сюда же RabbitMQ или иной брокер очередей. СУБД для хранения результатов и статусов работы.
2) Пишите ещё одно независимое приложение "рядом": Взамен Celery сделайте что-нибудь своё, но попроще. Асинхронное или многопоточное, если для нужд самообучения - можно и такое и такое. Но тут снова транспорт сообщений, RabbitMQ или иной брокер.

Если на Фласке свет клином не сошёлся - можно сразу взять Tornado или AsyncIO и сделать "два в одном". Отдача веб-контента не будет сильно мешать асинхронной работе с серверами. В этом случае будет всё внутри одного сервера. Вопрос масштабируемости здесь оставим за рамками, вам пока оно ни к чему заморачиваться.

P.S. Поищите на ютубе доклады Романа Иманкулова, он очень хорошо излагает на тему своих "велосипедов" взамен Celery, etc.

Comments

[shibanovan]

Большое спасибо! Оч полезно

[shibanovan]

А если бы вы реализовывали по второму варианту - независимое приложение "рядом" как вы видите алгоритм получения заданий и отдача результатов воркерами?
У меня пока вырисовывается примерно такой алгоритм: запускаем к примеру, 4 воркера:
1ый берет задания с 1го по 4
2ой с 4го по 8ое
и т.е. Как только воркер завершает своб очередь заданий - он лезет за следующими

Касаемо текущего статуса выполнения задания вот совсем теряюсь... в процессе воркера в отдельную. таблицу писать?

[Антон Коновалов]

shibanovan, в самом простом варианте я бы создал табличку Task (хоть даже и в SQLIte), cо всеми данными для работы, датой начала, датой завершения (удобнее оценивать пропускную способность и производительность) и полем статуса (PENDING, WORK, FAILED, DONE). На брокеры сообщений пока не смотрите. У вас нет хайлоада, это же учебная задача в конце концов.
Воркеры я бы делал асинхронными, но вы всё же попробуйте на многопоточности и асинхронности.
Нужен отдельный бесконечный цикл в треде, который будет смотреть, сколько есть новых задач в статусе PENDING. Потом надо или порождать воркеры или посылать сообщения к уже работающим. Посылать лучше ID задачи. При получении задачи воркер меняет ей статус на WORK, по окончании DONE, пишет результаты в таблицу или же подробности ошибки (вдруг сервер недоступен или таймаут или плохой URL, etc.)
Оооочень примитивная схема, но примерно так обычно всё и работает.

[shibanovan]

И ещё раз большое спасибо!

Answer 2

[Сергей Горностаев]

Celery, RQ и т.п.