[源碼解析] 從TimeoutException看Flink的心跳機制

目錄

• [源碼解析] 從TimeoutException看Flink的心跳機制
  • 0x00 摘要
  • 0x01 緣由
  • 0x02 背景概念
    • 2.1 四大模塊
    • 2.2 Akka
    • 2.3 RPC機制
      • 2.3.1 RpcEndpoint：RPC的基類
      • RpcService：RPC服務提供者
      • RpcGateway：RPC調用的網關
    • 2.4 常見心跳機制
  • 0x03 Flink心跳機制
    • 3.1 代碼和機制
    • 3.2 靜態架構
      • 3.2.1 HeartbeatTarget ：監控目標抽象
      • 3.2.2 HeartbeatMonitor : 管理heartbeat target的心跳狀態
      • 3.2.3 HeartbeatManager ：心跳管理者
      • 3.2.4 HearbeatListener 處理心跳結果
    • 3.3 動態運行機制
      • 3.3.1 HearbeatManagerImpl : Receiver
      • 3.3.2 HeartbeatManagerSenderImpl : Sender
      • 3.3.3 HeartbeatMonitorImpl
      • 3.3.3 HeartbeatServices
  • 0x04 初始化
    • 4.1 心跳服務創建
  • 0x05 Flink中具體應用
    • 5.1 總述
      • 5.1.1 RM, JM, TM之間關係
      • 5.1.2 三者間心跳機制
    • 5.2 初始化過程
      • 5.2.1 TaskExecutor初始化
      • 5.2.2 JobMaster的初始化
      • 5.2.3 ResourceManager初始化
    • 5.3 註冊過程
      • 5.3.1 TM註冊到RM中
        • 5.3.1.1 TM的操作
        • 5.3.1.2 RM的操作
        • 5.3.1.3 返回到TM
      • 5.3.2 TM註冊到 JM
    • 5.4 心跳過程
      • 5.4.1 ResourceManager主動發起
        • 5.4.1.1 Sender遍歷所有監控的Monitor（Target）
        • 5.4.1.2 Target進行具體操作
        • 5.4.1.3 RPC調用
      • 5.4.2 RM通過RPC調用TM
      • 5.4.3 TM 通過RPC回到 RM
    • 5.5 超時處理
      • 5.5.1 TaskManager
      • 5.5.2 ResourceManager
  • 0x06 解決問題
  • 0x07 參考

0x00 摘要

本文從一個調試時候常見的異常 “TimeoutException: Heartbeat of TaskManager timed out”切入，為大家剖析Flink的心跳機制。文中代碼基於Flink 1.10。

0x01 緣由

大家如果經常調試Flink，當進入斷點看到了堆棧和變量內容之後，你容易陷入了沉思。當你發現了問題可能所在，高興的讓程序Resume的時候，你發現程序無法運行，有如下提示：

Caused by: java.util.concurrent.TimeoutException: Heartbeat of TaskManager with id 93aa1740-cd2c-4032-b74a-5f256edb3217 timed out.

這實在是很鬱悶的事情。作為程序猿不能忍啊，既然異常提示中有 Heartbeat 字樣，於是我們就來一起看看Flink的心跳機制，看看有沒有可以修改的途徑。

0x02 背景概念

2.1 四大模塊

Flink有核心四大組件：Dispatcher，JobMaster，ResourceManager，TaskExecutor。

• Dispatcher（Application Master）用於接收client提交的任務和啟動相應的JobManager。其提供REST接口來接收client的application提交，負責啟動JM和提交application，同時運行Web UI。
• ResourceManager：主要用於資源的申請和分配。當TM有空閑的slot就會告訴JM，沒有足夠的slot也會啟動新的TM。kill掉長時間空閑的TM。
• JobMaster ：功能主要包括（舊版本中JobManager的功能在新版本中以JobMaster形式出現，可能本文中會混淆這兩個詞，請大家諒解）：
  • 將JobGraph轉化為ExecutionGraph（physical dataflow graph，并行化）。
  • 向RM申請資源、schedule tasks、保存作業的元數據。
• TaskManager：類似Spark的executor，會跑多個線程的task、數據緩存與交換。Flink 架構遵循 Master – Slave 架構設計原則，JobMaster 為 Master 節點，TaskManager 為Slave節點。

這四大組件彼此之間的通信需要依賴RPC實現。

2.2 Akka

Flink底層RPC基於Akka實現。Akka是一個開發併發、容錯和可伸縮應用的框架。它是Actor Model的一個實現，和Erlang的併發模型很像。在Actor模型中，所有的實體被認為是獨立的actors。actors和其他actors通過發送異步消息通信。

Actor模型的強大來自於異步。它也可以顯式等待響應，這使得可以執行同步操作。但是強烈不建議同步消息，因為它們限制了系統的伸縮性。

2.3 RPC機制

RPC作用是：讓異步調用看起來像同步調用。

Flink基於Akka構建了其底層通信系統，引入了RPC調用，各節點通過GateWay方式回調，隱藏通信組件的細節，實現解耦。Flink整個通信框架的組件主要由RpcEndpoint、RpcService、RpcServer、AkkaInvocationHandler、AkkaRpcActor等構成。

RPC相關的主要接口如下：

• RpcEndpoint
• RpcService
• RpcGateway

2.3.1 RpcEndpoint：RPC的基類

RpcEndpoint是Flink RPC終端的基類，所有提供遠程過程調用的分佈式組件必須擴展RpcEndpoint，其功能由RpcService支持。

RpcEndpoint的子類只有四類組件：Dispatcher，JobMaster，ResourceManager，TaskExecutor，即Flink中只有這四個組件有RPC的能力，換句話說只有這四個組件有RPC的這個需求。

每個RpcEndpoint對應了一個路徑（endpointId和actorSystem共同確定），每個路徑對應一個Actor，其實現了RpcGateway接口，

RpcService：RPC服務提供者

RpcServer是RpcEndpoint的成員變量，為RpcService提供RPC服務/連接遠程Server，其只有一個子類實現：AkkaRpcService（可見目前Flink的通信方式依然是Akka）。

RpcServer用於啟動和連接到RpcEndpoint， 連接到rpc服務器將返回一個RpcGateway，可用於調用遠程過程。

Flink四大組件Dispatcher，JobMaster，ResourceManager，TaskExecutor，都是RpcEndpoint的實現，所以構建四大組件時，同步需要初始化RpcServer。如JobManager的構造方式，第一個參數就是需要知道RpcService。

RpcGateway：RPC調用的網關

Flink的RPC協議通過RpcGateway來定義；由前面可知，若想與遠端Actor通信，則必須提供地址（ip和port），如在Flink-on-Yarn模式下，JobMaster會先啟動ActorSystem，此時TaskExecutor的Container還未分配，後面與TaskExecutor通信時，必須讓其提供對應地址。

Dispatcher，JobMaster，ResourceManager，TaskExecutor 這四大組件通過各種方式實現了Gateway。以JobMaster為例，JobMaster實現JobMasterGateway接口。各組件類的成員變量都有需要通信的其他組件的GateWay實現類，這樣可通過各自的Gateway實現RPC調用。

