Kafka：基于法定人数的方法来选举新的领导者？
Kafka : Quorum-based approach to elect the new leader?
如所述here
，有两种常见的保持副本同步的策略，主备份复制和基于仲裁的复制
In primary-backup replication, the leader waits until the write
completes on every replica in the group before acknowledging the
client. If one of the replicas is down, the leader drops it from the
current group and continues to write to the remaining replicas. A
failed replica is allowed to rejoin the group if it comes back and
catches up with the leader. With f replicas, primary-backup
replication can tolerate f-1 failures.
In the quorum-based approach, the leader waits until a write completes
on a majority of the replicas. The size of the replica group doesn’t
change even when some replicas are down. If there are 2f+1 replicas,
quorum-based replication can tolerate f replica failures. If the
leader fails, it needs at least f+1 replicas to elect a new leader.
我对基于法定人数的方法中的语句 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 个）？
Also why do I need the uneven number(say 3) of zookeper to elect a
leader instead even number(say 2) ?
在像 zookeeper 这样的基于仲裁的系统中，领导者选举需要 "ensemble" 中的简单多数 - 即形成 zK 集群的节点。因此，对于一个 3 节点的整体而言，如果剩余两个节点要形成一个新的整体并保持运行，则可以容忍一个节点故障。另一方面，在四节点集成中，您至少需要 3 个节点存活才能形成多数，因此它只能容忍 1 个节点故障。另一方面，五节点集成可以容忍 2 个节点故障。
现在您看到一个 3 节点或 4 节点的集群只能有效地容忍 1 个节点故障，因此拥有奇数个节点以最大化给定集群可能发生故障的节点数是有意义的。
zK 领导者选举依赖于名为 ZAB. Every write goes through the leader and leader generates a transaction id (zxid) and assigns it to each write request. The id represent the order in which the writes are applied on all replicas. A write is considered successful if the leader receives the ack from the majority. An explanation of ZAB.
的类似于 Paxos 的协议
My question is why quorum(majority) of at f+1 replicas is required to
elect a new leader ? Why not any replica out of f+1
in-synch-replica(ISR) is selected ? Why do we need election instead of
just simple any selection?
至于为什么是选举而不是选择——一般来说，在最终一致性的分布式系统中，你需要进行选举，因为没有简单的方法可以知道剩下的节点中哪些节点有最新的数据，因此是有资格成为领导者。
在 Kafka 的情况下——对于具有多个副本和 ISR 的设置，可能有多个节点具有领导者的最新数据。
Kafka 仅使用 zookeeper 作为领导人选举的推动者。如果 Kafka 分区领导者宕机，Kafka 集群控制器会通过 zK 获知这一事实，并且集群控制器会选择一个 ISR 作为新的领导者。所以你可以看到这个 "election" 不同于像 zK 这样基于 quorum 的系统中的新领导人选举
ISR中哪个broker是"selected"有点复杂(see) -
每个副本将消息存储在本地日志中，并在日志中维护几个重要的偏移位置。日志结束偏移量 (LEO) 表示日志的尾部。高水位线 (HW) 是最后提交的消息的偏移量。每个日志都会定期同步到磁盘。 flushed offset之前的数据保证持久化在磁盘上。
因此，当领导者失败时，将通过以下方式选举新的领导者：
- ISR 中每个幸存的副本都会在 Zookeeper 中注册自己。
- 首先注册的副本成为新的领导者。新领导者选择其对数结束偏移量 (LEO) 作为新的高水位线 (HW)。
- 每个副本在 Zookeeper 中注册一个侦听器，以便在任何领导者更改时通知它。每当一个副本被通知一个新的领导者时：
如果副本不是新的领导者（它必须是跟随者），它 t运行 将它的日志发送到它的 HW，然后开始从新的领导者那里赶上。
leader 一直等到 ISR 中所有幸存的副本都赶上或配置的时间已经过去。 leader 将当前的 ISR 写入 Zookeeper 并打开自己进行读写。
现在，与仲裁模型相比，您可能会体会到主备份模型的优势——使用上述策略，具有 2 个 ISR 的 Kafka 3 节点集群可以容忍 2 个节点故障——包括领导者故障——同时，仍然会选出一个新的领导者（尽管那个新的领导者将不得不拒绝新的写入一段时间，直到其中一个失败的节点上线并赶上领导者）。
付出的代价当然是更高的写入延迟 - 在具有 2 个 ISR 的 3 节点 Kafka 集群中，领导者必须等待两个跟随者的确认才能确认写入客户端（生产者） .而在仲裁模型中，如果其中一个追随者确认，则可以确认写入。
因此，根据用例，Kafka 提供了在延迟上交换持久性的可能性。 2 ISR 意味着您有时会有更高的写入延迟，但耐用性更高。如果你 运行 只有一个 ISR，那么万一你失去了领导者和 ISR 节点，你要么没有可用性，要么你可以选择 不干净的领导者选举 在这种情况下你的耐久度较低。
更新 - 领导者选举和首选副本：
组成集群的所有节点都已经在zK中注册了。当其中一个节点发生故障时，zK 通知控制器节点（它本身由 zK 选出）。当发生这种情况时，其中一个实时 ISR 被选为新的领导者。但是 Kafka 有 "preferred replica" 的概念来平衡集群节点之间的领导分布。这是使用 auto.leader.rebalance.enable=true 启用的，在这种情况下，控制器将尝试将领导权移交给该首选副本。此首选副本是 ISR 列表中的第一个代理。这有点复杂，但只有 Kafka 管理员需要知道这一点。
如所述here
，有两种常见的保持副本同步的策略，主备份复制和基于仲裁的复制In primary-backup replication, the leader waits until the write completes on every replica in the group before acknowledging the client. If one of the replicas is down, the leader drops it from the current group and continues to write to the remaining replicas. A failed replica is allowed to rejoin the group if it comes back and catches up with the leader. With f replicas, primary-backup replication can tolerate f-1 failures.
In the quorum-based approach, the leader waits until a write completes on a majority of the replicas. The size of the replica group doesn’t change even when some replicas are down. If there are 2f+1 replicas, quorum-based replication can tolerate f replica failures. If the leader fails, it needs at least f+1 replicas to elect a new leader.
我对基于法定人数的方法中的语句 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 个）？
Also why do I need the uneven number(say 3) of zookeper to elect a leader instead even number(say 2) ?
在像 zookeeper 这样的基于仲裁的系统中，领导者选举需要 "ensemble" 中的简单多数 - 即形成 zK 集群的节点。因此，对于一个 3 节点的整体而言，如果剩余两个节点要形成一个新的整体并保持运行，则可以容忍一个节点故障。另一方面，在四节点集成中，您至少需要 3 个节点存活才能形成多数，因此它只能容忍 1 个节点故障。另一方面，五节点集成可以容忍 2 个节点故障。
现在您看到一个 3 节点或 4 节点的集群只能有效地容忍 1 个节点故障，因此拥有奇数个节点以最大化给定集群可能发生故障的节点数是有意义的。
zK 领导者选举依赖于名为 ZAB. Every write goes through the leader and leader generates a transaction id (zxid) and assigns it to each write request. The id represent the order in which the writes are applied on all replicas. A write is considered successful if the leader receives the ack from the majority. An explanation of ZAB.
的类似于 Paxos 的协议My question is why quorum(majority) of at f+1 replicas is required to elect a new leader ? Why not any replica out of f+1 in-synch-replica(ISR) is selected ? Why do we need election instead of just simple any selection?
至于为什么是选举而不是选择——一般来说，在最终一致性的分布式系统中，你需要进行选举，因为没有简单的方法可以知道剩下的节点中哪些节点有最新的数据，因此是有资格成为领导者。
在 Kafka 的情况下——对于具有多个副本和 ISR 的设置，可能有多个节点具有领导者的最新数据。
Kafka 仅使用 zookeeper 作为领导人选举的推动者。如果 Kafka 分区领导者宕机，Kafka 集群控制器会通过 zK 获知这一事实，并且集群控制器会选择一个 ISR 作为新的领导者。所以你可以看到这个 "election" 不同于像 zK 这样基于 quorum 的系统中的新领导人选举
ISR中哪个broker是"selected"有点复杂(see) -
每个副本将消息存储在本地日志中，并在日志中维护几个重要的偏移位置。日志结束偏移量 (LEO) 表示日志的尾部。高水位线 (HW) 是最后提交的消息的偏移量。每个日志都会定期同步到磁盘。 flushed offset之前的数据保证持久化在磁盘上。
因此，当领导者失败时，将通过以下方式选举新的领导者：
- ISR 中每个幸存的副本都会在 Zookeeper 中注册自己。
- 首先注册的副本成为新的领导者。新领导者选择其对数结束偏移量 (LEO) 作为新的高水位线 (HW)。
- 每个副本在 Zookeeper 中注册一个侦听器，以便在任何领导者更改时通知它。每当一个副本被通知一个新的领导者时： 如果副本不是新的领导者（它必须是跟随者），它 t运行 将它的日志发送到它的 HW，然后开始从新的领导者那里赶上。 leader 一直等到 ISR 中所有幸存的副本都赶上或配置的时间已经过去。 leader 将当前的 ISR 写入 Zookeeper 并打开自己进行读写。
现在，与仲裁模型相比，您可能会体会到主备份模型的优势——使用上述策略，具有 2 个 ISR 的 Kafka 3 节点集群可以容忍 2 个节点故障——包括领导者故障——同时，仍然会选出一个新的领导者（尽管那个新的领导者将不得不拒绝新的写入一段时间，直到其中一个失败的节点上线并赶上领导者）。
付出的代价当然是更高的写入延迟 - 在具有 2 个 ISR 的 3 节点 Kafka 集群中，领导者必须等待两个跟随者的确认才能确认写入客户端（生产者） .而在仲裁模型中，如果其中一个追随者确认，则可以确认写入。
因此，根据用例，Kafka 提供了在延迟上交换持久性的可能性。 2 ISR 意味着您有时会有更高的写入延迟，但耐用性更高。如果你 运行 只有一个 ISR，那么万一你失去了领导者和 ISR 节点，你要么没有可用性，要么你可以选择 不干净的领导者选举 在这种情况下你的耐久度较低。
更新 - 领导者选举和首选副本：
组成集群的所有节点都已经在zK中注册了。当其中一个节点发生故障时，zK 通知控制器节点（它本身由 zK 选出）。当发生这种情况时，其中一个实时 ISR 被选为新的领导者。但是 Kafka 有 "preferred replica" 的概念来平衡集群节点之间的领导分布。这是使用 auto.leader.rebalance.enable=true 启用的，在这种情况下，控制器将尝试将领导权移交给该首选副本。此首选副本是 ISR 列表中的第一个代理。这有点复杂，但只有 Kafka 管理员需要知道这一点。