high availability для кронов

[grigori]

Вопрос по архитектуре.
Кто-нибудь решал задачу по репликации периодических задач, которые обычно исполняются по крону?

Практическая задача: есть endpoint devices - датчики/кассы/что угодно, с которыми надо периодически связываться.
Устройств много, 100500 штук, периоды у всех разные.
Решение в лоб: по крону запускается процесс, который по своей логике создает таски в очереди, тысяча воркеров эти таски разгребает.
Главная проблема этого подхода - когда ломается сервер или крон, который создает таски в очереди, все останавливается.
На втором сервере крон не включить - будет race condition (у девайсов бывает жесткое ограничение на периодичность запросов).
Как генерить уникальный UUID для периодических задач так, чтобы при их создании на 2 серверах не возникало race condition, я сходу придумать не могу.
Может быть, здесь нужно несколько нод с выбором лидера, как в kafka и блокчейне?

У кого есть мысли как это решать?

 

[Yoskaldyr]

https://docs.temporal.io/docs/php/distributed-cron

Это?

 

[grigori]

https://docs.temporal.io/docs/php/distributed-cron

Это?

похоже, надо изучить и сделать poc

еще у меня появилась мысль, что для решения задачи можно создать "3й уровень" - вариацию saga pattern:
на 1 уровне worker решает задачу,
на 2 уровне диспетчер создает задачи в очереди по временным меткам с отметкой статуса исполнения,
а на 3м уровне инстансы "control plane" исполняются одновременно на нескольких серверах и создают временные метки по своему алгоритму - например, записи в таблице вида (PK, remote-device, time-from, time-till), и некий алгоритм должен проверять, что диапазоны не пересекаются

 

[Yoskaldyr]

Насчет temporal.io лучше у @Wolfy-J узнавать. Т.к. php реализация от его команды

 

[grigori]

главный вопрос - насколько temporal готов для mission critical задач - вопрос если и не на миллион долларов, то на сотни тысяч точно
судя по истории про coinbase - вроде бы, готов, надо попробовать

 

[fixxxer]

Dkron - Cloud native job scheduling system | Dkron

Cloud native job scheduling system

dkron.io

Chronos: Fault tolerant job scheduler for Mesos

mesos.github.io

 

[Redjik]

https://kubernetes.io/docs/tasks/job/

ничего не подходит?

 

[grigori]

Вань, у меня, к сожалению, нет k8s в инфраструктуре.

 

[Redjik]

Хм, а если лямбд на Амазоне наплодить вместо кронов?

 

[grigori]

как в дешевых хостингах по крону курлом дергали CGI вместо CLI

но вариант интересный, лямбды могут в SQS писать, а сервисы могут просто запускаться по POD-ам без синхронизации и выгребать задачи,
то есть, SPOF никуда не девается, просто In AWS we trust

 

[AnrDaemon]

А с распределённой обработкой это всегда перекладывание ответственности.

 

[grigori]

Как вариант, можно отказаться от создания задач в моменты времени (отказ от Availabiliy), и вместо этого создавать задачи с последовательными ID, как блоки в блокчейне, так, чтобы ID задач были вычисляемы на произвольный период, а время их добавления в очередь оказывалось в некоторых интервалах.

То есть, вместо 0 2 * * * задавать период запуска в формате ISO8601 time interval.
Тогда задачи можно генерить одновременно в нескольких точках.

 

[fixxxer]

Часто в распределенных планировщиках, в том же Chronos, интервалы в ISO8601 и задаются.

Ну как бы понятно, CAP-теорему никто не отменял)

 

[grigori]

chronos хорош, надо прикинуть что быстрее - хронос или велосипед

 

[fixxxer]

Dkron не смотрел? Я сам не пробовал, но выглядит как штука с минимальным порогом вхождения при прочих равных. Единственное, что смущает, что относительно новая и не факт, что хорошо обкатанная

 

[WMix]

и омиКрон попробуй

 

[fixxxer]

и омиКрон попробуй

я уже попробовал, ну такое