Выбирал тут планировщик для периодических заданий по обслуживанию приложения.
С Quartz что-то все устали возиться, ленились отдельную схему под его таблички выделять и кончили тем, что возжелали свежих проблем нового, неизведанного.
И, в том числе:
- Поддержки работы со множеством узлов в кластере;
- Поддержки персистентности заданий;
- Простоты использования;
- Простоты развертывания.
Конечно – open source с подходящей лицензией. И spring-boot-starter в комплекте – для максимального удовольствия.
Первым в гонку влезает Quartz – он здесь ужé и у́же применяться не желает!
Вторым идёт истинно безликий средний JobRunr – откуда-то вынырнул и смылся куда-то.
А против всего недостаточно хорошего у нас, как пелось, есть третий путь: молодёжный и свежий, только из-под клавиатуры – db-scheduler!
(Если не заглядывать в git log, а мы и не будем).
Таблички все же любят? Кто нет – можно без любви, она суха и беспристрастна при любом отношении (но ориентацию предпочитает альбомную):
| Критерий | Quartz | JobRunr | db-scheduler |
|---|---|---|---|
| Cluster-friendly | + | + | + |
| Персистентные задачи | + | + | + |
| История запусков | + | + | +/- |
| Простота использования | +/- | +/- | + |
| Простота развертывания | +/- | + | + |
| Служебных таблиц в БД | 11 (-) | 5 (+/-) | 1 (+) |
| Ретраи | Вручную (-) | Поставка (+) | Поставка (+) |
| Звёзд в GitHub | 6,2k | 2,3k | 1,2k |
| Дата последнего релиза | Окт 2019 (-) | Июл 2024 (+) | Июл 2024 (+) |
| Лицензия | Apache 2.0 | LGPL v3 | Apache 2.0 |
Quartz
По Кварцу понятно – он остановился в развитии (Достиг нирваны? Ждёт тепловой смерти вселенной?).
Делает много табличек – делает больно глазкам (да-да, можно и исправить, но лень же). В поставке нет ретраев.
Создание заданий смотрится очень энтерпрайзно, если вы в Индии – хватайте Кварц!
JobRunr
У JobRunr есть UI-панелька, Healthcheck из коробки, API-шка для работы с задачами, поддержка NoSQL хранилищ – и совсем нет совести!
Нет и не было…
Хочет много денег за такие пустячки, как:
- автоматический рестарт собственного служебного сервера при падениях;
- использование открытой Spring-транзакции в заданиях;
- интервал опроса задач менее 5 секунд.
Всё это решается усердной ручной работой, но – без приятных ощущений.
А ещё у него тяжелые запросы во вьюшке для дашборда и построения метрик. И умирание сервера вместе с liveness пробами при потере коннекта к БД, после чего отстреливается под. И название – из семи символов! И… Ладно, не буду придираться.
db-scheduler
О, от db-scheduler веет ветром перемен! Самим свои существованием он, как будто, подбивает впасть
в грех починки исправного! Соблазняет, как в истории про змею и яблоко.
Ну и кое-что полезное имеет и умеет тоже: мало (очень) сторонних зависимостей, код понятный и простой, Healthcheck в поставке, метрики – тоже, заявляет высокую производительность, умеет создавать задания в одном сервисе и выполнять в другом, создает впечатление просты перехода на него.
При этом – из коробки в нём нет истории выполнений задания (есть плагин) и UI-панели (тоже плагин).
И id-шник заданию при запуске надо вручную создавать. Не выглядит особо опасным занятием, если честно.
Что делать?
Простыня выше ☝ совершенно точно не является индивидуальной инвестиционной рекомендацией, если только вы не инвестируете в таблицы БД и строчки в редакторе (снова поприветствуем Индию!). Никакой другой рекомендацией она не является тоже.
Личный выбор каждого – TITS or GTFO, а подбор планировщика – не так уж, в сущности, важен 🙂