Flink JobManager的HA原理分析

文章目录

• 前言
• JobManager的HA切换通知
• 利用Zookeeper的领导选举与消息通知
• 引用

前言

---

在中心式管理的系统里，主节点若是只是单独服务部署的话，或多或少都会存在单点瓶颈（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