2.4 常見心跳機制

常見的心跳檢測有兩種：

• socket 套接字SO_KEEPALIVE本身帶有的心跳機制，定期向對方發送心跳包，對方收到心跳包後會自動回復；
• 應用自身實現心跳機制，同樣也是使用定期發送請求的方式；

Flink實現的是第二種方案。

0x03 Flink心跳機制

3.1 代碼和機制

Flink的心跳機制代碼在：

Flink-master/flink-runtime/src/main/java/org/apache/flink/runtime/heartbeat

四個接口：

HeartbeatListener.java          HeartbeatManager.java      HeartbeatTarget.java  HeartbeatMonitor.java

以及如下幾個類：

HeartbeatManagerImpl.java   HeartbeatManagerSenderImpl.java   HeartbeatMonitorImpl.java
HeartbeatServices.java    NoOpHeartbeatManager.java

Flink集群有多種業務流程，比如Resource Manager, Task Manager, Job Manager。每種業務流程都有自己的心跳機制。Flink的心跳機制只是提供接口和基本功能，具體業務功能由各業務流程自己實現。

我們首先設定 心跳系統中有兩種節點：sender和receiver。心跳機制是sender和receivers彼此相互檢測。但是檢測動作是Sender主動發起，即Sender主動發送請求探測receiver是否存活，因為Sender已經發送過來了探測心跳請求，所以這樣receiver同時也知道Sender是存活的，然後Reciver給Sender回應一個心跳錶示自己也是活着的。

因為Flink的幾個名詞和我們常見概念有所差別，所以流程上需要大家仔細甄別，即：

• Flink Sender 主動發送Request請求給Receiver，要求Receiver回應一個心跳；
• Flink Receiver 收到Request之後，通過Receive函數回應一個心跳請求給Sender；

3.2 靜態架構

3.2.1 HeartbeatTarget ：監控目標抽象

HeartbeatTarget是對監控目標的抽象。心跳機制在行為上而言有兩種動作：

• 向某個節點發送請求。
• 處理某個節點發來的請求。

HeartbeatTarget的函數就是這兩個動作：

• receiveHeartbeat ：向某個節點（Sender）發送心跳回應，其參數heartbeatOrigin 就是 Receiver。
• requestHeartbeat ：向某個節點（Receiver）要求其回應一個心跳，其參數requestOrigin 就是 Sender。requestHeartbeat這個函數是Sender的函數，其中Sender通過RPC直接調用到Receiver。

這兩個函數的參數也很簡單：分別是請求的發送放和接收方，還有Payload載荷。對於一個確定節點而言，接收的和發送的載荷是同一類型的。

public interface HeartbeatTarget<I> {
	/**
	 * Sends a heartbeat response to the target.
	 * @param heartbeatOrigin Resource ID identifying the machine for which a heartbeat shall be reported.
	 */
  // heartbeatOrigin 就是 Receiver
	void receiveHeartbeat(ResourceID heartbeatOrigin, I heartbeatPayload);

	/**
	 * Requests a heartbeat from the target. 
	 * @param requestOrigin Resource ID identifying the machine issuing the heartbeat request.
	 */
  // requestOrigin 就是 Sender
	void requestHeartbeat(ResourceID requestOrigin, I heartbeatPayload);
}

3.2.2 HeartbeatMonitor : 管理heartbeat target的心跳狀態

對HeartbeatTarget的封裝，這樣Manager對Target的操作是通過對Monitor完成，後續會在其繼承類中詳細說明。

public interface HeartbeatMonitor<O> {
  // Gets heartbeat target.
	HeartbeatTarget<O> getHeartbeatTarget();
	// Gets heartbeat target id.
	ResourceID getHeartbeatTargetId();
	// Report heartbeat from the monitored target.
	void reportHeartbeat();
	//Cancel this monitor.
	void cancel();
  //Gets the last heartbeat.
	long getLastHeartbeat();
}

3.2.3 HeartbeatManager ：心跳管理者

HeartbeatManager負責管理心跳機制，比如啟動/停止/報告一個HeartbeatTarget。此接口繼承HeartbeatTarget。

除了HeartbeatTarget的函數之外，這接口有4個函數：

• monitorTarget，把和某資源對應的節點加入到心跳監控列表;
• unmonitorTarget，從心跳監控列表刪除某資源對應的節點;
• stop，停止心跳管理服務，釋放資源;
• getLastHeartbeatFrom，獲取某節點的最後一次心跳數據。

public interface HeartbeatManager<I, O> extends HeartbeatTarget<I> {
	void monitorTarget(ResourceID resourceID, HeartbeatTarget<O> heartbeatTarget);
	void unmonitorTarget(ResourceID resourceID);
	void stop();
	long getLastHeartbeatFrom(ResourceID resourceId);
}

3.2.4 HearbeatListener 處理心跳結果

用戶業務邏輯需要繼承這個接口以處理心跳結果。其可以看做服務的輸出，實現了三個回調函數。

• notifyHeartbeatTimeout，處理節點心跳超時
• reportPayload，處理節點發來的Payload載荷
• retrievePayLoad。獲取對某節點發下一次心跳請求的Payload載荷

public interface HeartbeatListener<I, O> {
	void notifyHeartbeatTimeout(ResourceID resourceID);
	void reportPayload(ResourceID resourceID, I payload);
	O retrievePayload(ResourceID resourceID);
}

3.3 動態運行機制

之前提到Sender和Receiver，下面兩個類就對應上述概念。

• HeartbeatManagerImpl ：Receiver，存在於JobMaster與TaskExecutor中；
• HeartbeatManagerSenderImpl ：Sender，繼承 HeartbeatManagerImpl類，用於周期發送心跳要求，存在於JobMaster、ResourceManager中。

幾個關鍵問題：

1. 如何判定心跳超時？

   心跳服務啟動后，Flink在Monitor中通過 ScheduledFuture 會啟動一個線程來處理心跳超時事件。在設定的心跳超時時間到達后才執行線程。

   如果在設定的心跳超時時間內接收到組件的心跳消息，會先將該線程取消而後重新開啟，重置心跳超時事件的觸發。

   如果在設定的心跳超時時間內沒有收到組件的心跳，則會通知組件：你超時了。

2. 何時”調用雙方”發起心跳檢查？

   心跳檢查是雙向的，一方（Sender）會主動發起心跳請求，而另一方（Receiver）則是對心跳做出響應，兩者通過RPC相互調用，重置對方的 Monitor 超時線程。

   以JobMaster和TaskManager為例，JM在啟動時會開啟周期調度，向已經註冊到JM中的TM發起心跳檢查，通過RPC調用TM的requestHeartbeat方法，重置TM中對JM超時線程的調用，表示當前JM狀態正常。在TM的requestHeartbeat方法被調用后，通過RPC調用JM的receiveHeartbeat，重置 JM 中對TM超時線程的調用，表示TM狀態正常。

