概述

Flink内部有一些服务是JobMaster和TaskExecutor共用的。如HighAvailabilityServices, RpcService, ActorSystem(MetricQueryService), HeartbeatServices, MetricRegistryImpl, BlobCacheService.

HighAvailabilityServices 的作用

• 提供 Leader 获取服务(ResourceManager, Dispatcher, JobManager, WebMonitor)
• 提供 Leader 选举服务(同上)
• 提供Checkpoint恢复工厂类(获取已完成的Checkpoint的元信息，以及Checkpoint计数器)
• 提供SubmittedJobGraphStore，用来保存和恢复JobGraph
• 提供大文件(Blob)的高可用存储
• 提供(RunningJobsRegistry)，任务状态信息的保存与获取

HighAvailabilityServices 的使用者

• ClusterEntrypoint
• TaskManagerRunner
• ClusterClient

HighAvailabilityServices 的创建

• HighAvailabilityServices 的创建是通过HighAvailabilityServicesUtils这个工具类，这个工具类提供了两个重要的静态方法来生成HighAvailabilityServices 。

  • 第一个是 createAvailableOrEmbeddedServices(Configuration config, Executor executor)，主要用于创建MiniCluster，服务于测试和本地运行。

  • 第二个是 createHighAvailabilityServices(Configuration configuration, Executor executor, AddressResolution addressResolution)，相比于第一个方法，它的参数还需要AddressResolution 。

    /**
     * Enum specifying whether address resolution should be tried or not when creating the
     * {@link HighAvailabilityServices}.
     */
    public enum AddressResolution {
        TRY_ADDRESS_RESOLUTION,
        NO_ADDRESS_RESOLUTION
    }
    

    • TRY_ADDRESS_RESOLUTION和NO_ADDRESS_RESOLUTION，分别代表是否需要解析地址。用于在非HA环境下的直接解析地址，如果hostname不存在则快速失败。在ClusterEntrypoint中由于是本地，不需要解析，而在TaskManagerRunner与ClusterClient中使用了TRY_ADDRESS_RESOLUTION，因为一个是负责执行具体任务，另一个则是用户的客户端。
    • 这个方法首先获取高可用模式(HighAvailabilityMode)，分别是无高可用，基于Zookeeper的高可用，以及自己定制的高可用模式。

      public enum HighAvailabilityMode {
          NONE(false),
          ZOOKEEPER(true),
          FACTORY_CLASS(true);
      }
      

    • 其中None模式JobManager地址是固定的，所以直接从Configuration中获取地址并生成一个StandaloneHaServices。
    • Zookeeper模式会先创建BlobStorService，就是一个高可用的大文件持久化服务，这个服务将文件保存在high-availability.storageDir配置的位置，并在Zookeeper上保存元信息。

      case ZOOKEEPER:
          BlobStoreService blobStoreService = BlobUtils.createBlobStoreFromConfig(configuration);
          return new ZooKeeperHaServices(
                    ZooKeeperUtils.startCuratorFramework(configuration),
                    executor,
                    configuration,
                    blobStoreService);
      

    • Custom模式需要用户自己实现HighAvailabilityServicesFactory

LeaderElectionService & LeaderRetrievalService

• LeaderElectionService和LeaderRetrievalService分别提供了某个组件参加Leader选举和获取其他组件Leader的功能。(组件包括ResourceManager, Dispatcher, JobManager, WebMonitor)。

• LeaderElectionService

  • 接口如下所示, start方法就是将当前的组件加入Leader选举，上述四个组件都是现了LeaderContender接口。

  • 当某个组件被选举为leader时，会回调该组件实现的grantLeadership方法(第一次被选举为leader)，当某个组件不再是leader时，会回调该组件实现的revokeLeadership方法。

    public interface LeaderElectionService {
      void start(LeaderContender contender) throws Exception;
      void stop() throws Exception;
      void confirmLeaderSessionID(UUID leaderSessionID);
      boolean hasLeadership(@Nonnull UUID leaderSessionId);
    }
    public interface LeaderContender {
      void grantLeadership(UUID leaderSessionID);
      void revokeLeadership();
      String getAddress();
      void handleError(Exception exception);
    }
    

