1. Why Rebalance?
当某个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创建之时生成,顺序不会发生改变。
2. Rebalance Configure
| 参数 | 默认值 | 描述 |
|---|---|---|
| auto.leader.rebalance.enable | true | 开启再平衡 |
| leader.imbalance.check.interval.seconds | 300 | 再平衡检测的时间间隔,300秒 |
| leader.imbalance.per.broker.percentage | 10 | 每个Broker允许的不平衡比率,即超过当前数值会触发再平衡</ |

当Kafka集群中的Broker宕机后,其Leader副本会转移,导致负载不平衡。Kafka通过Partition Leader Rebalance来恢复负载均衡,确保在Broker故障和恢复后,Leadership能回到首选副本。在Broker故障期间,如果ISR内的副本成为新的Leader,可能会造成性能影响和数据丢失风险。Rebalance过程涉及对集群状态的检查和调整,以优化性能。
最低0.47元/天 解锁文章
218

被折叠的 条评论
为什么被折叠?