3. 如何處理心跳超時？

   心跳服務依賴 HeartbeatListener，當在timeout時間範圍內未接收到心跳響應，則會觸發超時處理線程，該線程通過調用HeartbeatListener.notifyHeartbeatTimeout方法做後續重連操作或者直接斷開。

下面是一個概要（以RM & TM為例）：

• RM : 實現了ResourceManagerGateway (可以直接被RPC調用)

• TM : 實現了TaskExecutorGateway (可以直接被RPC調用)

• RM ：有一個Sender HM ： taskManagerHeartbeatManager，Sender HM 擁有用戶定義的 TaskManagerHeartbeatListener

• TM ：有一個Receiver HM ：resourceManagerHeartbeatManager，Receiver HM 擁有用戶定義的ResourceManagerHeartbeatListener。

• HeartbeatManager 有一個ConcurrentHashMap<ResourceID, HeartbeatMonitor > heartbeatTargets，這個Map是它監控的所有Target。

• 對於RM的每一個需要監控的TM, 其生成一個HeartbeatTarget，進而被構造成一個HeartbeatMonitor，放置到ResourceManager.taskManagerHeartbeatManager中。

• 每一個Target對應的Monitor中，有自己的異步任務ScheduledFuture，這個ScheduledFuture不停的被取消/重新生成。如果在某個期間內沒有被取消，則通知用戶定義的listener出現了timeout。

3.3.1 HearbeatManagerImpl : Receiver

HearbeatManagerImpl是receiver的具體實現。它由 心跳 被發起方（就是Receiver，例如TM） 創建，接收 發起方（就是Sender，例如 JM）的心跳發送請求。心跳超時 會觸發 heartbeatListener.notifyHeartbeatTimeout方法。

注意：被發起方監控線程（Monitor）的開啟是在接收到請求心跳（requestHeartbeat被調用后）以後才觸發的，屬於被動觸發。

HearbeatManagerImpl主要維護了

• 一個心跳監控列表 map : <ResourceID, HeartbeatMonitor<O>> heartbeatTargets;。這是一個KV關聯。

  key代表要發送心跳組件（例如：TM）的ID，value則是為當前組件創建的觸發心跳超時的線程HeartbeatMonitor，兩者一一對應。

  當一個從所聯繫的machine發過來的心跳被收到時候，對應的monitor的狀態會被更新（重啟一個新ScheduledFuture）。當一個monitor發現了一個 heartbeat timed out，它會通知自己的HeartbeatListener。

• 一個 ScheduledExecutor mainThreadExecutor 負責heartbeat timeout notifications。

• heartbeatListener ：處理心跳結果。

HearbeatManagerImpl 數據結構如下：

@ThreadSafe
public class HeartbeatManagerImpl<I, O> implements HeartbeatManager<I, O> {

	/** Heartbeat timeout interval in milli seconds. */
	private final long heartbeatTimeoutIntervalMs;

	/** Resource ID which is used to mark one own's heartbeat signals. */
	private final ResourceID ownResourceID;

	/** Heartbeat listener with which the heartbeat manager has been associated. */
	private final HeartbeatListener<I, O> heartbeatListener;

	/** Executor service used to run heartbeat timeout notifications. */
	private final ScheduledExecutor mainThreadExecutor;

	/** Map containing the heartbeat monitors associated with the respective resource ID. */
	private final ConcurrentHashMap<ResourceID, HeartbeatMonitor<O>> heartbeatTargets;

	/** Running state of the heartbeat manager. */
	protected volatile boolean stopped;  
}

HearbeatManagerImpl實現的主要函數有：

• monitorTarget ：把一個節點加入到心跳監控列表。
  • 傳入參數有：ResourceId和HearbeatTarget，monitorTarget根據這兩個參數，生成一個HeartbeatMonitor對象，然後把這個對象跟ResrouceId做kv關聯，存入到heartbeatTargets。 一個節點可能參与多個業務流程，因此一個節點參与多個心跳流程，一個節點上運行多個不同類型的HearbeatTarget。所以一個ResourceID可能會跟不同類型的HearbeatTarget對象關聯，分別加入到多個HeartbeatManager，進行不同類型的心跳監控。也因此這個函數入參是兩個參數。
• requestHeartbeat ：Sender通過RPC異步調用到Receiver的這個函數 以要求receiver向requestOrigin節點（就是Sender）發起一次心跳響應，載荷是heartbeatPayLoad。其內部流程如下：
  • 首先會調用reportHeartbeat函數，作用是 通過Monitor 記錄發起請求的這個時間點，然後創建一個ScheduleFuture。如果到期后，requestOrigin沒有作出響應，那麼就將requestOrigin節點對應的HeartbeatMonitor的state設置成TIMEOUT狀態，如果到期內requestOrigin響應了，ScheduleFuture會被取消，HeartbeatMonitor的state仍然是RUNNING。
  • 其次調用reportPayload函數，把requestOrigin節點的最新的heartbeatPayload通知給heartbeatListener。heartbeatListener是外部傳入的，它根據所有節點的心跳記錄做監聽管理。
  • 最後調用receiveHearbeat函數，響應一個心跳給Sender。

3.3.2 HeartbeatManagerSenderImpl : Sender

繼承HearbeatManagerImpl，由心跳管理的一方(例如JM)創建，實現了run函數（即它可以作為一個單獨線程運行），創建后立即開啟周期調度線程，每次遍歷自己管理的heartbeatTarget，觸發heartbeatTarget.requestHeartbeat，要求 Target 返回一個心跳響應。屬於主動觸發心跳請求。

public class HeartbeatManagerSenderImpl<I, O> extends HeartbeatManagerImpl<I, O> implements Runnable {
	public void run() {
		if (!stopped) {
			for (HeartbeatMonitor<O> heartbeatMonitor : getHeartbeatTargets().values()) {
				requestHeartbeat(heartbeatMonitor);
			}
      // 周期調度
			getMainThreadExecutor().schedule(this, heartbeatPeriod, TimeUnit.MILLISECONDS);
		}
	}

  //  主動發起心跳檢查
	private void requestHeartbeat(HeartbeatMonitor<O> heartbeatMonitor) {
		O payload = getHeartbeatListener().retrievePayload(heartbeatMonitor.getHeartbeatTargetId());
		final HeartbeatTarget<O> heartbeatTarget = heartbeatMonitor.getHeartbeatTarget();
    // 調用 Target 的 requestHeartbeat 函數
		heartbeatTarget.requestHeartbeat(getOwnResourceID(), payload);
	}  
}

3.3.3 HeartbeatMonitorImpl

Heartbeat monitor管理心跳目標，它啟動一個ScheduledExecutor。

• 如果在timeout時間內沒有接收到心跳信號，則判定心跳超時，通知給HeartbeatListener。
• 如果在timeout時間內接收到心跳信號，則重置當前ScheduledExecutor。

public class HeartbeatMonitorImpl<O> implements HeartbeatMonitor<O>, Runnable {