• LeaderRetrievalService

  • LeaderRetrievalService 非常简洁，提供了start和stop方法，并且start方法只能被调用一次，在ZK模式中因为它只会监听一条ZK上的路径(即一个组件的变化)。
  • 在启动LeaderRetrievalService的方法中需要接收参数LeaderRetrievalListener，将实现这个接口的类的实例作为参数传入这个方法，在相应组件leader发生变化时会回调notifyLeaderAddress方法，在LeaderRetrievalService抛出异常的时候会调用handleError方法。

    public interface LeaderRetrievalService {
      void start(LeaderRetrievalListener listener) throws Exception;
      void stop() throws Exception;
    }
    public interface LeaderRetrievalListener {
      void notifyLeaderAddress(@Nullable String leaderAddress, @Nullable UUID leaderSessionID);
      void handleError(Exception exception);
    }
    

HighAvailabilityServices 的典型实现 ZooKeeperHaServices

• ZooKeeperHaServices的Constructor需要接受四个参数，分别为CuratorFramework, Executor, Configuration, BlobStoreService

• 在HighAvailabilityServices创建中，已经介绍了BlobStoreService的作用，此处要再介绍一下是创建CuratorFramework的方法ZooKeeperUtils.startCuratorFramework(configuration)

• CuratorFramework创建

  • 下图是如何通过Builder创建CuratorFramework，详情可以阅读Zookeeper客户端Curator使用详解
    一文，这里会介绍这些参数是如何配置的

      CuratorFramework cf = CuratorFrameworkFactory.builder()
              .connectString(zkQuorum)
              .sessionTimeoutMs(sessionTimeout)
              .connectionTimeoutMs(connectionTimeout)
              .retryPolicy(new ExponentialBackoffRetry(retryWait, maxRetryAttempts))
              // Curator prepends a '/' manually and throws an Exception if the
              // namespace starts with a '/'.
              .namespace(rootWithNamespace.startsWith("/") ? rootWithNamespace.substring(1) : rootWithNamespace)
              .aclProvider(aclProvider)
              .build();
    

    • zkQuorum对应配置中的high-availability.zookeeper.quorum，即Zookeeper的地址
    • sessionTimeout对应配置中的high-availability.zookeeper.client.session-timeout，单位为毫秒，默认60000即一分钟，ZK会话的超时时间
    • connectionTimeout对应配置中的high-availability.zookeeper.client.connection-timeout，单位为毫秒，默认15000即15秒，ZK的连接超时时间
    • 重试策略为ExponentialBackoffRetry，从概率上来讲随着重试次数越来越多，重试间隔呈指数级增长
      • retryWait对应配置中的high-availability.zookeeper.client.retry-wait，即基础的间隔时间
      • maxRetryAttempts对应配置中的high-availability.zookeeper.client.max-retry-attempts，即最大重试次数
    • rootWithNamespace由root和namespace(clusterId)拼成，root对应配置中的high-availability.zookeeper.path.root，默认为/flink, namespace对应配置中的high-availability.cluster-id, 在Yarn模式下也就是applicationId
    • aclProvider默认使用DefaultACLProvider，相关的配置有zookeeper.sasl.disable(默人false)和high-availability.zookeeper.client.acl(默认open)

• Executor是用来执行ZooKeeperCompletedCheckpointStore移除CompletedCheckpoints的任务的。

• 在介绍LeaderElectionService和LeaderRetrievalService的ZK实现之前，先看一个flink cluster在zookeeper中的目录结构，如下图

  
  ZK目录结构

