抽象
LeaderElectionService
这个接口用于从一组竞选者中选出一个leader，其start方法需要传递一个LeaderContender竞选者作为参数，如果有多个竞选者，则每一个竞选者都需要拥有自己的竞选服务类。
LeaderContender
需要竞选leader的候选者们需要实现本接口，即flink中所有需要进行leader选举的组件均会实现本接口。
LeaderRetrievalService
这个接口用于当leader改变的时候收到通知，并回调注册的LeaderRetrievalListener。某些组件对其他组件的leader变更敏感(比如ResourceManager的leader变更则TaskExecutor就需要重新连接到该新的RM上)，这些组件就可以创建LeaderRetrievalService服务，实现其敏感组件leader变更后的业务逻辑。
LeaderRetrievalListener
当leader改时获取到新的leader地址和id，进而实现自定义的业务功能。比如：TaskExecutor的resourceManagerLeaderRetriever就启动了一个ResourceManagerLeaderListener当新的ResourceManager被选举为leader时进行重新连接到新的leader。
实现
采用curator库中的LeaderLatch实现leader选举。主要涉及LeaderLatch和LeaderLatchListener这两个类.LeaderLatchListener接口的两个回调方法：
isLeader: LeaderLatch的失去leader时会被调用notLeader: LeaderLatch的获得leader时会被调用
但是这两个方法都是在LeaderLatch状态转变中被调用，都有可能在这两个方法调用前，leader又改变了回去了，这种情况下唯一可以保证的就是，你可以预期另一个对应的方法也会很快被调用。所以实现中LeaderLatchListener的方法被回调时必须再次调用LeaderLatch.hasLeadership()进行确认。
想了解更多的同学可以参考curator相关文档LeaderLatch
ZooKeeperLeaderElectionService
ZooKeeperLeaderElectionService实现了LeaderLatchListener接口当其启动的LeaderContender被选举为leader时isLeader方法会被回调，然后调用LeaderContender的grantLeadership,实现类可以在该方法中实现自己的业务逻辑（比如job的recovery）完成后再调用LeaderElectionService的confirmLeaderSessionID把新的leader的地址和uuid写入到相应的zk node节点,然后注册监听了该zk node节点的相关LeaderRetrievalService就会收到leader变化的通知从而进行相应的业务处理。
下图为用zookeeper实现leader选举的时序图。
相关组件
- Dispatcher 负责任务的提交，任务持久化，创建JobManagerRunner执行任务以及当master失败时进行任务恢复
- ResourceManager 负责资源的分配和回收
- WebMonitorEndpoint 负责服务前端RESTful调用
- JobManagerRunner 负责job级别的leader选举