	/** Resource ID of the monitored heartbeat target. */
	private final ResourceID resourceID;   // 被監控的resource ID

	/** Associated heartbeat target. */
	private final HeartbeatTarget<O> heartbeatTarget; //心跳目標

	private final ScheduledExecutor scheduledExecutor;

	/** Listener which is notified about heartbeat timeouts. */
	private final HeartbeatListener<?, ?> heartbeatListener; // 心跳監聽器

	/** Maximum heartbeat timeout interval. */
	private final long heartbeatTimeoutIntervalMs;

	private volatile ScheduledFuture<?> futureTimeout;
  //  AtomicReference  使用 
	private final AtomicReference<State> state = new AtomicReference<>(State.RUNNING);
   //  最近一次接收到心跳的時間
  private volatile long lastHeartbeat;
  
	// 報告心跳
	public void reportHeartbeat() {
    // 保留最近一次接收心跳時間
		lastHeartbeat = System.currentTimeMillis();
    // 接收心跳后，重置timeout線程
		resetHeartbeatTimeout(heartbeatTimeoutIntervalMs);
	}

  // 心跳超時，觸發lister的notifyHeartbeatTimeout
	public void run() {
		// The heartbeat has timed out if we're in state running
		if (state.compareAndSet(State.RUNNING, State.TIMEOUT)) {
			heartbeatListener.notifyHeartbeatTimeout(resourceID);
		}
	}

  //  重置TIMEOUT
	void resetHeartbeatTimeout(long heartbeatTimeout) {
		if (state.get() == State.RUNNING) {
      //先取消線程，在重新開啟
			cancelTimeout();
      // 啟動超時線程
			futureTimeout = scheduledExecutor.schedule(this, heartbeatTimeout, TimeUnit.MILLISECONDS);

			// Double check for concurrent accesses (e.g. a firing of the scheduled future)
			if (state.get() != State.RUNNING) {
				cancelTimeout();
			}
		}
	}

3.3.3 HeartbeatServices

建立heartbeat receivers and heartbeat senders，主要是對外提供服務。這裏我們可以看到：

• HeartbeatManagerImpl就是receivers。
• HeartbeatManagerSenderImpl就是senders。

public class HeartbeatServices {
	// Creates a heartbeat manager which does not actively send heartbeats.
	public <I, O> HeartbeatManager<I, O> createHeartbeatManager(...) {
		return new HeartbeatManagerImpl<>(...);
	}
	// Creates a heartbeat manager which actively sends heartbeats to monitoring targets.
	public <I, O> HeartbeatManager<I, O> createHeartbeatManagerSender(...) {
		return new HeartbeatManagerSenderImpl<>(...);
	}
}

0x04 初始化

4.1 心跳服務創建

心跳管理服務在Cluster入口創建。因為我們是調試，所以在MiniCluster.start調用。

public void start() throws Exception {
				......
				heartbeatServices = HeartbeatServices.fromConfiguration(configuration);
				......
}

HeartbeatServices.fromConfiguration會從Configuration中獲取配置信息：

• 心跳間隔 heartbeat.interval
• 心跳超時時間 heartbeat.timeout

這個就是我們解決最開始問題的思路：從配置信息入手，擴大心跳間隔。

public HeartbeatServices(long heartbeatInterval, long heartbeatTimeout) {
		this.heartbeatInterval = heartbeatInterval;
		this.heartbeatTimeout = heartbeatTimeout;
}

public static HeartbeatServices fromConfiguration(Configuration configuration) {
		long heartbeatInterval = configuration.getLong(HeartbeatManagerOptions.HEARTBEAT_INTERVAL);
		long heartbeatTimeout = configuration.getLong(HeartbeatManagerOptions.HEARTBEAT_TIMEOUT);

		return new HeartbeatServices(heartbeatInterval, heartbeatTimeout);
}

0x05 Flink中具體應用

5.1 總述

5.1.1 RM, JM, TM之間關係

系統中有幾個ResourceManager？整個 Flink 集群中只有一個 ResourceManager。

系統中有幾個JobManager？JobManager 負責管理作業的執行。默認情況下，每個 Flink 集群只有一個 JobManager 實例。JobManager 相當於整個集群的 Master 節點，負責整個集群的任務管理和資源管理。

系統中有幾個TaskManager？這個由具體啟動方式決定。比如Flink on Yarn，Session模式能夠指定拉起多少個TaskManager。 Per job模式中TaskManager數量是在提交作業時根據併發度動態計算，即Number of TM = Parallelism/numberOfTaskSlots。比如：有一個作業，Parallelism為10，numberOfTaskSlots為1，則TaskManager為10。

5.1.2 三者間心跳機制

Flink中ResourceManager、JobMaster、TaskExecutor三者之間存在相互檢測的心跳機制：

• ResourceManager會主動發送請求探測JobMaster、TaskExecutor是否存活。
• JobMaster也會主動發送請求探測TaskExecutor是否存活，以便進行任務重啟或者失敗處理。

我們之前講過，HeartbeatManagerSenderImpl屬於Sender，HeartbeatManagerImpl屬於Receiver。

1. HeartbeatManagerImpl所處位置可以理解為client，存在於JobMaster與TaskExecutor中；
2. HeartbeatManagerSenderImpl類，繼承 HeartbeatManagerImpl類，用於周期發送心跳請求，所處位置可以理解為server, 存在於JobMaster、ResourceManager中。

ResourceManager 級別最高，所以兩個HM都是Sender，監控taskManager和jobManager

public abstract class ResourceManager<WorkerType extends ResourceIDRetrievable>
		extends FencedRpcEndpoint<ResourceManagerId>
		implements ResourceManagerGateway, LeaderContender {
	taskManagerHeartbeatManager = heartbeatServices.createHeartbeatManagerSender
	jobManagerHeartbeatManager = heartbeatServices.createHeartbeatManagerSender
}

JobMaster級別中等，一個Sender, 一個Receiver，受到ResourceManager的監控，監控taskManager。

public class JobMaster extends FencedRpcEndpoint<JobMasterId> implements JobMasterGateway, JobMasterService {
	taskManagerHeartbeatManager = heartbeatServices.createHeartbeatManagerSender
	resourceManagerHeartbeatManager = heartbeatServices.createHeartbeatManager
}

TaskExecutor級別最低，兩個Receiver，分別被JM和RM疾控。

public class TaskExecutor extends RpcEndpoint implements TaskExecutorGateway {
	this.jobManagerHeartbeatManager = return heartbeatServices.createHeartbeatManager
	this.resourceManagerHeartbeatManager = return heartbeatServices.createHeartbeatManager
}

以JobManager和TaskManager為例。JM在啟動時會開啟周期調度，向已經註冊到JM中的TM發起心跳檢查，通過RPC調用TM的requestHeartbeat方法，重置對JM超時線程的調用，表示當前JM狀態正常。在TM的requestHeartbeat方法被調用后，通過RPC調用JM的receiveHeartbeat，重置對TM超時線程的調用，表示TM狀態正常。

5.2 初始化過程

5.2.1 TaskExecutor初始化

TM初始化生成了兩個Receiver HM。

public class TaskExecutor extends RpcEndpoint implements TaskExecutorGateway {
	/** The heartbeat manager for job manager in the task manager. */
	private final HeartbeatManager<AllocatedSlotReport, AccumulatorReport> jobManagerHeartbeatManager;

