Лучшие практики Hazelcast для отработки отказа при параллельной обработке

Я новичок в Hazelcast. Итак, у вас есть вопрос о лучших методах обработки сбоев во время параллельной обработки:

Освоение Hazelcast, раздел 6.6, стр. 96:

Work-queue не имеет высокой доступности: каждый участник создаст один или несколько локальных ThreadPoolExecutors с обычными рабочими очередями, которые выполняют реальную работу. Когда задача отправлена, она будет помещена в рабочую очередь этого ThreadPoolExecutor и не будет поддерживаться Hazelcast. Если что-то случится с этим участником, вся необработанная работа будет потеряна.

Задача:

Предположим, у меня есть 1 главный узел и 2 подчиненных. Запускаю трудоемкую задачу с

executor.submitToAllMembers (new TimeConsumingTask())

Итак, каждый узел что-то обрабатывает. И пока они все что-то обрабатывают, один из рабов выходит из строя

Вопросы:

  1. Невозможно повторно запустить работу с отказавшим элементом на другом узле, верно?
  2. Есть ли другой (желательно лучший) подход, чем повторный запуск всего набора заданий для всего кластера? (В случае, если TimeConsumingTask равно Runnable)
  3. Есть ли другой (желательно лучший) подход, чем повторный запуск всего набора заданий для всего кластера? (В случае, если TimeConsumingTask равно Callable и я хочу получить Future в качестве результата вычисления кластера)

java hazelcast
person VB_    schedule 12.02.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я предполагаю, что под «обработкой сбоев» вы имеете в виду сценарий, когда узел в кластере выходит из строя ....

Вопрос 1 Не автоматически. Вы правы, предполагая, что задачи выполнения Hazelcast не являются отказоустойчивыми. Однако, если вы смогли справиться с ошибкой задачи, я не вижу причины, по которой вы не могли повторно отправить работу другому участнику кластера.

Вопрос 2. Трудно понять, что на самом деле делает ваша TimeConsumingTask - как и в случае с любым механизмом распределенного выполнения, обычно лучше составить длительную задачу как серию более мелких задач. Если вы не можете составить свою задачу из более мелких элементов, тогда нет - на самом деле нет лучшего подхода, чем повторная отправка всей работы еще раз.

Вопрос 3. К этому вопросу применимо то же самое, что и к вопросу 2. Возвращение будущего из отправки задачи не поможет вам в значительной степени, если узел откажет. Фьючерсы предоставляют вам возможность ждать (необязательно в течение определенного периода тайм-аута) результата и предоставляют возможность отмены задачи.

Как правило, для обработки сбоя узла я бы посмотрел, поможет ли ExecutionCallback - в этом случае вы получите уведомление о сбое, и я в настоящее время предполагаю, что сбой узла подпадает под это. Когда ваш обратный вызов получает уведомление о сбое, вы можете повторно отправить задание.

Вы также можете изучить некоторые другие подходы, существующие вне основного Hazelcast API. Hazeltask - это проект на GitHub, который обещает обработку отказа и повторную отправку задач - так что, может быть, стоит взглянуть?

person Mike    schedule 17.02.2015