• ZookeeperLeaderElectionService

  • 接口

    • ZooKeeperLeaderElectionService除了实现LeaderElectionService以外，还实现了LeaderLatchListener，NodeCacheListener，UnhandledErrorListener三个属于curator的接口。
    • LeaderLatchListener需要实现类实现两个回调方法，如下

      public interface LeaderLatchListener {
          void isLeader();
          void notLeader();
      }
      

      • 当被监听的对象(此处即为该ZookeeperLeaderElectionService实例)被选为leader时，isLeader实现的逻辑会被调用
      • 当失去leader位置时，notLeader会被调用
    • NodeCacheListener只有一个方法，如下

      public interface NodeCacheListener {
          void nodeChanged() throws Exception;
      }
      

      • 当监测的节点状态发生变化时，nodeChanged会被调用，在此处是保存了LeaderContender地址和LeaderSessionID的节点
    • UnhandledErrorListener接口需要实现一个方法，如下

      public interface UnhandledErrorListener {
          void unhandledError(String var1, Throwable var2);
      }
      

      • 当后台操作发生异常时触发unhandledError方法，在flink各个组件的实现中也把这当做fatal error来处理

  • 创建

    • ZookeeperLeaderElectionService的创建通过工具类ZookeeperUtils的createLeaderElectionService方法，如下。

    public static ZooKeeperLeaderElectionService createLeaderElectionService(
            final CuratorFramework client,
            final Configuration configuration,
            final String pathSuffix) {
        final String latchPath = configuration.getString(
            HighAvailabilityOptions.HA_ZOOKEEPER_LATCH_PATH) + pathSuffix;
        final String leaderPath = configuration.getString(
            HighAvailabilityOptions.HA_ZOOKEEPER_LEADER_PATH) + pathSuffix;
    
        return new ZooKeeperLeaderElectionService(client, latchPath, leaderPath);
    }
    

    • 该方法接受的参数其中client(CuratorFramework)的创建上一个小节介绍了。还有pathSuffix则对应的是各个组件，分别如下, 与leader和leaderlatch目录下一一对应

      private static final String RESOURCE_MANAGER_LEADER_PATH = "/resource_manager_lock";
      private static final String DISPATCHER_LEADER_PATH = "/dispatcher_lock";
      private static final String JOB_MANAGER_LEADER_PATH = "/job_manager_lock";
      private static final String REST_SERVER_LEADER_PATH = "/rest_server_lock";
      

    • 方法体中的HA_ZOOKEEPER_LATCH_PATH对应flink配置中的high-availability.zookeeper.path.latch，默认值为/leaderlatch，HA_ZOOKEEPER_LEADER_PATH对应flink配置中的high-availability.zookeeper.path.leader，默认为/leader。此处latchpath与leaderpath就与上图中flink集群在zk下的目录一一对应了起来。
    • 在ZookeeperLeaderElectionService的构造方法如下

      public ZooKeeperLeaderElectionService(CuratorFramework client, String latchPath, String leaderPath) {
          this.client = Preconditions.checkNotNull(client, "CuratorFramework client");
          this.leaderPath = Preconditions.checkNotNull(leaderPath, "leaderPath");
      
          leaderLatch = new LeaderLatch(client, latchPath);
          cache = new NodeCache(client, leaderPath);
      
          issuedLeaderSessionID = null;
          confirmedLeaderSessionID = null;
          leaderContender = null;
      
          running = false;
      }
      

      • 其中LeaderLatch是Curator的针对某一条zk路径的leader选举实现，NodeCache是Curator监控某一条zk路径的变化的实现，在此处只是分别根据latchpath和leaderpath初始化了对象，还没有启动监听。
      • 有两个重要的类型为UUID的成员变量被初始化为null，分别是issuedLeaderSessionID和confirmedLeaderSessionID。这两个变量在leader选举过程中起到非常重要的作用。

  • 启动

    • 在启动LeaderElectionService时，会将实现LeaderContender(参与选举)的实例传入，基于zk的方法实现如下

    public void start(LeaderContender contender) throws Exception {
        Preconditions.checkNotNull(contender, "Contender must not be null.");
        Preconditions.checkState(leaderContender == null, "Contender was already set.");
        LOG.info("Starting ZooKeeperLeaderElectionService {}.", this);
        synchronized (lock) {
            client.getUnhandledErrorListenable().addListener(this);
            leaderContender = contender;
            leaderLatch.addListener(this);
            leaderLatch.start();
            cache.getListenable().addListener(this);
            cache.start();
            client.getConnectionStateListenable().addListener(listener);
            running = true;
        }
    }
    

    • 在启动方法中，将当前LeaderElection的对象作为Listener加入LeaderLatch，NodeCache和CuratorFramework的UnhandleError中，并启动前两个服务，并将Running置为true。

  • 过程

    • 过程主要包含了被选举为leader，不再是leader和Cache节点改变
      • 被选举为leader，如接口小节所述，isLeader方法会被调用，此时会生成一个UUID作为issuedLeaderSessionID，并作为调用LeaderContender(参与选举的组件)的grantLeadership方法的参数。而LeaderContender则会通过confirmedLeaderSessionID来进行确认，只有与issuedLeaderSessionID相同，confirmedLeaderSessionID才会更新，并将leader信息写入对应的leaderPath的节点中。
      • 不再是leader，如接口小节所述，notLeader方法会被调用，此时会将issuedLeaderSessionID和confirmLeaderSessionID置为null，并调用LeaderContender的revokeLeadership方法通知该组件已经失去leader位置。
      • Cache节点改变时，nodeChanged方法会被调用，首先判断是否为leader，如果是的话则判断confirmedLeaderSessionID是否为空，如果不为空则将其连同LeaderContender的地址写入leaderpath下的zk临时节点。

  • 停止

    • 在停止方法中LeaderContender将退出选举。具体实现是将启动方法中添加的listener移除并关闭LeaderLatch和NodeCache，并将成员变量的引用置null。