	/** The heartbeat manager for resource manager in the task manager. */
	private final HeartbeatManager<Void, TaskExecutorHeartbeatPayload> resourceManagerHeartbeatManager;
  
  //初始化函數
	this.jobManagerHeartbeatManager = createJobManagerHeartbeatManager(heartbeatServices, resourceId);
	this.resourceManagerHeartbeatManager = createResourceManagerHeartbeatManager(heartbeatServices, resourceId);
}

生成HeartbeatManager時，就註冊了ResourceManagerHeartbeatListener和JobManagerHeartbeatListener。

此時，兩個HeartbeatManagerImpl中已經創建好對應monitor線程，只有在JM或者RM執行requestHeartbeat后，才會觸發該線程的執行。

5.2.2 JobMaster的初始化

JM生成了一個Sender HM，一個Receiver HM。這裡會註冊 TaskManagerHeartbeatListener 和 ResourceManagerHeartbeatListener

public class JobMaster extends FencedRpcEndpoint<JobMasterId> implements JobMasterGateway, JobMasterService {
  private HeartbeatManager<AccumulatorReport, AllocatedSlotReport> taskManagerHeartbeatManager;
  private HeartbeatManager<Void, Void> resourceManagerHeartbeatManager;

  private void startHeartbeatServices() {
      taskManagerHeartbeatManager = heartbeatServices.createHeartbeatManagerSender(
        resourceId,
        new TaskManagerHeartbeatListener(),
        getMainThreadExecutor(),
        log);

      resourceManagerHeartbeatManager = heartbeatServices.createHeartbeatManager(
        resourceId,
        new ResourceManagerHeartbeatListener(),
        getMainThreadExecutor(),
        log);
  }
}

5.2.3 ResourceManager初始化

JobMaster在啟動時候，會在startHeartbeatServices函數中生成兩個Sender HeartbeatManager。

taskManagerHeartbeatManager ：HeartbeatManagerSenderImpl對象，會反覆啟動一個定時器，定時掃描需要探測的對象並且發送心跳請求。

jobManagerHeartbeatManager ：HeartbeatManagerSenderImpl，會反覆啟動一個定時器，定時掃描需要探測的對象並且發送心跳請求。

taskManagerHeartbeatManager = heartbeatServices.createHeartbeatManagerSender(
			resourceId,
			new TaskManagerHeartbeatListener(),
			getMainThreadExecutor(),
			log);

jobManagerHeartbeatManager = heartbeatServices.createHeartbeatManagerSender(
			resourceId,
			new JobManagerHeartbeatListener(),
			getMainThreadExecutor(),
			log);  

5.3 註冊過程

我們以TM與RM交互為例。TaskExecutor啟動之後，需要註冊到RM和JM中。

流程圖如下：

 * 1. Run in Task Manager
 *
 *    TaskExecutor.onStart //Life cycle
 *        |
 *        +----> startTaskExecutorServices@TaskExecutor
 *        |     //開始TM服務
 *        |     
 *        +----> resourceManagerLeaderRetriever.start(new ResourceManagerLeaderListener());
 *        |     // 開始連接到RM
 *        |     // start by connecting to the ResourceManager
 *        |    
 *        +----> notifyLeaderAddress@ResourceManagerLeaderListener  
 *        |     // 當RM狀態變化之後，將回調到這裏    
 *        |     // The listener for leader changes of the resource manager.
 *        |        
 *        +----> reconnectToResourceManager@TaskExecutor   
 *        |     // 以下三步調用是漸進的，就是與RM聯繫。
 *        |    
 *        +----> tryConnectToResourceManager@TaskExecutor 
 *        |     
 *        +----> connectToResourceManager()@TaskExecutor
 *        |     // 主要作用是生成了 TaskExecutorToResourceManagerConnection    
 *        |  
 *        +----> start@TaskExecutorToResourceManagerConnection
 *        |     // 開始RPC調用，將會調用到其基類RegisteredRpcConnection的start   
 *        |   
 *        +----> start@RegisteredRpcConnection
 *        |     // RegisteredRpcConnection實現了組件之間註冊聯繫的基本RPC
 *        |      
   
   
 * ~~~~~~~~ 這裡是 Akka RPC
   
 * 2. Run in Resource Manager   
 * 現在程序執行序列到達了RM, 主要是添加一個Target到RM 的 Sender HM；
 *
 *    registerTaskExecutor@ResourceManager
 *        |
 *        +----> taskExecutorGatewayFuture.handleAsync
 *        |     // 異步調用到這裏
 *        |     
 *        +----> registerTaskExecutorInternal@ResourceManager
 *        |     // RM的內部實現，將把TM註冊到RM自己這裏
 *        |      
 *        +----> taskManagerHeartbeatManager.monitorTarget
 *        |     // 生成HeartbeatMonitor，
 *        |      
 *        +---->  heartbeatTargets.put(resourceID,heartbeatMonitor);
 *        |     // 把Monitor放到 HM in TM之中，就是說TM開始監控了RM
 *        |        

 * ~~~~~~~~ 這裡是 Akka RPC
  
