0


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变更,通知订阅组件

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

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


本文转载自: https://blog.csdn.net/szlhj/article/details/134688008
版权归原作者 中间件XL 所有, 如有侵权,请联系我们删除。

“flink源码分析之功能组件(五)-高可用组件”的评论:

还没有评论