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

Question

[German Zvonchuk]

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

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

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

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

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

1-ый запуск сервисов:

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

2-ой запуск сервисов:

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

3-ий запуск сервисов:

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

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

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

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

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

Буду очень признателен, если подскажите, в каком направлении искать решение задачи.

Comments

[ThunderCat]

rabbitMQ?

Answer 1

[Дмитрий Шицков]

• Systemd
  
• Supervisord
  

Answer 2

[Saboteur]

Если вам нужно запускать их последовательно, зачем вы каждый сервис запускаете в крон отдельно от других?

Сделайте скрипт, впишите в него все сервисы по очереди и запускайте скрипт раз в 10 минут?

Answer 3

[1210mk2]

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

Answer 4

[Иван Корюков]

Когда у вас есть очередь сообщений, вам нужны программы, которые запускаются один раз и в цикле читают и обрабатывают сообщения из очереди. Ну и супервизор над ними, который будет их поднимать если они падают.

Т.е. ваши сервисы не должны запускаться по крону, а должны постоянно работать.

Answer 5

[Vitaly Karasik]

"Продвинутые" cron'ы:
- Rundeck https://www.rundeck.com/open-source
- Airflow https://airflow.apache.org/

Answer 6

[Валентин]

Тут несколько способов, перечислю по мере уменьшения "правильности" на мой взгляд:
1) переписать сервисы так, чтобы они могли быть постоянно запущенными. Это станет тогда типичной архитектурой, много раз уже реализованной людьми ранее :) Т.е. сервисы запущены 24/7 и через очередь друг в друга кидают информацию. Можно еще про саги почитать: https://habr.com/ru/company/oleg-bunin/blog/418235/
2) перейти с крона на systemd таймеры и сервисы. Реализовать запуск первого по таймеру, а дальше через systemd зависимости расписать и он сам будет всё друг за другом стартовать.
3) использовать "умный" крон типа rundeck, ну выше уже такое советовали.
P.S. А если это одна, по сути, задача, зачем она в нескольких приложениях? Возможно стоит вообще собрать их в одно каое-то, go'шное например и запускать его когда требуется.