【Kafka原理】分区的leader和follower

一、leader和follower

在Kafka中，每个topic都可以配置多个分区以及多个副本。每个分区都有一个leader以及0个或者多个follower。在创建topic时，Kafka会将每个分区的leader均匀地分配在每个broker上。使用Kafka时，是感觉不到leader和follower存在的。

• Kafka中的leader负责处理读写操作，而follower只是负责副本数据的同步
• 如果leader出现故障，其他follower会被重新选举为leader
• follower像是一个消费者，不断拉取对应分区的leader数据，并保存到日志数据文件中

二、AR、ISR、OSR

• AR（Assigned Replica 已分配的副本）：表示某个分区的所有副本
• ISR（In-Sync-Replica 在同步中的副本）：表示所有与leader副本保持一定程度同步的副本（包括leader副本在内）
• OSR（Out-of-Sync-Replica 不在同步中的副本）：表示所有与leader副本同步滞后过多的follower副本（不包括leader副本）
• AR = ISR + OSR
• 正常情况下，所有的follower副本都应该与leader副本保持同步，即：AR = ISR，OSR集合为空

四、leader选举

1. Controller的介绍

• Kafka启动时，会在所有的broker（集群节点）中选择一个controller
• 之前的leader和follower是针对分区而言的，而controller是针对broker的
• 创建topic、添加分区、修改副本数量等管理任务都是由controller完成的
• Kafka分区leader的选举，也是有controller决定的

2. Controller的选举

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

3. Controller选举分区leader

• 所有分区的leader选举都是由controller决定的
• controller会将leader的改变直接通过RPC的方式通知需为此做出响应的broker
• controller读取到当前分区的ISR，只有一个replica存活时，就选择这个replica作为leader，否则任意选择一个replica作为leader
• 如果该分区的所有replica都已经宕机，则新的leader为-1

4. 为什么不通过ZK的方式选举分区的leader？

• Kafka集群如果业务很多的情况下，会存在很多的分区
• 假设某个broker宕机，就会出现很多的分区都需要重新选举leader
• 如果使用zookeeper选举leader，会给zk带来巨大的压力。因此，Kafka中leader的选举不能使用zk来实现

五、leader负载均衡

如果某个broker崩溃之后，就可能导致分区的leader分布不均匀，就是说一个broker上存在一个topic下不同分区的leader

1. Prefered Replica

• Kafka中引入了一个叫做【prefered replica】概念，即：优先的replica
• 在ISR列表中，第一个replica就是prefered replica

2. 重新分配分区leader