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

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

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