Kafka 集群中有一个 broker 的 Controller 会被选举为 Controller Leader，负责管理集群broker 的上下线，所有 topic 的分区副本分配和 Leader 选举等工作。

Controller 的信息同步工作是依赖于 Zookeeper 的。

（1）创建一个新的 topic，4 个分区，4 个副本

 bin/kafka-topics.sh --bootstrap-server hadoop11:9092 --create --topic bigdata2401 --partitions 4 --replication-factor 4

（2）查看 Leader 分布情况

bin/kafka-topics.sh --bootstrap-server bigdata01:9092 --describe --topic bigdata2305

Topic: bigdata2301

Topic: bigdata2301 Partition: 0 Leader: 0 Replicas: 0,2,3,1 Isr: 0,2,3,1

Topic: bigdata2301 Partition: 1 Leader: 2 Replicas: 2,3,1,0 Isr: 2,3,1,0

Topic: bigdata2301 Partition: 2 Leader: 3 Replicas: 3,1,0,2 Isr: 3,1,0,2

Topic: bigdata2301 Partition: 3 Leader: 1 Replicas: 1,0,2,3 Isr: 1,0,2,3

 

（3）停止掉 hadoop13 的 kafka 进程，并查看 Leader 分区情况

bin/kafka-server-stop.shbin/kafka-topics.sh --bootstrap-server bigdata01:9092 --describe 
--topic bigdata2305 

 

Topic: bigdata2301 Partition: 0 Leader: 0 Replicas: 0,2,3,1 Isr: 0,2,1

Topic: bigdata2301 Partition: 1 Leader: 2 Replicas: 2,3,1,0 Isr: 2,1,0

Topic: bigdata2301 Partition: 2 Leader: 1 Replicas: 3,1,0,2 Isr: 1,0,2

Topic: bigdata2301 Partition: 3 Leader: 1 Replicas: 1,0,2,3 Isr: 1,0,2

（4）停止掉 hadoop14 的 kafka 进程，并查看 Leader 分区情况 

通过以上演示，可以发现，选举是按照AR(跟Replicas一样)进行的，而不是ISR 

 

• ISR 集合是 Kafka 维护副本同步状态的关键。每个 Topic 的每个分区都有一个 ISR 集合，这个集合中的副本与 Leader 副本保持同步。ISR 集合记录在 Zookeeper 上，Kafka 通过 Zookeeper 来管理和协调这些状态信息。
• Kafka 只有在确保所有 ISR 中的副本都已经同步了 Leader 中的消息后，才会认为这些消息是已提交的。这一机制确保了消息的高可靠性，避免了消息丢失或数据不一致的问题。
• 当 Leader 发生故障时，Kafka 会从 ISR 集合中选举新的 Leader。只有那些与原 Leader 保持同步的 Follower 副本才有资格被选作新的 Leader。这一规则确保了新的 Leader 能够快速接管并继续提供一致性的服务。
• 为了确保高可用性，Kafka 采用多副本机制。假设一个 Topic 有 N+1 个副本，那么 Kafka 可以容忍最多 N 个服务器不可用。这意味着，即使有 N 个副本出现故障，Kafka 仍然能够通过剩余的副本继续提供服务。这一特性大大提高了系统的容错能力。
• 如果 ISR 中的副本都丢失了，则：

• • 当 ISR 中的所有副本都丢失时，Kafka 可以选择等待这些副本中的任何一个恢复。一旦有副本恢复并重新加入 ISR 集合，Kafka 就可以继续对外提供服务。虽然这一过程中需要等待一定的时间，但能够确保数据的一致性和完整性。
  • 如果等待时间过长，Kafka 也可以从 OSR（out-of-sync replica）集合中选出一个副本作为新的 Leader 副本。然而，这一过程中可能会导致数据丢失，因为 OSR 中的副本没有与 Leader 保持同步。这是一个权衡可用性和一致性的问题，需要根据具体场景进行选择。