Комментарии 10
Из своего многолетнего опыта в джаве могу заказать, что quartz - это одна из худших библиотек, что я видел. Создавать этот мусор в БД, кучу конфигураций и весь этот вышеупомянутый ад только для того чтобы сделать то, что делает Spring Scheduler из коробки - это за гранью добра и зла. До сих пор помню, сколько я мучался что бы адаптировать это под mongo db.
Просто не используйте это поделие.
К сожалению, Spring Scheduler из коробки не поддерживает кластерность, т.е. все написанные в вашем приложении шедулеры будут запущены на каждом инстансе вашего приложения + с помощью коробочного шедулера нет возможности следить за жизненным циклом задания.
Тот же SchedLock, упомянутый в статье, настройка которого производится в стиле коробочного шедулера с помощью аннотаций, позволяет решить только одну проблему - запуск запланированного задания только на одном инстансе, но без возможности слежения за жизненным циклом таски: если инстанс грохнется во время выполнения задания, другие экземпляры приложения не перехватят это задание. Quartz позволяет решить как первую, так и вторую проблемы, описанные выше.
К сожалению, quartz работает только с реляционными бд, поэтому представляю каких трудов это стоило, чтобы прикрутить его к mongo. Получилось, кстати?
Вам в любом случае нужен инструмент синхронизации инстансов между собой - это либо бд, либо брокер (Кафка, например), либо какой-нибудь редис. И это будет уже кастом решение, которое потребует кмк не меньших трудозатрат, скорее всего даже больших. Других интересных библиотек, позволяющих решить данные задачи, я, к сожалению, не нашел. Может подскажете, какие решения применяли вы в кластере для работы с механизмом планировки заданий?
Можно например завести под задания по расписанию отдельные cron-cli микросервисы и менеджить кластерность, расписание и жизненный цикл через k8s
Можно даже оставить формирование отчета вашему многокластерному монолиту с точкой входа в виде эндпоинта, а по крону будет запускаться микросервис который вызовет соответствующий эндпоинт.
Скедулер и не должен поддерживать синглетон на кластере. Для этого существуют другие инструменты, например zookeeper или что-то типа Apache Ratis.
Впрочем, если есть общая база, то несложно тупо сделать запрос update Locker set instance = <my instance id> where instance is NULL. Для этого нужна одна таблица (c одной записью), а не 100.
если инстанс грохнется во время выполнения задания, другие экземпляры приложения не перехватят это задание
Задачи повтора и эксклюзивного выполнения и запуска по расписанию - это разные вещи.
Разве запуск отчёта вручную, с точки зрения вашей логики по повторам и пр, чем-то отличается от запуска по расписания?
Если вы, например, используете какой-нибудь движок для батч-процессинга, то этим должен он заниматься, а вовсе не планировщик
К сожалению, quartz работает только с реляционными бд, поэтому представляю каких трудов это стоило, чтобы прикрутить его к mongo. Получилось, кстати?
Только часть функционала
Спасибо за ответ!
Впрочем, если есть общая база, то несложно тупо сделать запрос update Locker set instance = <my instance id> where instance is NULL. Для этого нужна одна таблица (c одной записью), а не 100.
Если при этом ещё и нужно знать, завершено ли задание успешно или нет, если нет, то сколько попыток запуска джобы было? Если не успешно, то как организовать перезапуск со смещением по времени? Как минимум потребуется чуть больше таблиц.
Задачи повтора и эксклюзивного выполнения и запуска по расписанию - это разные вещи.
К примеру, кейс формирования ежеквартального отчёта: формирование отчёта запускается в последний день каждого 3-го месяца, логика формирования отчёта громоздка и не должна происходить на нескольких инстансах одновременно, также логика использует запросы к внешним системам, которые время от времени могут не отвечать, но отчёт должен быть сформирован. После нескольких неудачных попыток создания отчёта в течение определенного времени необходимо уведомить администратора о том, что наблюдаются какие-то проблемы и прекратить попытки формирования отчёта в автоматическом режиме, но при этом через 3 месяца по-прежнему необходимо создание нового отчёта.
Чем не кейс эксклюзивного запуска по расписанию с возможностью повтора задания? ?
Если вы, например, используете какой-нибудь движок для батч-процессинга, то этим должен он заниматься, а вовсе не планировщик
Подобного движка в нашем проекте, к сожалению, не используется.
Про Apache Ratis обязательно почитаю, спасибо большое!
Насколько понимаю, тут следует разделить шедулинг и систему единичной копии. Кстати, решение единичной копии можно же решать и в отрыве от шедулинга. Можно, например вообще запускать отдельную копию которая и будет делать только отчет, тогда и проблемы единичного запуска нет. Да и контролировать потом эту копию легче.
В случае, описанном вами, нужно поднимать отдельный сервис, который будет собирать только отчёт, но опять же нужно поднимать несколько инстансов этого "сборщика" - здесь опять же встаёт проблема синхронизации этих сборщиков между собой (вернулись к началу статьи), потому что если этот единственный инстанс сборщика упадет - будет грустно.
Кажется тут смешали воедино две проблемы — исполнение периодических заданий, и сохранение стэйта заданий в распределенной среде. Первая часть замечательно решается средствами Спринга, вторая решается в полном отрыве от первой части, и диапазон возможных решений тут от использования всяких БД, включая Redis, и до IMDG, например Hazelcast. Последний позволит держать распределенный стейт вообще парой строчек.
С производительностью у quartz беда. Там, насколько я помню 2 лока на кластер: instance_name/trigger_access и instance_name/state_access. На сколько-нибудь высоком рейте всё встает колом на конкуренции за получением лока.
Интересная информация, спасибо!
Да, для высокой нагрузки лучше использовать что-то другое, но в случае высокой нагрузки, как мне кажется, и нет необходимости в отслеживании жизненного цикла задания (т.е. всех приседаний, которые описаны в статье). В моем случае речь идёт о тяжеловесных тасках, которые запускаются крайне редко и должны быть выполнены любой ценой ?
Публикации
Ни одно задание не будет провалено: Spring Boot и Quartz в режиме cluster