Kafka副本

Kafka Controller

在Kafka集群中有一个broker会被选举为控制器（Kafka Controller），它负责管理整个集群中所有分区和副本的状态。

当某个分区的leader副本出现故障时，由控制器负责为该分区选举新的leader副本。当检测到某个分区的ISR集合发生变化时，由控制器负责通知所有broker更新其元数据信息。当使用kafka-topics.sh脚本为某个topic增加分区数量时，同样还是由控制器负责分区的重新分配。

Kafka中的控制器选举的工作依赖于Zookeeper，成功竞选为控制器的broker会在Zookeeper中创建/controller这个临时节点。

在任意时刻，集群中有且仅有一个控制器。每个broker启动的时候会去尝试去读取/controller节点的brokerid的值，如果读取到brokerid的值不为-1，则表示已经有其它broker节点成功竞选为控制器，所以当前broker就会放弃竞选；如果Zookeeper中不存在/controller这个节点，或者这个节点中的数据异常，那么就会尝试去创建/controller这个节点，当前broker去创建节点的时候，也有可能其他broker同时去尝试创建这个节点，只有创建成功的那个broker才会成为控制器，而创建失败的broker则表示竞选失败。

副本（Replication）

同一个partition可能会有多个replication（对应 server.properties 配置中的 default.replication.factor=N）。没有replication的情况下，一旦broker 宕机，其上所有 patition 的数据都不可被消费，同时producer也不能再将数据存于其上的partition。

引入replication之后，同一个partition可能会有多个replication，需要在这些replication之间选出一个leader

producer和consumer只与这个leader交互，其它replication作为follower从leader 中复制数据。

AR ISR OSR

AR：分区中的所有副本统称为AR ( Assigned Replicas ) 。

ISR：所有与leader 副本保持一定程度同步的副本（包括leader 副本在内）组成ISR （In-Sync Replicas ) , ISR 集合是AR 集合中的一个子集。

消息会先发送到leader 副本，然后follower 副本才能从leader 副本中拉取（pull）消息进行同步，同步期间内follower 副本相对于leader 副本而言会有一定程度的滞后。所谓“ 一定程度的同步”是指可忍受的滞后范围，这个范围可以通过参数进行配置。

OSR: 与leader 副本同步滞后过多的副本（不包括leader 副本）组成OSR ( Out-of-Sync Replicas ），由此可见， AR=ISR+OSR 。

在正常情况下， 所有的follower 副本都应该与leader 副本保持一定程度的同步，即AR=ISR，OSR 集合为空。

leader 副本负责维护和跟踪ISR 集合中所有follower 副本的滞后状态， 当follower 副本落后太多或失效时， leader 副本会把它从ISR 集合中剔除。

如果OSR 集合中有follower 副本“追上leader 副本，那么leader 副本会把它从OSR 集合转移至ISR 集合。

默认情况下， 当leader 副本发生故障时，只有在ISR集合中的副本才有资格被选举为新的leader， 而在OSR集合中的副本则没有任何机会（不过这个原则也可以通过修改相应的参数配置来改变） 。

HW LEO

HW：ISR 与HW和LEO也有紧密的关系。HW是High Watermark的缩写，俗称高水位，它标识了一个特定的消息偏移量（offset），消费者只能拉取（pull）到这个offset之前的消息。

LEO：是Log End Offset的缩写，它标识当前日志文件中下一条待写入消息的offset, LEO 的大小相当于当前日志分区中最后一条消息的offset 值加1 。

分区ISR集合中的每个副本都会维护自身的LEO，而ISR集合中最小的LEO即为分区的HW，对消费者而言只能消费HW之前的消息。

副本失效判断

当follower副本将leader副本LEO ( LogEndOffset）之前的日志全部同步时，则认为该follower副本己经追赶上leader副本，此时更新该副本的lastCaughtUpTimeMs 标识。

Kafka的副本管理器会启动一个副本过期检测的定时任务，而这个定时任务会定时检查当前时间与副本lastCaughtUpTimeMs差值是否大于参数replica.lag.time.max.ms 指定的值。不要错误地认为follower 副本只要拉取leader副本的数据就会更新lastCaughtUpTimeMs。

在0.9.0.0之前，Kafka提供了replica.lag.max.messages 来控制follower副本最多落后leader副本的消息数量，follower 相对于leader 落后当超过这个数量的时候就判定该follower是失效的，就会从ISR移除。对应的Kafka 也针对这些场景提供了一些控制的参数：replica.lag.max.messages（以数量为标准衡量是否落后），replica.lag.time.max（多久没有向leader请求数据）

0.9.0.0 之后提供了一个更加适合的方式来解决这个问题，采用Kafka 落后消费进度的时间长度来判断是否踢出ISR，这样有效的避免了在突发流量偶然落后于leader 被不合理的踢出ISR的情况，如果长时间落后于leader 这种情况实际故障是需要去踢的也没问题，也就有效的避免了ISR的反复移进移出所带来的代价。

参考：Kafka设计解析（九）为何去掉replica.lag.max.messages参数_dlx29376的博客-CSDN博客

副本失效原因

follower 副本进程卡住，在一段时间内根本没有向leader 副本发起同步请求，比如频繁的Full GC 。

follower 副本进程同步过慢，在一段时间内都无法追赶上leader 副本，比如I/O开销过大

随着follower 副本不断与leader 副本进行消息同步， follower 副本的LEO 也会逐渐后移，并最终追赶上leader 副本，此时该follower 副本就有资格进入ISR 集合。追赶上leader 副本的判定准则是此副本的LEO 是否不小于leader 副本的HW。

优先副本

优先副本：是指在AR 集合列表中的第一个副本。比如上面主题topic-partitions 中分区。的AR 集合列表（ Replicas ）为［1 ,2 , 0］，那么分区0 的优先副本即为1 。理想情况下，优先副本就是该分区的leader副本。

Kafka 要确保所有主题的优先副本在Kafka 集群中均匀分布，这样就保证了所有分区的leader 均衡分布。如果leader 分布过于集中， 就会造成集群负载不均衡。

优先副本的选举是指通过一定的方式促使优先副本选举为leader副本，以此来促进集群的负载均衡， 这一行为也可以称为“分区平衡” 。

分区平衡并不意味着Kafka集群的负载均衡，例如：每个分区的leader 副本的负载各不相同，有些leader 副本的负载很高。