flink源码分析之功能组件(五)-高可用组件

简介

     本系列是flink源码分析的第二个系列,上一个《flink源码分析之集群与资源》分析集群与资源,本系列分析功能组件,kubeclient,rpc,心跳,高可用,slotpool,rest,metrics,future。

     本文解释高可用组件,包括两项服务,主节点选举主节点变更通知*

    高可用服务常见有两种实现,zookeeper和k8s,本文介绍zookeeper

   *flink高可用组件还有作业状态,作业存储,作业结果存储服务,这些放到作业执行系列分析,本章暂不涉及

设计

上图是高可用包结构,也体现逻辑结构,功能结构

highavailability 定义高可用的接口和抽象类;Services类,即构建工厂,包括zookeeper实现

leaderelection 选主组件

leaderretrieval 主节点变更获取组件

zookeeper  zookeeper实现*,高可用zk实现依赖curator

*这是我理想的包结构,选主组件,主节点变更组件zookeeper实现都在zookeeper目录

znode结构

zookeeper分布式设计,不能绕开的是znode设计,本节解释一下高可用组件znode设计

图是选主和主节点变更通知znode,flink还有作业存储,检查点,与leader节点同级,未在上图展示

/latch 选主节点,master多个组件都需要选主,只有一个选主节点,选主那节解释选主怎样做的

/connection_info 存储master组件主节点的地址

其他节点的含义比较明确,不一一解释

高可用构建服务

highavailability包是高可用组件的初始化和构建工厂,包括构建面向各业务组件的高可用服务

flink代码规范,***Services是构建服务

ClientHighAvailabilityServices 构建rest端主节点获取服务,rest端是flink内置rest服务,本系列有一章专门解释,该服务给RestClusterClient获取rest端主节点地址,构建rpc网关,远程执行集群管理

HighAvailabilityServices 构建master组件,包括分发器,作业管理器,资源管理器,rest端等的选主服务和主节点获取服务,HighAvailabilityServices继承ClientHighAvailabilityServices,意味着master内部也可获取rest端地址,使用rest服务

ZooKeeperMultipleComponentLeaderElectionHaServices zookeeper的多组件选主高可用构建服务实现,关于多组件选主下一节详细解释

选主

上图选主类图,下面分3各部分解释,业务组件;服务与驱动;监听机制

业务组件层

ResourceManagerServiceImpl/DefaultDispatcherRunner/JobMasterServiceLeadershipRunner

3个分别是资源管理器分发器作业管理器的运行管理服务,选主管理是其中一个职责,都实现了LeaderContender,接收当选/退选事件,继而对管理的master组件相应的处理

服务和驱动

Flink高可用组件是服务和驱动分离设计,解耦了服务逻辑与底层的分布式协调驱动,这样分布式引擎可以无缝切换

flink选主有两套的选主组件,单组件和多组件

单组件选主

LeaderElectionService/LeaderElectionDriver

单组件的选主服务,对应的zookeeper驱动实现被标注为”废弃”,flink master有多个组件,每类组件选主需要多个/latch,选主比较耗时,多个选主效率较低;作业节点不定,造成/latch需要增删,节点管理困难,flink使用的是多组件的选主

多组件选主

MultipleComponentLeaderElectionService/MultipleComponentLeaderElectionDriver

b.1)     LeaderElectionService代表单个组件,自身是LeaderElectionEventHandler实现,注册到

MultipleComponentLeaderElectionService

b.2) MultipleComponentLeaderElectionService构建MultipleComponentLeaderElectionDriver ,自身是MultipleComponentLeaderElectionDriver.Listener实现,获取MultipleComponentLeaderElectionDriver的通知

b.3) MultipleComponentLeaderElectionDriver  zookeeper实现依赖curator的LeaderLatch,自身实现LeaderLatchListener,获取zookeeper的leader选举通知

c)  桥接

桥接涉及两个类,MultipleComponentLeaderElectionDriverAdapter和LeaderElectionEventHandler

MultipleComponentLeaderElectionDriverAdapter  该类虽然命名为adapter,但我理解不是适配器,实则是桥接,装扮成LeaderElectionDriver实现,高可用的功能转给MultipleComponentLeaderElectionService,后者通过LeaderElectionEventHandler通知LeaderElectionService

​​​​​​​监听机制

上一节服务与驱动介绍了监听机制,本节详细介绍各个监听器

LeaderLatchListener curator LeaderLatch的监听器,接收当选/未当选消息,通知flink高可用多组件选主的监听器

MultipleComponentLeaderElectionDriver.Listener  flink高可用组件监听器,生成会话Id,通知注册的多组件;会话是新主节点的生命周期,类似新王登记的年号,用于识别旧主或更新主,分布式环境是关键,避免不一致的发生

LeaderElectionEventHandler  连接多组件选主和单组件选主的监听器,接收当前的sessionId,此接口同时接收连接信息变更,因此也是获取主节点变更的监听器

LeaderContender  业务组件通知接口,通知业务组件的管理服务当选/退选事件,管理服务对管理的master组件相应处理

总结

  1. flink 高可用服务分单个组件和多个组件,单个组件高可用驱动已标注”废弃”,master组件直接依赖是LeaderElectionService,但其选主功能桥接到多组件选主服务MultipleComponentLeaderElectionService,LeaderElectionService代表master组件注册到后者,后者当选后,通知所有注册的master组件
  2. flink高可用监听机制分3层,底层的curator,原生zookeeper watcher事件;第二层高可用组件层,多组件选主服务到单组件选主服务;第三层,业务组件获取事件做相应的业务处理 

主节点变更通知

主节点变更通知是选主的下游,选主结束,新主在znode connection_info 写入自身地址信息,主节点变更通知服务监听连接信息节点,收到节点data变更,通知订阅组件

上图是主节点变更服务的类图,

比较简单,这里列出参与的类,原理和使用分析留给读者自行分析

  • 21
    点赞
  • 17
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

中间件XL

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值