一、zookepper Leader Election 主要有两种方法：
(1)抢注Leader节点-----非公平模式
(2)先到先得，后者监听前者-----公平模式
(1)抢注Leader节点-----非公平模式
1.创建Leader父节点，如/chroot,并将其设置为persist持久节点；
2.各客户端通过在/chroot下创建Leader节点，例如/chroot/Leader，来竞争Leader,该节点被设置为ephemeral临时节点；
3.若某客户端创建Leader节点成功，则该客户端成功竞选为Leader;
4.若某客户端创建Leader失败，则竞选Leader失败，在/chroot/Leader节点上注册exist的watch监听，一旦该节点被删除则获得通知；
5.Leader客户端可通过删除Leader节点来放弃Leader；
6.如果Leader宕机，由于Leader节点被设置为ephemeral临时节点，Leader节点会被自行删除，而其他节点由于在Leader节点上注册了watch，故可得到通知，参加下一轮的Leader竞选，从而保证了客户端以Leader角色工作；
(2)先到先得，后者监听前者-----公平模式
1.创建Leader父节点，如/chroot，并将其设置为persist持久节点；
2. 各客户端通过在/chroot下创建Leader节点，如/chroot/Leader，来竞争Leader,该节点被设置为ephemeral_sequential临时顺序节点；
3.客户端通过getChildren方法获得/chroot/下的所有子节点，如果其注册的节点ID在所有的子节点ID中是最小的，则当前客户端竞选Leader成功；
4. 否则，在前面的一个节点上注册watch 监听，一旦前面的节点被删除，则它得到通知，返回step3(但是，不能认为自己成为Leader节点，因为可能前面的节点只是宕机了)
5. Leader节点可以通过自行删除自己创建的节点放弃Leader;
二、Leader Election的Curator
LeaderLatch:
- 竞选为Leader后，不可以自行放弃Leader领导权；
- 只能通过close方法放弃领导权；
- 强力建议增加ConnectionStateListener,当连接suspended或者lost时视为丢弃领导权
- 可通过await方法等待成功获取领导权，并可加入timeout;
- 可通过hasLeadership方法判断是否为Leader;
- 可通过getLeader方法获取当前Leader;
- 可通过getParticipants方法获取当前竞选Leader的参与方；
LeaderSelector:
- 竞选Leader成功后回调takeLeadership方法；
- 可在takeLeadership方法中实现业务逻辑；
- 一旦takeLeadership方法返回，即视为放弃领导权；
- 可通过autoRequeue方法循环获取领导权；
- 可通过hasLeadership方法判断是否为Leader；
- 可通过getLeader方法方法获取当前Leader;
- 可通过getParticipants方法获取当前竞选Leader的参与方；
三、Kafka “各自为政” Leader Eclection
- "各自为政" Leader Election
每个Partition的多个Replica 同时竞争Leader;
- 优点：
实现简单；
- 缺点：
Herd Effect;羊群效应
Zookepper负载过量；
Latency(延时)较大；
四、Kafka基于 Controller 的 Leader Election
- 基于Controller的Leader Election
整个集群汇中选举出一个Broker作为Controller；
Controller为所有的Topic的所有的Partition指定Leader以及Follower；
- 优点：
极大缓解了Herd Effect问题；
减轻了Zookepper负载；
Controller 与Leader以及Follower间通过RPC通信，高效且实时；
- 缺点：
引入Controller增加了复杂度；
需要考虑Controller的Failover；