|NO.Z.00051|——————————|BigDataEnd|——|Hadoop&kafka.V36|——|kafka.v36|Leader选举|

一、Leader选举

### --- 下图中

~~~     分区P1的Leader是0，ISR是0和1
~~~     分区P2的Leader是2，ISR是1和2
~~~     分区P3的Leader是1，ISR是0，1，2。
~~~     # 生产者和消费者的请求都由Leader副本来处理。
~~~     Follower副本只负责消费Leader副本的数据和Leader保持同步。

### --- 对于P1，如果0宕机会发生什么？

~~~     Leader副本和Follower副本之间的关系并不是固定不变的，
~~~     在Leader所在的broker发生故障的时候，
~~~     就需要进行分区的Leader副本和Follower副本之间的切换，需要选举Leader副本。

### --- 如何选举？

~~~     如果某个分区所在的服务器除了问题，
~~~     不可用，kafka会从该分区的其他的副本中选择一个作为新的Leader。
~~~     之后所有的读写就会转移到这个新的Leader上。现在的问题是应当选择哪个作为新的Leader。
~~~     只有那些跟Leader保持同步的Follower才应该被选作新的Leader。
~~~     Kafka会在Zookeeper上针对每个Topic维护一个称为ISR（in-sync replica，已同步的副本）的集合，
~~~     该集合中是一些分区的副本。
~~~     只有当这些副本都跟Leader中的副本同步了之后，kafka才会认为消息已提交，
~~~     并反馈给消息的生产者。
~~~     如果这个集合有增减，kafka会更新zookeeper上的记录。
~~~     如果某个分区的Leader不可用，Kafka就会从ISR集合中选择一个副本作为新的Leader。
~~~     显然通过ISR，kafka需要的冗余度较低，可以容忍的失败数比较高。
~~~     假设某个topic有N+1个副本，kafka可以容忍N个服务器不可用。

### --- 为什么不用少数服从多数的方法

~~~     少数服从多数是一种比较常见的一致性算发和Leader选举法。
~~~     它的含义是只有超过半数的副本同步了，系统才会认为数据已同步；
~~~     选择Leader时也是从超过半数的同步的副本中选择。
~~~     这种算法需要较高的冗余度，跟Kafka比起来，浪费资源。
~~~     譬如只允许一台机器失败，需要有三个副本；而如果只容忍两台机器失败，则需要五个副本。
~~~     而kafka的ISR集合方法，分别只需要两个和三个副本。

### --- 如果所有的ISR副本都失败了怎么办？

~~~     此时有两种方法可选，
~~~     等待ISR集合中的副本复活，
~~~     选择任何一个立即可用的副本，而这个副本不一定是在ISR集合中。
~~~     需要设置unclean.leader.election.enable=true
~~~     这两种方法各有利弊，实际生产中按需选择。
~~~     如果要等待ISR副本复活，虽然可以保证一致性，但可能需要很长时间。
~~~     而如果选择立即可用的副本，则很可能该副本并不一致。

### --- 总结：

~~~     Kafka中Leader分区选举，通过维护一个动态变化的ISR集合来实现，
~~~     一旦Leader分区丢掉，则从ISR中随机挑选一个副本做新的Leader分区。
~~~     # 如果ISR中的副本都丢失了，则：
~~~     可以等待ISR中的副本任何一个恢复，接着对外提供服务，需要时间等待。
~~~     从OSR中选出一个副本做Leader副本，此时会造成数据丢失

Walter Savage Landor:strove with none,for none was worth my strife.Nature I loved and, next to Nature, Art:I warm'd both hands before the fire of life.It sinks, and I am ready to depart

——W.S.Landor