Как улучшить архитектуру сервиса отложенных задач?

Question

[Олег Лобач]

Необходимо реализовать сервис, выполняющий http-запросы в определенное время. Установка таймера осуществляется передачей сообщения через очередь (RabbitMQ).
Сервис представлят собой job-server с точным временем запуска задачи.

Наилучшее решение, которое смог придумать: хранить полученные задачи в БД. Каждая задача имеет абсолютное время запуска. Отдельный демон периодически (например, раз в секунду/) выбирает из базы задачи, дата страбатывания которых меньше текущего времени + длительность периода срабатывания. Если записи найдены, выполнить запрос для каждой из задач. Повторить цикл.
Добавление задач в пул (БД) осуществляется отдельным демоном, слушающим очередь.

Требования:
- минимальный период между добавлением задачи и её срабатыванием - 30 сек
- точность указания времени срабатывания - 1 сек
- максимальный период установки таймера - не ограничен
- порядок срабатывания зависит только от даты срабатывания, но не зависит от порядка поступления их в пул
- язык для реализации сервиса - php 5.6

Есть ли более оптимальные/эффективные варианты? Может есть готовые решения? Либо можно ли улучшить мой вариант?

Answer 1

[smple]

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

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

Технологии для написания демонов https://daemon.io/ или reactphp.org можно еще почитать про создание демонов на php, но для этой задачи php не лучший язык, задача небольшая можно реализовать на чем угодно.

Comments

[Олег Лобач]

Ваше предложение отличается от моего только способом получения новых задач из хранилища: по внешнему сигналу вместо периодического опроса. Но такой вариант требует либо просыпаться периодически для обработки сигналов, либо копать библиотеки типа libenv.
По поводу технологии - естественно, php не самый лучший вариант для демона, но не хочется без крайней необходимости вводить в проект новые технологии.

[smple]

bladeofsteel: смысл в том что он один раз получает задачу из очереди и если новая не добавлялась он результат держит у себя(в памяти и повторно не лезет в базу).

Минус крона в том что он указывается с точностью до минуты.
Еще существенный минус подхода в cron, что есть race condition и соответсвенно надо делать файлик что процесс запущен чтобы не выполнить случайно дважды одну и туже задачу (теоритически такая штука может быть)

[Олег Лобач]

smple: так я и не предлагал использовать крон

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

Что Ваш, что мой варианты имеют как достоинства, так и недостатки. И пока Вы меня не убедили, что сигналы и хранение списка в памяти лучше периодического теребоньканья БД.

[smple]

bladeofsteel: нету цели убедить.
Выбирать надо вариант который больше подходит в текущий момент.

И вам логичней использовать вариант с cron это не хорошо и не плохо это решение, надо у него лишь учитывать race condition (делать файлик когда запущен и не позволять запускать повторную копию).

Теперь к тому варианту что я предложил:
1. Принимать задачи может кто угодно и складывать их куда и как удобней, надо лишь послать сигнал процессу что список задач изменен, определять что задача в далеком будущем или сейчас в том месте не логично (не он отвечает за выполнения отложенных задач).
2. Мы не храним весь список задач в памяти процесса, мы храним ближайшую дат, наступления задачи и id это задачи например (ну или задачу целиком), эта задача вычисляется в момент добавления новой задачи в очередь(он может быть как раньше так и позже).
3. Про горизонтальное масштабирование, вариант с кроном еще хуже если он запущен на нескольких серверах.

Я лишь привел другой пример у которого есть несомненно минусы и плюсы.

[Олег Лобач]

smple: я нигде ни разу не написал, что хочу использовать крон. зачем Вы так упорно его критикуете? :)

[smple]

bladeofsteel: сам крон мне очень нравиться, была ситуаций когда делали подобное и потом был race condition и для борьбы с ним в начале создавали файлик pid (что обработка задача уже запущенна)

Потом переписали на простейщий цикл и хватало с головой.

Сейчас у нас на node обычный цикл который дергает php код в бесконечном цикле, а демон написанный на node в systemd лежит (supervizord или forever аналогичные штуки можно почитать)
supervisord.org
https://github.com/foreverjs/forever
Это гораздо лучше cron подходит
Сам по себе крон хорош но не в текущем контексте.

[Олег Лобач]

smple: про супервизор в курсе, спасибо. иногда его использую, иногда monit