Как контролировать работу скриптов-воркеров? Что лучше Crontab?

Здравствуйте,

у меня есть 6 сервисов написанных на PHP и на Golang, которые выполняют одну большую задачу.

Чтобы подзадачи выполнялись последовательно, используем очереди, первый сервис записывает данные в очередь, второй сервис их подхватывает и так далее, 6 сервис завершает цикл и задача считается выполненной.

Сервисы запускаются при помощи crontab, при помощи записи в БД контролируем статус сервиса, чтобы повторно его не запустить, если он еще выполняется.

У этого способа есть минут, все сервисы запускаются раз в минуту.

1-ый запуск сервисов:
  • 1-ый сервис отработал - записал в очередь.
  • 2-ой сервис запустился в холостую.
  • 3-ий сервис запустился в холостую.


2-ой запуск сервисов:
  • 1-ый сервис запустился в холостую.
  • 2-ый сервис отработал - записал в очередь.
  • 3-ий сервис запустился в холостую.


3-ий запуск сервисов:
  • 1-ый сервис запустился в холостую.
  • 2-ой сервис запустился в холостую.
  • 3-ий сервис отработал - задача завершена.


и такая же ситуация с 4,5 и 6 сервисами.

В итоге, до момента когда задача будет завершена и информация будет опубликована на сайте проходит до 7 минут.

Хотел спросить, есть ли способ по лучше по запуску и мониторингу сервисов?

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

Буду очень признателен, если подскажите, в каком направлении искать решение задачи.
  • Вопрос задан
  • 296 просмотров
Пригласить эксперта
Ответы на вопрос 6
  • Systemd
  • Supervisord
Ответ написан
Комментировать
saboteur_kiev
@saboteur_kiev Куратор тега Linux
software engineer
Если вам нужно запускать их последовательно, зачем вы каждый сервис запускаете в крон отдельно от других?

Сделайте скрипт, впишите в него все сервисы по очереди и запускайте скрипт раз в 10 минут?
Ответ написан
Комментировать
1210mk2
@1210mk2
Как вариант, если сервисы "падучие", помещайте в планировщик задач.
тот же RabbitMQ. Делаете 6 очередей. На каждую минимум по 1 консьюмеру.
Закидивается задача в 1ю очередь. Ее начинает обрабатывать первый консьюмер.При отработке помещает задачу в следующую очередь. При фейле задание будет обработано повторно на этом же шаге - есть режим, когда задача сама себя в очередь возвращает.
Сервис RabbitMQ крутится на сервере, консьюмеры можно запускать по крону, чтобы всегда висели резидентами. Или через flock, или демонами через supervisor.
Ответ написан
Комментировать
@MadridianFox
Web-программист, многостаночник
Когда у вас есть очередь сообщений, вам нужны программы, которые запускаются один раз и в цикле читают и обрабатывают сообщения из очереди. Ну и супервизор над ними, который будет их поднимать если они падают.

Т.е. ваши сервисы не должны запускаться по крону, а должны постоянно работать.
Ответ написан
Комментировать
@vitaly_il1
DevOps Consulting
"Продвинутые" cron'ы:
- Rundeck https://www.rundeck.com/open-source
- Airflow https://airflow.apache.org/
Ответ написан
Комментировать
@ProFfeSsoRr
Сис.админ по Linux
Тут несколько способов, перечислю по мере уменьшения "правильности" на мой взгляд:
1) переписать сервисы так, чтобы они могли быть постоянно запущенными. Это станет тогда типичной архитектурой, много раз уже реализованной людьми ранее :) Т.е. сервисы запущены 24/7 и через очередь друг в друга кидают информацию. Можно еще про саги почитать: https://habr.com/ru/company/oleg-bunin/blog/418235/
2) перейти с крона на systemd таймеры и сервисы. Реализовать запуск первого по таймеру, а дальше через systemd зависимости расписать и он сам будет всё друг за другом стартовать.
3) использовать "умный" крон типа rundeck, ну выше уже такое советовали.
P.S. А если это одна, по сути, задача, зачем она в нескольких приложениях? Возможно стоит вообще собрать их в одно каое-то, go'шное например и запускать его когда требуется.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы