PartitionStateMachine,分区状态机负责管理Kafka分区状态的转换,类似ReplicaStateMachine。
很多面试官都爱问Leader选举策略。学完本文,你不但能说出4种Leader选举场景,还能总结出它们的共性。
类似ReplicaSM:
类定义一样!尤其是ZkPartitionSM和ZKReplicaSM,所接收字段列表都一致。所以功能其实也差不多。
同理,ZkPartitionSM实例的创建和启动时机也和ZkReplicaSM完全相同:每个Broker进程启动时,会在创建KafkaController对象的过程中,生成ZkPartitionSM实例,而只有Controller组件所在Broker,才会启动分区状态机。
每个Broker启动时,都会创建对应分区状态机和副本状态机实例,但只有Controller所在的Broker才会启动它们。若Controller变更到其他Broker:
PartitionState定义了分区的状态空间及流转规则,以OnlinePartition态为例:
OnlinePartition和OfflinePartition都有一根箭头指向自己,表明OnlinePartition切换到OnlinePartition的操作是允许的。当分区Leader选举发生的时候,就可能出现。
分区Leader选举,PartitionStateMachine的特有功能。每个分区都得选举出Leader,才能正常提供服务。因此,对于分区,Leader副本很重要。所以必须熟悉Leader选举的流程实现。
Kafka定义了哪些推选策略,何时执行Leader选举?
分区Leader选举:为Kafka主题的某个分区推选Leader副本,当前分区Leader选举有如下场景:
针对以上场景,分区状态机的PartitionLeaderElectionAlgorithms定义如下方法分别负责为每种场景选举Leader副本:
其中属offlinePartitionLeaderElection最复杂:
该方法接收如下参数:
1.assignments
分区的副本列表:Assigned Replicas,AR。创建主题后,使用kafka-topics脚本查看主题时,可见Replicas列数据:主题下每个分区的AR。assignments参数类型是Seq[Int],说明AR有序,不一定和ISR顺序相同
2.isr
保存了分区所有与Leader副本保持同步的副本列表。Leader副本自己也在ISR中。作为Seq[Int]类型的变量,isr自身也是有顺序的。
3.liveReplicas
保存该分区下所有存活状态的副本。
根据Controller元数据缓存中的数据。所有在运行中的Broker上的副本,都认为是活的。
4.uncleanLeaderElectionEnabled
默认只要不是由AdminClient发起的Leader选举,该参数为false:Kafka不允许执行Unclean Leader选举。
Unclean Leader选举:在ISR列表为空时,Kafka选择一个非ISR副本作为新Leader。由于存在丢数据风险,Broker端参数unclean.leader.election.enable默认值为false,禁掉Unclean Leader选举。
2.4.0.0版本正式支持在AdminClient端为给定分区选举Leader:若Leader选举由AdminClient触发,默认开启Unclean Leader选举。
顺序搜索AR列表,将第一个满足如下条件的副本作为新Leader返回:
若找不到这样的副本,检查是否开启Unclean Leader选举:
其它选举策略几乎相同,都是从AR或给定副本列表中寻找存活状态的ISR副本。
所以Kafka为分区选举Leader就是:AR列表(或给定副本列表)中首个处于存活状态,且在ISR列表的副本。
PartitionSM的工作原理。
入口方法签名:
包含确认哪些Broker属于下一步的相关Broker,给Broker发送哪些请求
重点还是
重点看OnlinePartition分支:
节点位置:/brokers/topics/<topic>/partitions/<partition>
,每个节点都要包含分区的Leader和ISR。
Leader和ISR的确定规则:
详见initializeLeaderAndIsrForPartitions:
选举Leader的核心代码:
大体分为如下步骤:
根据给定的PartitionLeaderElectionStrategy,调用PartitionLeaderElectionAlgorithms的不同方法执行Leader选举,同时,区分出成功选举Leader和未选出Leader的分区。
4种不同策略定义了4个专属方法执行Leader选举。选择Leader的规则:副本集合中首个存活&&处于ISR中的副本。
联想到handleStateChanges的step2是Controller给相关的Broker发送请求:
本文深入研究了Kafka分区状态机的构造原理和工作机制。
Kafka目前提供4种Leader选举策略:
这4类选举策略在选择Leader上,几乎都是选择当前副本有序集合中的、首个处于ISR集合中的存活副本作为新Leader。
PartitionSM是Kafka Controller端定义的分区状态机,负责定义、维护和管理合法的分区状态转换。每个Broker启动时都会实例化一个分区状态机对象,但只有Controller所在的Broker才会启动它。
Kafka分区有4类状态:
未初始化状态,处于该状态下的分区尚不具备选举Leader的资格
分区正常工作时的状态
Leader选举有4类场景:
每类场景都对应于一种特定的Leader选举策略。handleStateChanges是入口方法,内部调用doHandleStateChanges执行实际Leader选举功能
版权说明 : 本文为转载文章, 版权归原作者所有 版权申明
原文链接 : https://javaedge.blog.csdn.net/article/details/122293325
内容来源于网络,如有侵权,请联系作者删除!