 * 3. Run in Task Manager
 * 現在程序回到了TM, 主要是添加一個Target到 TM 的 Receiver HM；
 *
 *    onRegistrationSuccess@TaskExecutorToResourceManagerConnection
 *        |   
 *        |   
 *        +---->  onRegistrationSuccess@ResourceManagerRegistrationListener 
 *        |       // 回調函數
 *        |  
 *        +---->  runAsync(establishResourceManagerConnection) 
 *        |       // 異步執行
 *        |  
 *        +---->  establishResourceManagerConnection@TaskExecutor 
 *        |       // 說明已經和RM建立了聯繫，所以可以開始監控RM了
 *        |  
 *        +---->  resourceManagerHeartbeatManager.monitorTarget 
 *        |     // 生成HeartbeatMonitor，
 *        |      
 *        +---->  heartbeatTargets.put(resourceID,heartbeatMonitor);  
 *        |       // 把 RM 也註冊到 TM了
 *        |       // monitor the resource manager as heartbeat target 

下面是具體文字描述。

5.3.1 TM註冊到RM中

5.3.1.1 TM的操作

• TaskExecutor啟動之後，調用onStart，開始其生命周期。
• onStart直接調用startTaskExecutorServices。
• 啟動服務的第一步就是與ResourceManager取得聯繫，這裏註冊了一個ResourceManagerLeaderListener()，用來監聽RM Leader的變化。

private final LeaderRetrievalService resourceManagerLeaderRetriever;
// resourceManagerLeaderRetriever其實是EmbeddedLeaderService的實現，A simple leader election service, which selects a leader among contenders and notifies listeners.

resourceManagerLeaderRetriever.start(new ResourceManagerLeaderListener());

• 當得到RM Leader的地址之後，會調用到回調函數notifyLeaderAddress@ResourceManagerLeaderListener，然後調用notifyOfNewResourceManagerLeader。
• notifyOfNewResourceManagerLeader中獲取到RM地址后，就通過reconnectToResourceManager與RM聯繫。
• reconnectToResourceManager中間接調用到TaskExecutorToResourceManagerConnection。其作用是建立TaskExecutor 和 ResourceManager之間的聯繫。因為知道 ResourceManagerGateway所以才能進行RPC操作。
• 然後在 TaskExecutorToResourceManagerConnection中，就通過RPC與RM聯繫。

5.3.1.2 RM的操作

• RPC調用后，程序就來到了RM中，RM做如下操作：
• 會註冊一個新的TaskExecutor到自己的taskManagerHeartbeatManager中。
• registerTaskExecutor@ResourceManager會通過異步調用到registerTaskExecutorInternal。
• registerTaskExecutorInternal中首先看看是否這個TaskExecutor的ResourceID之前註冊過，如果註冊過就移除再添加一個新的TaskExecutor。
• 通過 taskManagerHeartbeatManager.monitorTarget 開始進行心跳機制的註冊。

taskManagerHeartbeatManager.monitorTarget(taskExecutorResourceId, new HeartbeatTarget<Void>() {
				public void receiveHeartbeat(ResourceID resourceID, Void payload) {
					// the ResourceManager will always send heartbeat requests to the
					// TaskManager
				}
				public void requestHeartbeat(ResourceID resourceID, Void payload) {
					taskExecutorGateway.heartbeatFromResourceManager(resourceID);
				}
});

當註冊完成后，RM中的Sender HM內部結構如下，能看出來多了一個Target：

taskManagerHeartbeatManager = {HeartbeatManagerSenderImpl@8866} 
 heartbeatPeriod = 10000
 heartbeatTimeoutIntervalMs = 50000
 ownResourceID = {ResourceID@8871} "040709f36ebf38f309fed518a88946af"
 heartbeatListener = {ResourceManager$TaskManagerHeartbeatListener@8872} 
 mainThreadExecutor = {RpcEndpoint$MainThreadExecutor@8873} 
 heartbeatTargets = {ConcurrentHashMap@8875}  size = 1
  {ResourceID@8867} "630c15c9-4861-4b41-9c95-92504f458b71" -> {HeartbeatMonitorImpl@9448} 
   key = {ResourceID@8867} "630c15c9-4861-4b41-9c95-92504f458b71"
   value = {HeartbeatMonitorImpl@9448} 
    resourceID = {ResourceID@8867} "630c15c9-4861-4b41-9c95-92504f458b71"
    heartbeatTarget = {ResourceManager$2@8868} 
    scheduledExecutor = {RpcEndpoint$MainThreadExecutor@8873} 
    heartbeatListener = {ResourceManager$TaskManagerHeartbeatListener@8872} 
    heartbeatTimeoutIntervalMs = 50000
    futureTimeout = {ScheduledFutureAdapter@10140} 
    state = {AtomicReference@9786} "RUNNING"
    lastHeartbeat = 0

5.3.1.3 返回到TM

RM會通過RPC再次回到TaskExecutor，其新執行序列如下：

• 首先RPC調用到了 onRegistrationSuccess@TaskExecutorToResourceManagerConnection。
• 然後onRegistrationSuccess@ResourceManagerRegistrationListener中通過異步執行調用到了establishResourceManagerConnection。這說明TM已經和RM建立了聯繫，所以可以開始監控RM了。
• 然後和RM操作類似，通過resourceManagerHeartbeatManager.monitorTarget 來把RM註冊到自己這裏。

HeartbeatMonitor<O> heartbeatMonitor = heartbeatMonitorFactory.createHeartbeatMonitor 
heartbeatTargets.put(resourceID, heartbeatMonitor);  

當註冊完成后，其Receiver HM結構如下：

resourceManagerHeartbeatManager = {HeartbeatManagerImpl@10163} 
 heartbeatTimeoutIntervalMs = 50000
 ownResourceID = {ResourceID@8882} "96a9b80c-dd97-4b63-9049-afb6662ea3e2"
 heartbeatListener = {TaskExecutor$ResourceManagerHeartbeatListener@10425} 
 mainThreadExecutor = {RpcEndpoint$MainThreadExecutor@10426} 
 heartbeatTargets = {ConcurrentHashMap@10427}  size = 1
  {ResourceID@8886} "122fa66685133b11ea26ee1b1a6cef75" -> {HeartbeatMonitorImpl@10666} 
   key = {ResourceID@8886} "122fa66685133b11ea26ee1b1a6cef75"
   value = {HeartbeatMonitorImpl@10666} 
    resourceID = {ResourceID@8886} "122fa66685133b11ea26ee1b1a6cef75"
    heartbeatTarget = {TaskExecutor$1@10668} 
    scheduledExecutor = {RpcEndpoint$MainThreadExecutor@10426} 
    heartbeatListener = {TaskExecutor$ResourceManagerHeartbeatListener@10425} 
    heartbeatTimeoutIntervalMs = 50000
    futureTimeout = {ScheduledFutureAdapter@10992} 
    state = {AtomicReference@10667} "RUNNING"
    lastHeartbeat = 0

5.3.2 TM註冊到 JM

其調用基本思路與之前相同，就是TM和JM之間互相註冊一個代表對方的monitor：

JobLeaderListenerImpl ----> establishJobManagerConnection

消息到了JM中，做如下操作。

registerTaskManager ----> taskManagerHeartbeatManager.monitorTarget
  // monitor the task manager as heartbeat target

5.4 心跳過程

在任務提交之後，我們就進入了正常的心跳監控流程。我們依然用 TM 和 RM進行演示。

我們先給出一個流程圖。

 * 1. Run in Resouce Manager
 *
 *    HeartbeatManagerSender in RM
 *        |
 *        +----> run@HeartbeatManagerSenderImpl
 *        |     //遍歷所有監控的Monitor（Target），逐一在Target上調用requestHeartbeat
 *        |     
 *        +----> requestHeartbeat@HeartbeatManagerSenderImpl 
 *        |     // 將調用具體監控對象的自定義函數
 *        |     // heartbeatTarget.requestHeartbeat(getOwnResourceID(), payload);
 *        |      
 *        +----> getHeartbeatListener().retrievePayload   
 *        |     // 調用到TaskManagerHeartbeatListener@ResourceManager    
 *        |     // 這裡是return null;，因為RM不會是任何人的Receiver
 *        |        
 *        +----> requestHeartbeat@HeartbeatTarget   
 *        |     // 調用到Target這裏，代碼在ResourceManager這裏，就是生成Target時候賦值的
 *        |    
 *        +----> taskExecutorGateway.heartbeatFromResourceManager
 *        |     // 會通過gateway RPC 調用到TM，這就是主動對TM發起了心跳請求
 *        |      

