Flink架构分析之HA

抽象

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选举