当某个Broker宕机时,分布在该Broker节点的Leader副本的Leadership就会转移到其他副本。当该Broker重新启动时,它将只是其所有分区的follower,导致该节点不会用于同客户端读写。
为了避免这种不平衡,Kafka提出了preferred replicas
的概念。如果分区的副本列表为[1,5,9],则副本1会优先选作Leader,因为它在副本列表中较早。默认情况下,Kafka集群将尝试将Leadership恢复到首选副本,实现Broker的负载均衡。
【补充】:正常情况下,Leader选举controller会首先判断存在ISR(in-sync-replica) 中的副本,其次按照preferred replicas
的顺序,谁优先则谁选为Leader。preferred replicas
在每个Topic创建之时生成,顺序不会发生改变。
参数 | 默认值 | 描述 |
---|---|---|
auto.leader.rebalance.enable | true | 开启再平衡 |
leader.imbalance.check.interval.seconds | 300 | 再平衡检测的时间间隔,300秒 |
leader.imbalance.per.broker.percentage | 10 | 每个Broker允许的不平衡比率,即超过当前数值会触发再平衡 |
leader.imbalance.per.broker.percentage
创建Topic Answer, 查看主题情况如下:
Topic: Answer Partition: 0 Leader: 1 Replicas: 1,3,0,2 Isr: 1,3,0,2
Topic: Answer Partition: 1 Leader: 0 Replicas: 0,1,2,3 Isr: 0,1,2,3
Topic: Answer Partition: 2 Leader: 2 Replicas: 2,0,3,1 Isr: 2,0,3,1
Topic: Answer Partition: 3 Leader: 3 Replicas: 3,2,1,0 Isr: 3,2,1,0
如果Broker1挂了,导致Broker3承担了两个Leader副本,其中imbalance的副本数=1,所有的副本数=4,1/4>10%
Topic: Answer Partition: 0 Leader: 3 Replicas: 1,3,0,2 Isr: 3,0,2
Topic: Answer Partition: 1 Leader: 0 Replicas: 0,1,2,3 Isr: 0,2,3
Topic: Answer Partition: 2 Leader: 2 Replicas: 2,0,3,1 Isr: 2,0,3
Topic: Answer Partition: 3 Leader: 3 Replicas: 3,2,1,0 Isr: 3,2,0
当Broker3重启成功之后,rebalance check并且rebalance后,
Topic: Answer Partition: 0 Leader: 1 Replicas: 1,3,0,2 Isr: 3,0,2,1
Topic: Answer Partition: 1 Leader: 0 Replicas: 0,1,2,3 Isr: 0,2,3,1
Topic: Answer Partition: 2 Leader: 2 Replicas: 2,0,3,1 Isr: 2,0,3,1
Topic: Answer Partition: 3 Leader: 3 Replicas: 3,2,1,0 Isr: 3,2,0,1
必然会导致Kafka的性能,每次Leader的更新会导致Leader和Follower的offset(Water Mark)更新,还可能会导致数据的丢失。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)