(постргрес) и периодически выполняться приложением по расписанию. Приложение в одной реплике (монолит). Расписание хранится в самой джобе, джобы многошаговые (для этого в джобе прописывается статус, а обработчик по некоему fsm по-очереди исполняет некоторые действия, обновляет статус джобы, и забывает до следующей итерации).
Вопрос: как лучше реализовать расписание?
Приходит на ум формат cron, но нет ни малеишей идеи, как это подружить с SQL
Привет. ТК крон имеет минимальную точность в 1 секунду, а для некоторых тасок и реже, то можно раз в N доставать крон записи из таблицы, по ним генерить конкретные таски воркерам и их тоже сохранять в бд. Сложнее поддержать какие-нибудь правила выполнения на запуск сервера - там есть пара таких кейсов.
1. По поводу нескольких инстансов: SELECT FOR UPDATE SKIP LOCKED 2. По поводу пропущенных тасок: брать прошедшие таски со статусом «в ожидании» и на пару минут вперёд. С кроном все равно так же надо будет делать
Я говорил про расписание не в виде временных точек, а в виде периодичности, как например cron
Тогда можно использовать тикер. Создаёшь задачи и каждому назначаешь период выполнения. Ну или крон. Я подумал про другое расписание.
1) не до конца понятно - что именно нужно будет лочить и что апдейтить под локом? запись вида * * * * * не меняется все время. Вот 2 демона сделали с ней select for update одновременно - сначала первый, потом он снял свой лок и затем второй сделал то же самое. запись остается неизменной; как второму понять, что ему уже не надо порождать таски на выполнение задачи после первого?
Статус в бд поменять
видимо не поменять, а вставить запись статус, тип таски + время. в бд лежит вот такое: * * * * * task1 надо вставить - task1 17.00 created
если эту вставляемую запись совмещать со статусом выполнения таски - вроде норм. но будет много записей. если иметь 1 запись под тип таски и в ней поле с последним временем тригера - записей будет меньше, но как-то менее надежно, чтоли. все-таки кроны уже реализованы много где и я бы завязался на чужую имплементацию. Будь то исходный crontab или кронджобы в каком-нибудь сервисе, типа кубера.
У меня в данном случае ничего, кроме одного инстанса го и одного инстанса постгри нету 🙂 Поэтому завязываюсь на них
ОК, но имхо при деплое есть шанс всеж наличия 2 инстансов в одно время. потому что другой вариант деплоя - будет с простоем.
Обсуждают сегодня