Кафка: Кворумный подход к избранию нового лидера?

Question

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

В репликации первичной резервной копии лидер ожидает завершения записи на каждой реплике в группе, прежде чем подтвердить клиент. Если одна из реплик не работает, лидер удаляет ее из текущей группы и продолжает запись в остальные реплики. Неудачной реплике разрешается вернуться в группу, если она вернется и догонит лидера. С репликами f репликация первичной резервной копии может выдерживать сбои f-1.

В подходе, основанном на кворуме, лидер ожидает завершения записи в большинстве реплик. Размер группы реплик не меняется, даже если некоторые реплики не работают. Если имеется 2f+1 реплик, репликация на основе кворума может допускать сбои f реплик. Если лидер терпит неудачу, ему нужно как минимум f + 1 реплика, чтобы выбрать нового лидера.

У меня есть вопрос по поводу заявления If the leader fails, it needs at least f+1 replicas to elect a new leader в подходе, основанном на кворуме. Мой вопрос: почему кворум (большинство) в f+1 Реплики требуется для выбора нового лидера? Почему не какая-либо копия из f+1 in-synch-replica(ISR) выбрана? Зачем нам нужны выборы вместо простого выбора?

На выборах, как зоопарк выбирает окончательного лидера из оставшихся реплик? Сравнивает ли он, какая реплика обновлена ​​последним Кроме того, зачем мне нужен неравный номер (скажем, 3) zookeper, чтобы выбрать лидера вместо четного числа (скажем, 2)?

Answer 1

Кроме того, зачем мне нужен неравный номер (скажем, 3) zookeper, чтобы выбрать лидера вместо четного числа (скажем, 2)?

В системе, основанной на кворуме, такой как zookeeper, для выбора лидера требуется простое большинство из "ансамбля" - то есть узлов, которые образуют кластер zK. Таким образом, для трехузлового ансамбля сбой одного узла может быть допущен, если оставшиеся два сформируют новый ансамбль и останутся в рабочем состоянии. С другой стороны, в ансамбле с четырьмя узлами вам нужно как минимум 3 живых узла, чтобы сформировать большинство, чтобы он мог выдержать только один отказ узла. Ансамбль из пяти узлов, с другой стороны, может допускать сбои в двух узлах.

Теперь вы видите, что кластер из 3 или 4 узлов может эффективно переносить отказ только 1 узла, поэтому имеет смысл иметь нечетное количество узлов, чтобы максимизировать количество узлов, которые могут быть недоступны для данного кластера.

Выбор лидера zK основан на протоколе, подобном Paxos, который называется ZAB. Каждая запись проходит через лидера, а лидер генерирует идентификатор транзакции (zxid) и присваивает его каждому запросу на запись. Идентификатор представляет порядок, в котором записи применяются ко всем репликам. Запись считается успешной, если лидер получает подтверждение от большинства. Объяснение ZAB.

Мой вопрос: почему для избрания нового лидера требуется кворум (большинство) при репликах f+1? Почему не выбирается какая-либо реплика из f+1 in-synch-replica(ISR)? Зачем нам нужны выборы вместо простого выбора?

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

В случае Kafka - для настройки с несколькими репликами и ISR потенциально может быть несколько узлов с обновленными данными по сравнению с данными лидера.

Kafka использует 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 должен знать об этом.