 * ~~~~~~~~ 這裡是 Akka RPC
   
 * 2. Run in Task Manager   
 * 現在程序執行序列到達了TM, 主要是 1. 重置TM的Monitor線程; 2.返回一些負載信息；
 *
 *    heartbeatFromResourceManager@TaskExecutor
 *        |
 *        +----> resourceManagerHeartbeatManager.requestHeartbeat(resourceID, null);
 *        |     //開始要調用到 Receiver HM in Task Manager
 *        |     
 *        +----> requestHeartbeat@HeartbeatManager in TM 
 *        |     // 在Receiver HM in Task Manager 這裏運行
 *        |      
 *        +----> reportHeartbeat@HeartbeatMonitor   
 *        |     //reportHeartbeat : 記錄發起請求的這個時間點，然後resetHeartbeatTimeout
 *        |      
 *        +----> resetHeartbeatTimeout@HeartbeatMonitor
 *        |     // 如果Monitor狀態依然是RUNNING，則取消之前設置的ScheduledFuture。
 *        |     // 重新創建一個ScheduleFuture。因為如果不取消，則之前那個ScheduleFuture運行時
 *        |     // 會調用HeartbeatMonitorImpl.run函數，run直接compareAndSet后，通知目標函數
 *        |     // 目前已經超時，即調用heartbeatListener.notifyHeartbeatTimeout。
 *        |     // 這裏代表 JM 狀態正常。   
 *        |      
 *        +---->  heartbeatListener.reportPayload
 *        |     // 把Target節點的最新的heartbeatPayload通知給heartbeatListener。 
 *        |     // heartbeatListerner是外部傳入的，它根據所擁有的節點的心跳記錄做監聽管理。
 *        |        
 *        +---->  heartbeatTarget.receiveHeartbeat(getOwnResourceID(), heartbeatListener.retrievePayload(requestOrigin));
 *        |      
 *        |     
 *        +---->  retrievePayload@ResourceManagerHeartbeatListener in TM   
 *        |       // heartbeatTarget.receiveHeartbeat參數調用的
 *        |     
 *        +---->  return new TaskExecutorHeartbeatPayload
 *        |   
 *        |     
 *        +---->  receiveHeartbeat in TM 
 *        |       // 回到 heartbeatTarget.receiveHeartbeat，這就是TM生成Target的時候的自定義函數
 *        |       // 就是響應一個心跳消息回給RM
 *        |     
 *        +----> resourceManagerGateway.heartbeatFromTaskManager  
 *        |     // 會通過gateway RPC 調用到 ResourcManager
 *        |      

 * ~~~~~~~~ 這裡是 Akka RPC
  
 * 3. Run in Resouce Manager
 * 現在程序回到了RM, 主要是 1.重置RM的Monitor線程；2. 上報收到TaskExecutor的負載信息  
 *
 *    heartbeatFromTaskManager in RM
 *        |   
 *        |   
 *        +---->  taskManagerHeartbeatManager.receiveHeartbeat 
 *        |       // 這是個Sender HM
 *        |  
 *        +---->  HeartbeatManagerImpl.receiveHeartbeat  
 *        |  
 *        |     
 *        +---->  HeartbeatManagerImpl.reportHeartbeat(heartbeatOrigin);
 *        | 
 *        |    
 *        +---->  heartbeatMonitor.reportHeartbeat(); 
 *        |      // 這裏就是重置RM 這裏對應的Monitor。在reportHeartbeat重置 JM monitor線程的觸發，即cancelTimeout取消註冊時候的超時定時任務，並且註冊下一個超時檢測futureTimeout；這代表TM正常執行。
 *        |     
 *        +----> heartbeatListener.reportPayload    
 *        |      //把Target節點的最新的heartbeatPayload通知給 TaskManagerHeartbeatListener。heartbeatListerner是外部傳入的，它根據所擁有的節點的心跳記錄做監聽管理。 
 *        |      
 *        +----> slotManager.reportSlotStatus(instanceId, payload.getSlotReport());
 *        |     // TaskManagerHeartbeatListener中調用，上報收到TaskExecutor的負載信息
 *        |        

下面是具體文字描述。

5.4.1 ResourceManager主動發起

5.4.1.1 Sender遍歷所有監控的Monitor（Target）

心跳機制是由Sender主動發起的。這裏就是 ResourceManager 的HeartbeatManagerSenderImpl中定時schedual調用，這裡會遍歷所有監控的Monitor（Target），逐一在Target上調用requestHeartbeat。

// HeartbeatManagerSenderImpl中的代碼

	@Override
	public void run() {
		if (!stopped) {
			for (HeartbeatMonitor<O> heartbeatMonitor : getHeartbeatTargets().values()) {
        // 這裏向被監控對象節點發起一次心跳請求，載荷是heartbeatPayLoad,要求被監控對象回應心跳
				requestHeartbeat(heartbeatMonitor);
			}
			getMainThreadExecutor().schedule(this, heartbeatPeriod, TimeUnit.MILLISECONDS);
		}
	}
}

// 運行時候的變量
this = {HeartbeatManagerSenderImpl@9037} 
 heartbeatPeriod = 10000
 heartbeatTimeoutIntervalMs = 50000
 ownResourceID = {ResourceID@8788} "d349506cae32cadbe99b9f9c49a01c95"
 heartbeatListener = {ResourceManager$TaskManagerHeartbeatListener@8789} 
 mainThreadExecutor = {RpcEndpoint$MainThreadExecutor@8790} 

// 調用棧如下
requestHeartbeat:711, ResourceManager$2 (org.apache.flink.runtime.resourcemanager)
requestHeartbeat:702, ResourceManager$2 (org.apache.flink.runtime.resourcemanager)
requestHeartbeat:92, HeartbeatManagerSenderImpl (org.apache.flink.runtime.heartbeat)
run:81, HeartbeatManagerSenderImpl (org.apache.flink.runtime.heartbeat)
call:511, Executors$RunnableAdapter (java.util.concurrent)
run$$$capture:266, FutureTask (java.util.concurrent)
run:-1, FutureTask (java.util.concurrent)

5.4.1.2 Target進行具體操作

具體監控對象 Target 會調用自定義的requestHeartbeat。

HeartbeatManagerSenderImpl

	private void requestHeartbeat(HeartbeatMonitor<O> heartbeatMonitor) {
		O payload = getHeartbeatListener().retrievePayload(heartbeatMonitor.getHeartbeatTargetId());
		final HeartbeatTarget<O> heartbeatTarget = heartbeatMonitor.getHeartbeatTarget();

    // 這裏就是具體監控對象
		heartbeatTarget.requestHeartbeat(getOwnResourceID(), payload);
	}

heartbeatTarget = {ResourceManager$2@10688} 
 taskExecutorGateway = {$Proxy42@9459} "org.apache.flink.runtime.rpc.akka.AkkaInvocationHandler@6d0c8334"
 this$0 = {StandaloneResourceManager@9458} 

請注意，每一個Target都是由ResourceManager生成的。ResourceManager之前註冊成為Monitor時候就註冊了這個HeartbeatTarget。

