Kakfa的集中leader选举过程
- Kafka是分布式的消息分发系统，通过引入topic的概念来区分消息类型，引入partition的概念来增加消息的吞吐量，引入replica的概念来提高消息的可靠性。在多replica的场景下，消息的读写都是通过leader来完成，其他replica则是通过从leader读取数据来完成消息的同步以保证leader异常时消息的完善性。 然而在多个replica的场景下，谁能成为leader？ leader异常后，又如何选出新的leader呢这是kafka提供可靠服务的关键所在。下面就对此作简要分析。
Leader选举器
Kafka通过leaderSelector完成leader的选举。
可能触发为partition选举leader的场景有: 新创建topic，broker启动，broker停止，controller选举，客户端触发，reblance等等 场景。在不同的场景下选举方法不尽相同。Kafka提供了五种leader选举方式，继承PartitionLeaderSelector，实现selectLeader方法完成leader的选举， 下面对这五种leader选举方式给予说明：
NoOpLeaderSelector
该选举器不会调用到，大概是拿来测试用的。 该选举器直接返回当前的leader Irs，AR。
OfflinePartitionLeaderSelector
触发场景：
* 新创建topic
* PartitionStateMachine启动
* broker启动时
* ReplicaStateMachine检测到broker的znode“被删除”
选举：
1） Isr列表中有存货的replica，直接选出
2） 否则，unclean.leader.election.enable 为false，抛出异常
3） 存活的ar中有replica，选出，否则抛出异常
ControlledShutdownLeaderSelector
触发场景：
* kafka的broker进程政策退出发送消息给controller，controller触发
选举：
* 在isr列表中的选出存活的replica，否则抛出异常
PreferredReplicaPartitionLeaderSelector
触发场景：
* znode节点/admin/preferred_replica_election写入相关数据
* partition-rebalance-thread线程进行触发reblance时
* 新产生controller
选举 ：
1） AR中取出一个作为leader，如果与原有leader一样，抛出异常
2） 新leade的replica的broker存活且replica在isr中，选出，否则抛出异常
ReassignedPartitionLeaderSelector
触发场景:
* znode节点LeaderAndIsr发生变化
* Broker启动时
* zknode节点/admin/reassign_partitions变动
* 新产生controller时
选举：
* 新设置的ar中，存在broker存活的replica且replica在isr中则选出为leader，否则抛出异常
PS： 在所有的leader选举策略中，如果符合条件的replica有多个，如Seq[int]，则使用的是Seq.head，取的是seq的第一个
Kafka的leader选举过程逻辑较为简单，参考kafka.controller.PartitionLeaderSelector.scala即可
