Сколько контроллеров Kafka в кластере и какова цель?

Контроллер Kafka в кластере Kafka отвечает за управление лидерами разделов и отдыхом.

Если в кластере Kafka 100 брокеров, является ли контроллер только одним брокером Kafka? Итак, из 100 брокеров ли контроллер?

Как узнать, какой брокер является контроллером?

Критически ли важно управление Kafka Controller для управления системой kafka?

3 ответа

Решение

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

Более подробную информацию об обязанностях контроллера кластера можно найти здесь.

Чтобы определить, какой брокер является контроллером кластера, сначала необходимо подключиться к Zookeeper через ZK CLI:

./bin/zkCli.sh -server localhost:2181 

а потом get контроллер

[zk: localhost:2181(CONNECTED) 0] get /controller

Вывод должен выглядеть следующим образом:

{"version":1,"brokerid":100,"timestamp":"1506423376977"}
cZxid = 0x191
ctime = Tue Sep 26 12:56:16 CEST 2017
mZxid = 0x191
mtime = Tue Sep 26 12:56:16 CEST 2017
pZxid = 0x191
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x15ebdd241840002
dataLength = 56
numChildren = 0

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

[zk: localhost:2181(CONNECTED) 2] delete /controller

который должен дать вывод, аналогичный приведенному ниже:

DEBUG [Controller id=100] Resigning (kafka.controller.KafkaController)
DEBUG [Controller id=100] De-registering IsrChangeNotificationListener (kafka.controller.KafkaController)
DEBUG [Controller id=100] De-registering logDirEventNotificationListener (kafka.controller.KafkaController)
INFO [Controller id=100] Resigned (kafka.controller.KafkaController)
DEBUG [Controller id=100] Broker 200 has been elected as the controller, so stopping the election process. (kafka.controller.KafkaController)

Zookeeper - это хранилище состояния кластера Кафки. Он используется для выбора контроллера в самом начале или когда происходит сбой текущего контроллера. Контроллер также отвечает за указание другим репликам стать лидерами разделов в случае сбоя / сбоя брокера раздела.

Контроллер является одним из брокеров Kafka, который также отвечает за задачу выбора лидеров раздела (в дополнение к обычной функциональности брокера).

это контроллер только у одного брокера?

Существует только 1 контроллер за один раз.

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

Как узнать тем кто является контроллером в кафке?

Когда выбирается новый контроллер, он получает номер "эпохи контроллеров" от zookeeper. Брокеры знают текущую эпоху контроллера, и если они получают сообщение от контроллера с более старым номером, они знают, что игнорируют его

Является ли контроллер лидером?

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

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

Контроллер Kafka — это мозг кластера Kafka. Он следит за работоспособностью брокеров и принимает меры при сбоях брокеров.

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

Первый брокер, который запустится в кластере, станет контроллером Kafka, создав эфемерный узел с именем «/controller» в Zookeeper. При запуске других брокеров они также пытаются создать этот узел в Zookeeper, но получат исключение «узел уже существует», по которому понимают, что в кластере уже есть выбранный Контроллер.

Когда Zookeeper не получает сообщения пульса от контроллера, эфемерный узел в Zookeeper будет удален. Затем он уведомляет всех других брокеров в кластере об уходе контроллера через наблюдателя Zookeeper, который снова начинает новые выборы для нового контроллера. Все остальные брокеры снова попытаются создать эфемерный узел «/controller», и первый из них, которому это удастся, будет выбран новым контроллером.

Может быть возможность иметь более одного контроллера в кластере.Рассмотрим случай, когда на текущем контроллере Kafka («Контроллер_1») произошла длинная GC (сборка мусора), из-за которой Zookeeper не получил сообщение пульса от контроллера в течение настроенного периода времени. Это приводит к удалению узла «/controller» из Zookeeper, а другой брокер из кластера избирается в качестве нового контроллера («Controller_2»).

В этой ситуации у нас есть 2 контроллера «Контроллер_1» и «Контроллер_2» в кластере. Сборщик мусора «Контроллер_1» завершен, и он может попытаться записать/обновить состояние в Zookeeper. «Контроллер_2» также попытается записать/обновить состояние в Zookeeper, что может привести к тому, что кластер Kafka будет несовместим с записью как из старого, так и из нового контроллера.

Чтобы избежать этого, новая «эпоха» генерируется каждый раз, когда происходят выборы Контролера. Каждый раз, когда контроллер избирается, он получает новую более высокую эпоху посредством операции условного приращения Zookeeper.

При этом, когда старый контроллер («Контроллер_1») пытается что-то обновить, Zookeeper сравнивает текущую эпоху с более старой эпохой, отправленной старым контроллером в своем запросе на запись/обновление, и просто игнорирует ее. Все остальные брокеры в кластере также знают текущую эпоху контроллера, и если они получат сообщение от старого контроллера с более старой эпохой, они также его проигнорируют.

Другие вопросы по тегам