Кроме того, зачем мне нужен неравный номер (скажем, 3) zookeper, чтобы выбрать лидера вместо четного числа (скажем, 2)?
В системе, основанной на кворуме, такой как zookeeper, aВыбор лидера требует простого большинства из «ансамбля» - то есть узлов, которые образуют кластер zK.Таким образом, для трехузлового ансамбля отказ одного узла мог бы быть допущен, если бы оставшиеся два сформировали новый ансамбль и оставались в рабочем состоянии.С другой стороны, в ансамбле с четырьмя узлами вам нужно как минимум 3 живых узла, чтобы сформировать большинство, чтобы он мог выдержать только один отказ узла.Ансамбль из пяти узлов, с другой стороны, может допускать отказы двух узлов.
Теперь вы видите, что кластер из 3 или 4 узлов может эффективно переносить отказ только одного узла, поэтому имеет смысл иметь нечетное количество узлов.чтобы максимизировать количество узлов, которые могут быть недоступны для данного кластера.
Выбор лидера zK основан на протоколе Paxos, который называется ZAB .Каждая запись проходит через лидера, а лидер генерирует идентификатор транзакции (zxid) и присваивает его каждому запросу на запись.Идентификатор представляет порядок, в котором записи применяются ко всем репликам.Запись считается успешной, если лидер получает подтверждение от большинства.Объяснение ZAB .
Мой вопрос: почему для избрания нового лидера необходим кворум (большинство) в репликах f + 1?Почему не выбирается какая-либо реплика из f + 1 in-synch-replica (ISR)?Почему нам нужны выборы, а не просто какой-либо выбор?
Что касается выбора, а не выбора - в целом, в распределенной системе с возможной последовательностью, вам нужно проводить выборы, потому что нет выборапростой способ узнать, какой из оставшихся узлов имеет последние данные и, таким образом, может стать лидером.
В случае Kafka - для настройки с несколькими репликами и ISR потенциально может быть несколько узлов с актуальными данными лидера.
Кафка использует zookeeper только в качестве инструмента для выбора лидера.Если лидер раздела Kafka не работает, контроллер кластера Kafka получает информацию об этом через zK, и контроллер кластера выбирает один из ISR в качестве нового лидера.Таким образом, вы можете видеть, что эти "выборы" отличаются от выборов новых лидеров в системе, основанной на кворуме, такой как zK.
Какой брокер среди ISR "выбран", немного сложнее (см. ) -
Каждая реплика хранит сообщения в локальном журнале и поддерживает несколько важных позиций смещения в журнале.Смещение конца журнала (LEO) представляет хвост журнала.Верхний водяной знак (HW) является смещением последнего принятого сообщения.Каждый журнал периодически синхронизируется с дисками.Данные до сброшенного смещения гарантированно сохраняются на дисках.
Таким образом, при сбое лидера выбирается новый лидер:
- Каждая выжившая реплика в ISR регистрируется вZookeeper.
- Реплика, которая регистрируется первой, становится новым лидером.Новый лидер выбирает свое смещение конца журнала (LEO) в качестве нового верхнего водяного знака (HW).
- Каждая реплика регистрирует слушателя в Zookeeper, так что она будет проинформирована о любых изменениях лидера.Каждый раз, когда реплика уведомляется о новом лидере: если реплика не является новым лидером (она должна быть подписчиком), она усекает свой журнал до своего HW, а затем начинает догонять нового лидера.Лидер ждет, пока все сохранившиеся реплики в ISR не будут обнаружены или не пройдет настроенное время.Лидер записывает текущий ISR в Zookeeper и открывает себя как для чтения, так и для записи.
Теперь вы, вероятно, сможете оценить преимущества первичной модели резервного копирования по сравнению с моделью кворума - при использовании вышеупомянутой стратегии кластер узлов Kafka 3 с 2 ISR может допускать отказы двух узлов - включая отказ лидера - на в то же время и все еще выбирают нового лидера (хотя этот новый лидер должен будет отклонить новые записи на некоторое время, пока один из неисправных узлов не заработает и не догонит лидера).
Цена, которую нужно заплатить, является, конечно, более высокой задержкой записи - в кластере Kafka с 3 узлами с 2 ISR лидер должен ждать подтверждения от обоих последователей, чтобы подтвердить запись клиенту (производителю). Принимая во внимание, что в модели кворума запись может быть подтверждена, если один из последователей подтверждает.
Таким образом, в зависимости от варианта использования, Kafka предлагает возможность торговли долговечностью за время ожидания. 2 ISR означает, что у вас иногда выше задержка записи, но выше срок службы. Если вы работаете только с одним ISR, то в случае, если вы потеряете лидера и узел ISR, у вас либо не будет доступности, либо вы можете выбрать нечистых выборов лидера , в этом случае у вас будет более низкая стойкость.
Обновление - выборы лидера и предпочтительные реплики:
Все узлы, которые составляют кластер, уже зарегистрированы в zK. Когда один из узлов выходит из строя, zK уведомляет узел контроллера (который сам выбирается zK). Когда это происходит, один из живых ISR выбирается в качестве нового лидера. Но у Kafka есть концепция «предпочтительной реплики», чтобы сбалансировать распределение лидерства по узлам кластера. Это активируется с помощью auto.leader.rebalance.enable=true, при этом контроллер будет пытаться передать лидерство этой предпочтительной реплике. Эта предпочтительная реплика является первым посредником в списке ISR. Это все немного сложно, но об этом должен знать только админ Kafka.