kafka中leader和follower、AR、ISR、OSR、Controller的选举、为什么不能通过ZK的方式来选举partition的leader？

kafka中leader和follower、AR、ISR、OSR、Controller的选举、为什么不能通过ZK的方式来选举partition的leader？ leader和follower

在Kafka中，每个topic都可以配置多个分区以及多个副本。每个分区都有一个leader以及0个或者多个follower，在创建topic时，Kafka会将每个分区的leader均匀地分配在每个broker上。我们正常使用kafka是感觉不到leader、follower的存在的。但其实，所有的读写 *** 作都是由leader处理，而所有的follower都复制leader的日志数据文件，如果leader出现故障时，follower就会被选举为leader**。**所以，可以这样说：

l Kafka中的leader负责处理读写 *** 作，而follower只负责副本数据的同步

l 如果leader出现故障，其他follower会被重新选举为leader

l follower像一个consumer一样，拉取leader对应分区的数据，并保存到日志数据文件中

AR、ISR、OSR

在实际环境中，leader有可能会出现一些故障，所以Kafka一定会选举出新的leader。在讲解leader选举之前，我们先要明确几个概念。Kafka中，把follower可以按照不同状态分为三类——AR、ISR、OSR。

1. 分区的所有副本称为 「AR」（Assigned Replicas——已分配的副本）
2. 所有与leader副本保持一定程度同步的副本（包括 leader 副本在内）组成 「ISR」（In-Sync Replicas——在同步中的副本）
3. 由于follower副本同步滞后过多的副本（不包括 leader 副本）组成 「OSR」（Out-of-Sync Replias）
4. AR = ISR + OSR
5. 正常情况下，所有的follower副本都应该与leader副本保持同步，即AR = ISR，OSR集合为空

Controller

Kafka启动时，会在所有的broker中选择一个controller

leader和follower是针对partition，而controller是针对broker的

创建topic、或者添加分区、修改副本数量之类的管理任务都是由controller完成的

Kafka分区leader的选举，也是由controller决定的

Controller的选举

1. 在Kafka集群启动的时候，每个broker都会尝试去ZooKeeper上注册成为Controller（ZK临时节点）
2. 但只有一个竞争成功，其他的broker会注册该节点的监视器
3. 一旦临时节点状态发生变化，就可以进行相应的处理
4. Controller也是高可用的，一旦某个broker崩溃，其他的broker会重新注册为Controller

Controller选举partition leader

1. 所有Partition的leader选举都由controller决定
2. controller会将leader的改变直接通过RPC的方式通知需为此作出响应的Broker
3. controller读取到当前分区的ISR，只要有一个Replica还幸存，就选择其中一个作为leader否则，则任意选这个一个Replica作为leader
4. 如果该partition的所有Replica都已经宕机，则新的leader为-1

为什么不能通过ZK的方式来选举partition的leader？

Kafka集群如果业务很多的情况下，会有很多的partition

假设某个broker宕机，就会出现很多的partiton都需要重新选举leader

如果使用zookeeper选举leader，会给zookeeper带来巨大的压力。所以，kafka中leader的选举不能使用ZK来实现