這個HeartbeatTarget的定義如下，兩個函數是：

• receiveHeartbeat ：這個是空，因為RM沒有自己的Sender。

• requestHeartbeat ：這個針對TM，就是調用TM的heartbeatFromResourceManager，當然是通過RPC調用。

5.4.1.3 RPC調用

會調用到ResourceManager定義的函數requestHeartbeat，而requestHeartbeat會通過gateway調用到TM，這就是主動對TM發起了心跳請求。

taskManagerHeartbeatManager.monitorTarget(taskExecutorResourceId, new HeartbeatTarget<Void>() {
   @Override
   public void receiveHeartbeat(ResourceID resourceID, Void payload) {
      // the ResourceManager will always send heartbeat requests to the TaskManager
   }

   @Override
   public void requestHeartbeat(ResourceID resourceID, Void payload) {
      //就是調用到這裏
      taskExecutorGateway.heartbeatFromResourceManager(resourceID); 
   }
});

5.4.2 RM通過RPC調用TM

通過taskExecutorGateway。心跳程序執行就通過RPC從RM跳躍到了TM。

taskExecutorGateway.heartbeatFromResourceManager 的意義就是：通過RPC調用回到TaskExecutor。這個是在TaskExecutorGateway就定義好的。

// TaskExecutor RPC gateway interface.
public interface TaskExecutorGateway extends RpcGateway

TaskExecutor實現了TaskExecutorGateway，所以具體在TaskExecutor內部實現了接口函數。

@Override
public void heartbeatFromResourceManager(ResourceID resourceID) {
    //調用到了這裏 ...........
		resourceManagerHeartbeatManager.requestHeartbeat(resourceID, null);
}

TM中，resourceManagerHeartbeatManager 定義如下。

/** The heartbeat manager for resource manager in the task manager. */
private final HeartbeatManager<Void, TaskExecutorHeartbeatPayload> resourceManagerHeartbeatManager;

所以下面就是執行TM中的Receiver HM。在這個過程中有兩個處理步驟：

1. 調用對應HeartbeatMonitor的reportHeartbeat方法，cancelTimeout取消註冊時候的超時定時任務，並且註冊下一個超時檢測futureTimeout；
2. 調用monitorTarget的receiveHeartbeat方法，也就是會通過rpc調用JobMaster的heartbeatFromTaskManager方法返回一些負載信息；

具體是調用 requestHeartbeat@HeartbeatManager。在其中會

• 調用reportHeartbeat@HeartbeatMonitor，記錄發起請求的這個時間點，然後resetHeartbeatTimeout。
• 在resetHeartbeatTimeout@HeartbeatMonitor之中，如果Monitor狀態依然是RUNNING，則取消之前設置的ScheduledFuture。重新創建一個ScheduleFuture。因為如果不取消，則之前那個ScheduleFuture運行時會調用HeartbeatMonitorImpl.run函數，run直接compareAndSet后，通知目標函數目前已經超時，即調用heartbeatListener.notifyHeartbeatTimeout。
• 調用 heartbeatListener.reportPayload，把Target節點的最新的heartbeatPayload通知給heartbeatListener。
• 調用 heartbeatTarget.receiveHeartbeat(getOwnResourceID(), heartbeatListener.retrievePayload(requestOrigin)); 就是響應一個心跳消息回給RM。

	@Override
	public void requestHeartbeat(final ResourceID requestOrigin, I heartbeatPayload) {
		if (!stopped) {
			log.debug("Received heartbeat request from {}.", requestOrigin);

			final HeartbeatTarget<O> heartbeatTarget = reportHeartbeat(requestOrigin);

			if (heartbeatTarget != null) {
				if (heartbeatPayload != null) {
					heartbeatListener.reportPayload(requestOrigin, heartbeatPayload);
				}

				heartbeatTarget.receiveHeartbeat(getOwnResourceID(), heartbeatListener.retrievePayload(requestOrigin));
			}
		}
	}

最後會通過resourceManagerGateway.heartbeatFromTaskManager 調用到 ResourcManager。

5.4.3 TM 通過RPC回到 RM

JobMaster在接收到rpc請求后調用其heartbeatFromTaskManager方法，會調用taskManagerHeartbeatManager的receiveHeartbeat方法，在這個過程中同樣有兩個處理步驟：

1. 調用對應HeartbeatMonitor的reportHeartbeat方法，cancelTimeout取消註冊時候的超時定時任務，並且註冊下一個超時檢測futureTimeout；
2. 調用TaskManagerHeartbeatListener的reportPayload方法，上報收到TaskExecutor的負載信息

至此一次完成心跳過程已經完成，會根據heartbeatInterval執行下一次心跳。

5.5 超時處理

5.5.1 TaskManager

首先，在HeartbeatMonitorImpl中，如果超時，會調用Listener。

public void run() {
   // The heartbeat has timed out if we're in state running
   if (state.compareAndSet(State.RUNNING, State.TIMEOUT)) {
      heartbeatListener.notifyHeartbeatTimeout(resourceID);
   }
}

這就來到了ResourceManagerHeartbeatListener，會嘗試再次連接RM。

private class ResourceManagerHeartbeatListener implements HeartbeatListener<Void, TaskExecutorHeartbeatPayload> {

   @Override
   public void notifyHeartbeatTimeout(final ResourceID resourceId) {
      validateRunsInMainThread();
      // first check whether the timeout is still valid
      if (establishedResourceManagerConnection != null && establishedResourceManagerConnection.getResourceManagerResourceId().equals(resourceId)) {
         reconnectToResourceManager(new TaskManagerException(
            String.format("The heartbeat of ResourceManager with id %s timed out.", resourceId)));
      } else {
         .....
      }
   }

5.5.2 ResourceManager

RM就直接簡單粗暴，關閉連接。

private class TaskManagerHeartbeatListener implements HeartbeatListener<TaskExecutorHeartbeatPayload, Void> {

   @Override
   public void notifyHeartbeatTimeout(final ResourceID resourceID) {
      validateRunsInMainThread();
      closeTaskManagerConnection(
         resourceID,
         new TimeoutException("The heartbeat of TaskManager with id " + resourceID + "  timed out."));
   }
}  

0x06 解決問題

心跳機制我們講解完了，但是我們最初提到的異常應該如何解決呢？在程序最開始生成環境變量時候，通過設置環境變量的配置即可搞定：

Configuration conf = new Configuration();
conf.setString("heartbeat.timeout", "18000000");
final LocalEnvironment env = ExecutionEnvironment.createLocalEnvironment(conf);

0x07 參考

[flink-001]flink的心跳機制

Flink中心跳機制

flink1.8 心跳服務

你有必要了解一下Flink底層RPC使用的框架和原理

flink RPC(akka)

弄清Flink1.8的遠程過程調用(RPC)

Apache Flink源碼解析 （七）Flink RPC的底層實現

flink源碼閱讀第一篇—入口

flink-on-yarn 基礎架構和啟動流程

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?