Избегание расщепления мозга, голоса и кворума

Предположим, что у вас есть n процессов, n > 2. Вы хотите иметь между ними соглашение, что один из них должен быть активным. Поэтому им нужно проголосовать, чтобы определить, кто из них активен.

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

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

Единственным доступным механизмом связи между ними является обмен сообщениями pub-sub (не точка-точка).

Доступны одна или несколько баз данных, но ни одна база данных не должна быть единственной точкой отказа. То есть. было бы очень нежелательно, если бы все процессы были доступны для работы, и им было отказано в потере одной базы данных.

Дизайн? Какие сообщения нужно публиковать?

Ответ 1

Теория:

Это выборы лидера, которая представляет собой форму Консенсусная проблема, также иногда называемая Проблема двух генералов. При некоторых наборах допущений (полностью асинхронно и сообщения могут быть потеряны) это оказалось невозможным, и доказательство особенно элегантно.

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

На практике мы преодолеваем это, используя детекторы отказа для имитации синхронной системы.

Наиболее широко известный алгоритм, который разрешает консенсус, Paxos, который может терпеть отказ до половины участвующих узлов. Paxos имеет репутацию очень трудно реализовать, так как даже незначительные недоразумения в деталях протокола уничтожают его правильность.

Практические решения:

Хотя проблема в целом довольно сложная, получить рабочие системы намного проще. Доступны полные реализации Paxos или эквивалентные алгоритмы. Apache Zookeeper - лучшее, что я знаю. Для вашей конкретной проблемы я уверен, что это будет ваш самый быстрый маршрут. Другие реализации Paxos находятся вокруг, и также может быть возможно создать что-то в сетевых избыточных виртуальных ip-инструментах, таких как Wackamole. Я считаю, что версии большинства коммерческих баз данных высокого класса предлагают функции кворума как (дорогой) вариант.

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

Например, если одна точка отказа допустима, потому что восстановление, скорее всего, будет быстрым, тогда проблема тривиальна: просто выполните один специальный node.

Другим подходом может быть создание системы вокруг идемпотентных действий, поэтому дублирование обработки становится допустимым.

Наконец, вы можете разделить рабочую нагрузку на пул не избыточных систем: здесь отказы будут откладывать обработку до восстановления, но только для элементов с этим node, а не для всей рабочей нагрузки.

Эти виды компромиссов настолько проще, что они часто являются лучшим выбором. Нужно взвесить полезность полного решения против сложности его реализации и посмотреть, действительно ли это значение. Вот почему многие практические системы просто используют 2 Phase или 3 Phase Commit, хотя они блокируются в некоторых сценариях: снижение доступности является допустимым по сравнению со сложностью полной системы кворума.

Ответ 2

Я не понимаю, что сообщение pub-sub.

Если они получают какие-то рабочие объекты из внешнего источника, и вы хотите, чтобы один из них обрабатывал работу, вы могли бы взять пространство хеш-значений, 2 ^ 64, разделить пространство на количество узлов каждый node принимает кусок. Каждый node может хэшировать рабочие объекты по мере их поступления и определять, принадлежит ли им.

Ответ 3

Посмотрите, как это делают протоколы маршрутизации (OSPF и IS-IS), и посмотрите, работает ли это для вас. Они выбирают лидера (и в случае OSPF, резервного лидера).