Что произойдет, если лидер не умер, но не сможет получать сообщения в Кафке?SPOF? - PullRequest
Новая
       45

Что произойдет, если лидер не умер, но не сможет получать сообщения в Кафке?SPOF?

2 голосов
/ 16 апреля 2019

У меня 3 брокера, 3 раздела.Каждый брокер является лидером для одного раздела и ISR для всех.Допустим, я запускал брокеров на портах 19092,29092,39092 соответственно. 

19092 - partition 0
29092 - partition 1
39092 - partition 2

Тест Half-брокера:

Я бы хотел назвать его так!Поскольку он разрешает только ВЫХОД, но не ВХОД

Теперь я добавил следующее правило iptables: 

iptables -A INPUT -p tcp --dport 29092 -j DROP

и в источнике: 

bin/kafka-console-producer --broker-list 10.54.8.172:19092 --topic ftest

Вышеупомянутое правило iptables блокирует доступ INPUT, но не ограничивает посредника от обновления его живучести с помощью Zookeeper.Таким образом, zookeeper не будет считать его мертвым и не будет проводить выборы лидера для раздела 1.

Но производитель не может подключиться к нему из-за ПРАВИЛА и, следовательно, выдает ошибку. 

org.apache.kafka.common.errors.TimeoutException: Expiring 1 record(s) for ftest-1: 1778 ms has passed since batch creation plus linger time

Это я сделал вручную, но могут быть и другие причины, по которым доступ INPUT может быть заблокирован (некоторые вредоносные программы, DDoS или что-то еще).

До ПРАВИЛА iptables: 

Metadata for ftest (from broker 1: 10.54.8.172:19092/1):

 3 brokers:

  broker 2 at 10.54.8.172:29092

  broker 1 at 10.54.8.172:19092

  broker 3 at 10.54.8.172:39092

 1 topics:

  topic "ftest" with 3 partitions:

    partition 2, leader 3, replicas: 3,1,2, isrs: 3,1,2

    partition 1, leader 2, replicas: 2,3,1, isrs: 2,3,1

    partition 0, leader 1, replicas: 1,2,3, isrs: 1,2,3

После правила iptables: 

Metadata for ftest (from broker 1: 10.54.8.172:19092/1):

 3 brokers:

  broker 2 at 10.54.8.172:29092

  broker 1 at 10.54.8.172:19092

  broker 3 at 10.54.8.172:39092

 1 topics:

  topic "ftest" with 3 partitions:

    partition 2, leader 3, replicas: 3,1,2, isrs: 3,1,2

    partition 1, leader 2, replicas: 2,3,1, isrs: 2

    partition 0, leader 1, replicas: 1,2,3, isrs: 1,2,3

Поскольку существует только один лидер, и он мертв (в том смысле, чтоне может принимать никаких сообщений), не является ли единичной точкой отказа ?

Я считаю, что в идеале должно быть двустороннее взаимодействие между брокерами Zookeeper и Kafka.Не так ли?Кафка это позволяет?Если да, то как?

Кроме того, когда 29092 заблокирован для доступа INPUT, его ISR сократился до 1.

Это может быть из-за того, что он не может получать сообщения (биения) от2 других посредника.

Если он может подключиться (OUTPUT включен), то он может записать их, и для репликации, чтобы получить подтверждение, ему необходим доступ INPUT.

Таким образом, и INPUT, и OUTPUTздесь тоже должно быть.

Брокер 29092 ничем не хуже.Выход из системы в неисправимое состояние!

1 Ответ

0 голосов
/ 16 апреля 2019

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

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

Теперь каждый брокер регистрируется как «эфемерный узел» в zookeeper.Таким образом, брокер, инициировавший сеанс zK, поддерживает членство, используя периодические тактовые импульсы (тики в терминах zK).Если брокеру не удается поставить галочку в течение интервала времени ожидания, zookeeper удаляет этот узел, и контроллер Kafka, который зарегистрировался, чтобы получить уведомление об этом событии (через zK watches ), получает уведомление.Это инициирует избрание нового лидера, если отказавший брокер является лидером для раздела.Контроллер обрабатывает выбор лидера и уведомляет всех брокеров.

Так что да, существует двусторонняя связь между Kafka и zK - но это не прямая двусторонняя связь между каждым брокером и zK, если речь идет о выборе лидера раздела.обеспокоен.Есть посредник на пути контроллера.

В вашем тесте, поскольку контроллер никогда не получает уведомления о сбое брокера 2, так что брокер остается лидером раздела 1.

Теперь я спекулирую

Ваш брокер 2, который заблокировал ввод, не может получать обновления метаданных, поэтому он защищает себя от сжатия ISR.Это может помочь .

...