high availability для кронов

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Вопрос по архитектуре.
Кто-нибудь решал задачу по репликации периодических задач, которые обычно исполняются по крону?

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

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

grigori

( ͡° ͜ʖ ͡°)
Команда форума
похоже, надо изучить и сделать 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 - вроде бы, готов, надо попробовать
 
Сверху