Блог

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

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

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

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

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

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

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

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

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

Мой вопрос в том, почему для избрания нового лидера требуется кворум (большинство) из at 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 и открывает себя как для чтения, так и для записи.

Теперь вы, вероятно, можете оценить преимущества модели первичного резервного копирования по сравнению с моделью кворума — используя описанную выше стратегию, кластер из 3 узлов Kafka с 2 ISR может одновременно допускать сбои 2 узлов, включая сбой лидера, и все равно избирать нового лидера (хотя этот новый лидер будетприходится некоторое время отклонять новые записи, пока один из вышедших из строя узлов не заработает и не догонит лидера).

Цена, которую нужно заплатить, — это, конечно, более высокая задержка записи — в 3-узловом кластере Kafka с 2 ISR лидер должен дождаться подтверждения от обоих подписчиков, чтобы подтвердить запись клиенту (производителю). В то время как в модели кворума запись может быть подтверждена, если один из подписчиков подтвердит.

Таким образом, в зависимости от варианта использования, Kafka предлагает возможность обменять долговечность на задержку. 2 ISR означают, что у вас иногда более высокая задержка записи, но более высокая долговечность. Если вы работаете только с одним ISR, то в случае потери лидера и узла ISR у вас либо нет доступности, либо вы можете выбрать нечистые выборы лидера, и в этом случае у вас меньшая долговечность.

Обновление — Выборы лидера и предпочтительные реплики:

Все узлы, составляющие кластер, уже зарегистрированы в zK. Когда один из узлов выходит из строя, zK уведомляет узел контроллера (который сам избирается zK). Когда это происходит, один из действующих ISR выбирается в качестве нового лидера. Но у Kafka есть концепция «предпочтительной реплики», чтобы сбалансировать распределение лидерства по узлам кластера. Это включено с помощью auto.leader.rebalance.enable=true , в этом случае контроллер попытается передать лидерство этой предпочтительной реплике. Эта предпочтительная реплика является первым посредником в списке ISR. Все это немного сложно, но об этом должен знать только администратор Kafka.