Flink JobManager的HA原理分析

前言

在中心式管理的系统里，主节点如果只是单独服务部署的话，或多或少都会存在单点瓶颈（SPOF）问题。所以我们说现在的分布式系统都要求具有高可用性（High Availability）的实现。同样的，在早期Flink runtime层面，JobManager也没有完全做到HA的实现，这使得运行时的任务存在失败无法及时恢复的风险。不过在最新的代码里，Flink社区已经完善了这块的实现。本文，笔者简单来聊聊Flink JobManager的HA的原理。

JobManager的HA切换通知

笔者在对比了HDFS的HA实现和Flink JobManager的实现后，两者在部分实现上还是存在差异的，并不是说只是主从切换这样简单的过程。以下是几区分点：

HDFS的HA切换，主要保证的是数据请求处理的正常服务。而Flink要让所有的失败任务能够快速恢复。我们可以从更高层面来理解这样的差异：一个是存储系统的HA实现，一个是计算框架的HA实现。

所以FlinkJobMnager在服务发生切换的时候要及时地通知外界事物。这里的外界事物包括：

• JobManager管理的TaskManager
• 在跑的所有Job
• 在请求的JobClient客户端

然后这些Job，JobClient收到新的leader信息后，能够主动重新连接新的JobManager地址，保证任务的正常执行。那么这里面的通知过程是如何的呢，我们继续往下看。

利用Zookeeper的领导选举与消息通知

在这里，Flink内部定义了2类服务来做HA时的领导选举和消息提取（通知）：

• LeaderElectionService
• LeaderRetrievalService

在LeaderElectionService服务的实现中，是采用Apache Curator框架中的LeaderLatch来做领导选举的。然后新的领导被选举出来后，LeaderRetrievalService服务会第一时间得到通知，然后提取出最新leader地址，并通知到监听接口（LeaderRetrievalListener）。这里的通知对象就包含有上面提到的客户端等。
所以在Flink runtime层面，会有很多的LeaderRetrievalListener实现类，如下图所示：

更多实现细节，可以关注Flink-2287.

引用

[1].https://cwiki.apache.org/confluence/display/FLINK/JobManager+High+Availability
[2].https://issues.apache.org/jira/browse/FLINK-2287