Flink JobManager的HA原理分析

文章目錄

• 前言
• JobManager的HA切換通知
• 利用Zookeeper的領導選舉與消息通知
• 引用

前言

---

在中心式管理的系統裏，主節點若是隻是單獨服務部署的話，或多或少都會存在單點瓶頸（SPOF）問題。因此咱們說如今的分佈式系統都要求具備高可用性（High Availability）的實現。一樣的，在早期Flink runtime層面，JobManager也沒有徹底作到HA的實現，這使得運行時的任務存在失敗沒法及時恢復的風險。不過在最新的代碼裏，Flink社區已經完善了這塊的實現。本文，筆者簡單來聊聊Flink JobManager的HA的原理。

JobManager的HA切換通知

---

筆者在對比了HDFS的HA實現和Flink JobManager的實現後，二者在部分實現上仍是存在差別的，並非說只是主從切換這樣簡單的過程。如下是幾區分點：

HDFS的HA切換，主要保證的是數據請求處理的正常服務。而Flink要讓全部的失敗任務可以快速恢復。咱們能夠從更高層面來理解這樣的差別：一個是存儲系統的HA實現，一個是計算框架的HA實現。

因此FlinkJobMnager在服務發生切換的時候要及時地通知外界事物。這裏的外界事物包括：

• JobManager管理的TaskManager
• 在跑的全部Job
• 在請求的JobClient客戶端

而後這些Job，JobClient收到新的leader信息後，可以主動從新鏈接新的JobManager地址，保證任務的正常執行。那麼這裏面的通知過程是如何的呢，咱們繼續往下看。

利用Zookeeper的領導選舉與消息通知

---

在這裏，Flink內部定義了2類服務來作HA時的領導選舉和消息提取（通知）：

• LeaderElectionService
• LeaderRetrievalService

在LeaderElectionService服務的實現中，是採用Apache Curator框架中的LeaderLatch來作領導選舉的。而後新的領導被選舉出來後，LeaderRetrievalService服務會第一時間獲得通知，而後提取出最新leader地址，並通知到監聽接口（LeaderRetrievalListener）。這裏的通知對象就包含有上面提到的客戶端等。
因此在Flink runtime層面，會有不少的LeaderRetrievalListener實現類，以下圖所示：

更多實現細節，能夠關注Flink-2287.

引用

---

[1].https://cwiki.apache.org/confluence/display/FLINK/JobManager+High+Availability
[2].https://issues.apache.org/jira/browse/FLINK-2287