• 创建ZookeeperLeaderRetrievalService

  • 接口，ZooKeeperLeaderRetrievalService实现了LeaderRetrievalService，NodeCacheListener和UnhandledErrorListener接口，这三个接口在上文都已经介绍过。
  • 创建
    • 因为LeaderRetrievalService功能相对比较简单，只需要在leader切换时获取相关组件的Leader的地址和leaderSessionID，所以只创建了NodeCache来监测retrievalPath的变化(此处retrievalPath与参与选举的组件的leaderPath)相同，并缓存了lastLeaderAddress和lastLeaderSessionID，防止在leader并没有改变的情况下触发listener的notifyLeaderAddress。
  • 启动
    • 启动方法将Listener加入UnhandledError和NodeCache的监听并启动NodeCache，在CuratorFramework出错或者监测的retrievalPath节点发生变化或能收到回调。
  • 过程
    • 当监测的retrievalPath发生变化时，nodeChanged会被调用，在该方法体中，会从这个NodeCache(zk节点)中获取数据，与lastLeaderAddress和lastLeaderSessionID进行比对，如果发生变化会更新这两个变量并调用Listner的notifyLeaderAddress，通知新的leader地址与leaderSessionID.
  • 停止
    • 在停止方法中中止监听，具体实现是将listener移除，并关闭NodeCache。

• CheckpointRecoveryFactory

  • CheckpointRecoveryJob 一是提供了根据JobID和maxNumberOfCheckpointsToRetain(也就是保存的历史checpkpoint文件的个数)来生成CompletedCheckpointStore的方法，二是提供了根据JobID生成CheckpointIDCounter的方法。在本文中不会多做介绍，后续如果写到失败恢复的文章的话会详细介绍。CompletedCheckpointStore本质上主要是提供获取高可用存储下备份的JobGraph进行任务恢复的方法。
  • ZookeeperCheckpointRecoveryJob的提供CompletedCheckpointStore的实现中具体存储方式是将在高可用文件系统(如HDFS)上保存的Checkpoint文件的地址存储在/flink/cluster_id/checkpoints/路径下。其中ZK的路径由配置中的high-availability.zookeeper.path.checkpoints参数来制定，文件系统上存储的路径由配置中的high-availability.storageDir指定。
  • ZooKeeperCheckpointRecoveryFactory中提供CheckpointIDCounter是通过Curator的SharedCount来实现的，是一个高可用的计数器，路径由配置中high-availability.zookeeper.path.checkpoint-counter来指定，默认是/checkpoint-counter

• SubmittedJobGraphStore

  • SubmittedJobGraphStore提供了将JobGraph高可用文件系统上的保存和移除功能，以及根据 JobID获取所要恢复的任务的JobGraph功能。但是在zk的目录和hdfs上的目录下我都没有找到相应的文件，这边先略过，有机会补上。

• RunningJobsRegistry

  • ZK实现RunningJobsRegistry负责在ZK节点上登记所有集群中运行的Job的状态，三种状态分别为RUNNING，PENDING和FINISHED。ZK上的路径可以通过high-availability.zookeeper.path.running-registry来指定。

总结

• 本文简单的介绍了一下Flink高可用服务的功能，和基于ZK的典型实现。其中SubmittedJobGraphStore部分的实际运行不符合我的预期，后续有机会更正。