#java #spring #spring-batch
Вопрос:
У нас есть пакетное приложение Spring, которое планируется запускать каждые 30 минут, которое создает рабочих в облаке в виде отдельных модулей.
В классе конфигурации один из компонентов подключается к базе данных и считывает некоторые свойства. Если по какой-либо причине это соединение с БД не удается, то рабочий не запускается, а основное задание не запускается снова через 30 минут.
Это происходит потому, что, если рабочий процесс завершается сбоем при запуске, он не обновляет конечный статус в БД или не сообщает об этом ведущему как о сбое. Следовательно, Мастер предполагает, что он все еще работает, и не запускает Пакет снова.
У кого-нибудь есть какие-либо предложения о том, как с этим справиться и как обеспечить, чтобы Мастер снова запускал рабочих в запланированный срок?
Комментарии:
1.
that creates workers on the Cloud as separate pods: Как создаются рабочие? Как управляется жизненный цикл работников? Можете ли вы поделиться более подробной информацией о своей настройке?2. Рабочие создаются с помощью загрузчика ресурсов Docker. Периодически основное задание выполняет запрос, который извлекает список записей, подлежащих обработке. Как только у него появится список, в зависимости от размера списка, он создаст один или несколько рабочих модулей и распределит нагрузку между ними. Эти рабочие модули затем обрабатывают данные и переходят в состояние завершения.
3. Менеджер не может знать о статусе работника, если работник не сообщает об этом. Однако менеджер может быть настроен с таймаутом для этого. Поэтому, если вы хотите, чтобы менеджер вышел из строя до выполнения следующего расписания, вам необходимо установить время ожидания менее 30 минут. Тем не менее, я бы рекомендовал, чтобы у каждого расписания была своя работа, чтобы неудачное задание не повлияло на последующие расписания.
4. Спасибо. Есть ли также удобное свойство, которое можно добавить в приложение.properties, чтобы установить время ожидания (не удалось его найти), или нам нужно установить его с помощью кода?
5. Нет, вы можете установить время ожидания на
MessageChannelPartitionHandlerили через построительRemotePartitioningManagerStepBuilder#timeout.
Ответ №1:
проблема заключается в высокой доступности.
Вы можете добавить redis в начало базы данных. Если мы не можем прочитать конфигурацию из redis, а затем подключить базу данных.
2 наконец, добавьте службу повторных попыток, такую как resilience4j, в свой компонент, чтобы прочитать вашу конфигурацию несколько раз.
3rdly, для предупреждения, вы можете добавить соответствующую службу предупреждений в своем облаке, чтобы сообщить вам, какой модуль не запустился. Затем вы сможете перезапустить этот модуль вручную или автоматически.
Комментарии:
1. Хорошо, мы можем добавить устойчивость к многократному чтению и слой Redis, но нет ли способа автоматически перепланировать, чтобы планировщик запустил и снова запустил пакет? Проблема в том, что на производстве партии планируется запускать в ночное время. И все виды работ по техническому обслуживанию также происходят ночью. Таким образом, если проводилось техническое обслуживание и пакет запускался в одно и то же мгновение, он вообще не запускается на следующий день, если мы не перезапустим его вручную.
2. Я прошу прощения. Мне приснился кошмар, когда я пытался реализовать очередь сообщений в реальном времени, так что у меня даже не было времени проверить сообщение на stackoverflow. Думаю, сейчас я понимаю, что ты имеешь в виду. Вам должны понадобиться реестр служб и обнаружение. Если рабочий модуль вышел из строя из-за технического обслуживания или каких-либо других ошибок. Мы бы получили уведомление. Если ваша работа в quartz выполняется по графику 30 минут, служба избыточного расписания уведомит работника о выполнении работы через 30 минут. Если эта 30-минутная задержка повлияет на вашу систему, вы должны сохранить информацию об ошибке где-нибудь, а затем вызвать ее после того, как центр перезапустит работника.