Служба распределенного окна

Question

У меня есть библиотека классов, которая работает внутри службы Windows. Эта библиотека имеет давно запущенные потоки для опроса электронной почты (которая может быть разбита на задачи), обработки сообщений и т. Д. И работает хорошо.

Это часть продукта, которую нужно масштабировать, добавляя узлы. В настоящее время я определяю, какие клиенты обрабатываются одним узлом.

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

Он построен на C # / .NET и MS SQL Server и хотел бы придерживаться этих технологий.

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

Answer 1

1) Каждая установленная служба Windows регистрируется в базе данных с уникальным идентификатором .

2) Пока ваша служба жива, отправьте сердцебиение. Это сердцебиение может быть простым обновлением поля DateTime, когда служба последний раз регистрировалась. Вы можете обновить поле непосредственно в базе данных или перейти через веб-службу.

3) Создайте таблицу, которая определяет набор задач и назначенный unique_id машины, выполняющей эту задачу. Это может быть первым пришел первым обслужен. Машина может выбрать любую задачу, которую она выберет, и получить исключительные права на эту задачу, зарегистрировавшись в этой таблице. Я предпочитаю этот подход больше, чем централизованное управление, потому что вам не нужно беспокоиться о задачах, которые не выполняются, когда ваш централизованный контроллер выходит из строя.

4) Определите значение времени ожидания для сердцебиения. Каждый из ваших распределенных сервисов будет проверять наличие задач, которые не были подняты или истекли. Поддержание сердцебиения для любой машины, выполняющей задачу, не должно зависеть от того, сколько времени занимает задача. То есть, если задача A занимает 5 минут, machineA все равно должен обновить свое сердцебиение в течение этих 5 минут, чтобы machineB не помечал его как отключившийся.

5) В зависимости от сложности вашей задачи вам может потребоваться столбец состояния, который обновляет работник.

Answer 2

Мой подход заключается в том, чтобы распределить эту услугу на несколько компьютеров и координировать ее с помощью PAXOS или аналогичного алгоритма для управления выборами лидера. Таким образом, когда служба находится в узле, служба на других серверах может занять эту позицию. В более практическом плане я бы определенно использовал Apache Zookeeper для координации выборов лидеров.

Answer 3

Моим проектом будет центральная служба, которая будет обслуживать и распределять рабочие места, а также другие рабочие службы, которые фактически обрабатывают задания.Поэтому, когда нужно выполнить некоторые задания, они будут добавлены в очередь в центральной службе, служба уведомит об этом рабочие службы.Далее каждый работник будет пытаться получить работу для выполнения.Если задание назначено работнику, он будет обновлять статус задания в зависимости от того, успешно оно выполнено или не выполнено.Используя этот дизайн, вы можете легко масштабировать до любого количества рабочих сервисов, сколько хотите, и если один или два рабочих не влияют на остальные, потому что работа считается незавершенной, так что другие работники могут забрать и обработать ее.