卡夫卡：基于群体的方法来选举新的领导者？

Question

有两种保持副本同步的常见策略，即主备份复制和基于仲裁的复制，如此处所述

\n\n

\n

在主备复制中，领导者会等待组中每个副本的写入完成，然后再确认客户端。如果其中一个副本发生故障，领导者会将其从当前组中删除，并继续写入其余副本。如果失败的副本返回并赶上领导者，则允许其重新加入组。通过 f 个副本，主备复制可以容忍 f-1 故障。

\n\n

在基于仲裁的方法中，领导者会等待，直到大多数副本上的写入完成。即使某些副本已关闭，副本组的大小也不会改变\xe2\x80\x99t\n。如果有 2f+1 个副本，\n 基于仲裁的复制可以容忍 f 个副本失败。如果领导者失败，则至少需要 f+1 个副本才能选举新的领导者。

\n

\n\n

If the leader fails, it needs at least f+1 replicas to elect a new leader我对基于法定人数的方法中的声明有疑问。我的问题是为什么f+1需要 at 副本的法定人数（多数）来选举新的领导者？f+1 为什么不选择同步副本（ISR）之外的任何副本？为什么\n我们需要选举而不是简单的任意选择？

\n\n

对于选举，zookeeper 如何从剩余副本中选举出最终的领导者？它会比较哪个副本是最新更新的吗？另外，为什么我需要奇数数量（比如 3）的 Zookeper 来选举领导者，而不是偶数数量（比如 2）？

\n

Answer 1

另外，为什么我需要奇数数量（比如 3）的 Zookeper 来选举领导者，而不是偶数数量（比如 2）？

在像 Zookeeper 这样的基于仲裁的系统中，领导者选举需要“集合”（即形成 zK 集群的节点）中的简单多数。因此，对于 3 节点集成，如果剩余两个节点形成新的集成并保持运行，则可以容忍一个节点故障。另一方面，在四节点集成中，至少需要 3 个节点存活才能形成多数节点，因此它只能容忍 1 个节点故障。另一方面，五个节点的集成可以容忍 2 个节点故障。

现在您看到 3 节点或 4 节点集群只能有效地容忍 1 个节点故障，因此使用奇数个节点来最大化给定集群中可能出现故障的节点数是有意义的。

zK 领导者选举依赖于名为ZAB的类似 Paxos 的协议。每次写入都会经过领导者，领导者会生成一个事务ID（zxid）并将其分配给每个写入请求。id 表示在所有副本上应用写入的顺序。如果领导者收到多数人的确认，则认为写入成功。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 中注册一个侦听器，以便它会收到任何领导者更改的通知。每次副本收到有关新领导者的通知时：如果副本不是新领导者（它必须是追随者），它会将其日志截断到其硬件，然后开始追赶新领导者。领导者会等待，直到 ISR 中所有幸存的副本都赶上或已经过了配置的时间。领导者将当前的 ISR 写入 Zookeeper 并开放自己进行读取和写入。

现在，您可能会意识到主备份模型与仲裁模型相比的好处 - 使用上述策略，具有 2 个 ISR 的 Kafka 3 节点集群可以同时容忍 2 个节点故障（包括领导者故障），并且仍然选出一个新的领导者（尽管新的领导者必须拒绝新的写入一段时间，直到其中一个失败的节点上线并赶上领导者）。

当然，付出的代价是更高的写入延迟 - 在具有 2 个 ISR 的 3 节点 Kafka 集群中，领导者必须等待两个追随者的确认才能确认对客户端（生产者）的写入。而在仲裁模型中，如果其中一个追随者确认，则可以确认写入。

因此，根据用例，Kafka 提供了以持久性而非延迟为代价的可能性。2 个 ISR 意味着有时会有更高的写入延迟，但耐用性更高。如果您仅使用一个 ISR 运行，那么万一您失去了领导者和 ISR 节点，您要么没有可用性，要么您可以选择不干净的领导者选举，在这种情况下，您的持久性较低。

更新 - 领导者选举和首选副本：

组成集群的所有节点都已在 zK 中注册。当其中一个节点发生故障时，zK 通知控制节点（该节点本身由 zK 选举产生）。当这种情况发生时，其中一名实时 ISR 会被选为新的领导者。但 Kafka 有“首选副本”的概念来平衡集群节点之间的领导力分布。这是使用 启用的auto.leader.rebalance.enable=true，在这种情况下，控制器将尝试将领导权移交给该首选副本。此首选副本是 ISR 列表中的第一个代理。这有点复杂，但只有 Kafka 管理员需要了解这一点。