Flink JobManager的HA原理分析

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/Androidlushangderen/article/details/86189185

前言


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

没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试