Да, для высокой нагрузки лучше использовать что-то другое, но в случае высокой нагрузки, как мне кажется, и нет необходимости в отслеживании жизненного цикла задания (т.е. всех приседаний, которые описаны в статье). В моем случае речь идёт о тяжеловесных тасках, которые запускаются крайне редко и должны быть выполнены любой ценой ?
В случае, описанном вами, нужно поднимать отдельный сервис, который будет собирать только отчёт, но опять же нужно поднимать несколько инстансов этого "сборщика" - здесь опять же встаёт проблема синхронизации этих сборщиков между собой (вернулись к началу статьи), потому что если этот единственный инстанс сборщика упадет - будет грустно.
Впрочем, если есть общая база, то несложно тупо сделать запрос update Locker set instance = <my instance id> where instance is NULL. Для этого нужна одна таблица (c одной записью), а не 100.
Если при этом ещё и нужно знать, завершено ли задание успешно или нет, если нет, то сколько попыток запуска джобы было? Если не успешно, то как организовать перезапуск со смещением по времени? Как минимум потребуется чуть больше таблиц.
Задачи повтора и эксклюзивного выполнения и запуска по расписанию - это разные вещи.
К примеру, кейс формирования ежеквартального отчёта: формирование отчёта запускается в последний день каждого 3-го месяца, логика формирования отчёта громоздка и не должна происходить на нескольких инстансах одновременно, также логика использует запросы к внешним системам, которые время от времени могут не отвечать, но отчёт должен быть сформирован. После нескольких неудачных попыток создания отчёта в течение определенного времени необходимо уведомить администратора о том, что наблюдаются какие-то проблемы и прекратить попытки формирования отчёта в автоматическом режиме, но при этом через 3 месяца по-прежнему необходимо создание нового отчёта.
Чем не кейс эксклюзивного запуска по расписанию с возможностью повтора задания? ?
Если вы, например, используете какой-нибудь движок для батч-процессинга, то этим должен он заниматься, а вовсе не планировщик
Подобного движка в нашем проекте, к сожалению, не используется.
Про Apache Ratis обязательно почитаю, спасибо большое!
К сожалению, Spring Scheduler из коробки не поддерживает кластерность, т.е. все написанные в вашем приложении шедулеры будут запущены на каждом инстансе вашего приложения + с помощью коробочного шедулера нет возможности следить за жизненным циклом задания.
Тот же SchedLock, упомянутый в статье, настройка которого производится в стиле коробочного шедулера с помощью аннотаций, позволяет решить только одну проблему - запуск запланированного задания только на одном инстансе, но без возможности слежения за жизненным циклом таски: если инстанс грохнется во время выполнения задания, другие экземпляры приложения не перехватят это задание. Quartz позволяет решить как первую, так и вторую проблемы, описанные выше.
К сожалению, quartz работает только с реляционными бд, поэтому представляю каких трудов это стоило, чтобы прикрутить его к mongo. Получилось, кстати?
Вам в любом случае нужен инструмент синхронизации инстансов между собой - это либо бд, либо брокер (Кафка, например), либо какой-нибудь редис. И это будет уже кастом решение, которое потребует кмк не меньших трудозатрат, скорее всего даже больших. Других интересных библиотек, позволяющих решить данные задачи, я, к сожалению, не нашел. Может подскажете, какие решения применяли вы в кластере для работы с механизмом планировки заданий?
Интересная информация, спасибо!
Да, для высокой нагрузки лучше использовать что-то другое, но в случае высокой нагрузки, как мне кажется, и нет необходимости в отслеживании жизненного цикла задания (т.е. всех приседаний, которые описаны в статье). В моем случае речь идёт о тяжеловесных тасках, которые запускаются крайне редко и должны быть выполнены любой ценой ?
В случае, описанном вами, нужно поднимать отдельный сервис, который будет собирать только отчёт, но опять же нужно поднимать несколько инстансов этого "сборщика" - здесь опять же встаёт проблема синхронизации этих сборщиков между собой (вернулись к началу статьи), потому что если этот единственный инстанс сборщика упадет - будет грустно.
Спасибо за ответ!
Если при этом ещё и нужно знать, завершено ли задание успешно или нет, если нет, то сколько попыток запуска джобы было? Если не успешно, то как организовать перезапуск со смещением по времени? Как минимум потребуется чуть больше таблиц.
К примеру, кейс формирования ежеквартального отчёта: формирование отчёта запускается в последний день каждого 3-го месяца, логика формирования отчёта громоздка и не должна происходить на нескольких инстансах одновременно, также логика использует запросы к внешним системам, которые время от времени могут не отвечать, но отчёт должен быть сформирован. После нескольких неудачных попыток создания отчёта в течение определенного времени необходимо уведомить администратора о том, что наблюдаются какие-то проблемы и прекратить попытки формирования отчёта в автоматическом режиме, но при этом через 3 месяца по-прежнему необходимо создание нового отчёта.
Чем не кейс эксклюзивного запуска по расписанию с возможностью повтора задания? ?
Подобного движка в нашем проекте, к сожалению, не используется.
Про Apache Ratis обязательно почитаю, спасибо большое!
К сожалению, Spring Scheduler из коробки не поддерживает кластерность, т.е. все написанные в вашем приложении шедулеры будут запущены на каждом инстансе вашего приложения + с помощью коробочного шедулера нет возможности следить за жизненным циклом задания.
Тот же SchedLock, упомянутый в статье, настройка которого производится в стиле коробочного шедулера с помощью аннотаций, позволяет решить только одну проблему - запуск запланированного задания только на одном инстансе, но без возможности слежения за жизненным циклом таски: если инстанс грохнется во время выполнения задания, другие экземпляры приложения не перехватят это задание. Quartz позволяет решить как первую, так и вторую проблемы, описанные выше.
К сожалению, quartz работает только с реляционными бд, поэтому представляю каких трудов это стоило, чтобы прикрутить его к mongo. Получилось, кстати?
Вам в любом случае нужен инструмент синхронизации инстансов между собой - это либо бд, либо брокер (Кафка, например), либо какой-нибудь редис. И это будет уже кастом решение, которое потребует кмк не меньших трудозатрат, скорее всего даже больших. Других интересных библиотек, позволяющих решить данные задачи, я, к сожалению, не нашел. Может подскажете, какие решения применяли вы в кластере для работы с механизмом планировки заданий?