当某个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允许的不平衡比率，即超过当前数值会触发再平衡 |
创建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）更新，还可能会导致数据的丢失。
