apache-kafka - 如果 leader 没有死但是在 Kafka 中收不到消息会怎样？单点故障？

Question

我有 3 个代理，3 个分区。每个代理是一个分区的领导者和所有的 ISR。假设我分别在端口 19092,29092,39092 上运行代理。

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

半经纪人测试:

我想这样命名!因为它只允许 OUTPUT 而不允许 INPUT

现在，我添加了以下 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 更新其 liveness 。所以zookeeper不会认为它死了，所以不会对partition 1进行leader选举。

但是，由于规则的原因，生产者无法连接到它，因此会抛出错误。

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

因为只有一个领导者并且它死了(从某种意义上说它无法接收任何消息)，不是单点故障吗？

I think, there must ideally be 2 way communication between Zookeeper and Kafka brokers. Isn't it? Does Kafka allow it? If so, how?

Also, when the 29092 is blocked for INPUT access its ISR shrinked to 1.

It could be because it is not able to receive any messages (heartbeats) from the other 2 brokers.

If it can connect (OUTPUT is enabled), then it can write to them and for the replication to get acknowledged, it needs INPUT access.

So both INPUT and OUTPUT should be there here also.

The broker 29092 is as good as nothing here. Leaving the system in an unrecoverable state!

Answer 1

您的问题可能最好通过理解 Kafka 如何利用 zookeeper 原语来维护和组织集群状态来回答。

在 Kafka 中，领导选举是由充当 Controller 的经纪人之一精心策划的。只有一个 Controller ，它是使用 zookeeper 在 broker 中选出的。

现在，每个代理都将自己注册为 zookeeper 中的“临时节点”。因此发起 zK session 的代理通过使用周期性心跳(zK 术语中的滴答)来维护成员资格。如果代理未能在超时间隔内打勾，zookeeper 将删除该节点，并且已注册自己以接收该事件通知(通过 zK watches )的 Kafka Controller 会收到通知。如果失败的代理是分区的领导者，这将触发新的领导者选举。 Controller 处理 leader 选举并通知所有 broker。

是的，Kafka 和 zK 之间存在双向通信——但就分区领导者选举而言，这并不是每个代理和 zK 之间的直接双向通信。在 Controller 的方式中有一个中间人。

在您的测试中，由于 Controller 永远不会收到代理 2 故障的通知，因此该代理仍然是分区 1 的领导者。

现在开始，我正在推测

输入被阻止的代理 2 无法接收元数据更新，因此它通过将 ISR 缩小到自身来 self 隔离。这可能 help