溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章給大家分享的是有關Flink容錯機制之作業執行和守護進程的示例分析的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。
Flink 的錯誤恢復機制分為多個級別，即 Execution 級別的 Failover 策略和 ExecutionGraph 級別的 Job Restart 策略。當出現錯誤時，Flink 會先嘗試觸發范圍小的錯誤恢復機制，如果仍處理不了才會升級為更大范圍的錯誤恢復機制，具體可以看下面的序列圖。
當 Task 發生錯誤，TaskManager 會通過 RPC 通知 JobManager，后者將對應 Execution 的狀態轉為 failed 并觸發 Failover 策略。如果符合 Failover 策略，JobManager 會重啟 Execution，否則升級為 ExecutionGraph 的失敗。ExecutionGraph 失敗則進入 failing 的狀態，由 Restart 策略決定其重啟（restarting 狀態）還是異常退出（failed 狀態）。
Task Failover策略目前有三個，分別是：RestartAll、RestartIndividualStrategy 和 RestartPipelinedRegionStrategy。
RestartAll: 重啟全部 Task，是恢復作業一致性的最安全策略，會在其他 Failover 策略失敗時作為保底策略使用。目前是默認的 Task Failover 策略。
RestartPipelinedRegionStrategy: 重啟錯誤 Task 所在 Region 的全部 Task。Task Region 是由 Task 的數據傳輸決定的，有數據傳輸的 Task 會被放在同一個 Region，而不同 Region 之間沒有數據交換。
RestartIndividualStrategy: 恢復單個 Task。因為如果該 Task 沒有包含數據源，這會導致它不能重流數據而導致一部分數據丟失。考慮到至少提供準確一次的投遞語義，這個策略的使用范圍比較有限，只應用于 Task 間沒有數據傳輸的作業。
如果 Task 錯誤最終觸發了 Full Restart，此時 Job Restart 策略將會控制是否需要恢復作業。Flink 提供三種 Job 具體的 Restart Strategy。
FixedDelayRestartStrategy: 允許指定次數內的 Execution 失敗，如果超過該次數則導致 Job 失敗。FixedDelayRestartStrategy 重啟可以設置一定的延遲，以減少頻繁重試對外部系統帶來的負載和不必要的錯誤日志。
FailureRateRestartStrategy: 允許在指定時間窗口內的指定次數內的 Execution 失敗，如果超過這個頻率則導致 Job 失敗。同樣地，FailureRateRestartStrategy 也可以設置一定的重啟延遲。
NoRestartStrategy: 在 Execution 失敗時直接讓 Job 失敗。
Flink on YARN 的部署模式，關鍵的守護進程有 JobManager 和 TaskManager 兩個，其中JobManager的主要職責協調資源和管理作業的執行分別為ResourceManager 和 JobMaster 兩個守護線程承擔，三者之間的關系如下圖所示。
如果 ResouceManager 通過心跳超時檢測到或者通過集群管理器的通知了解到 TaskManager 故障，它會通知對應的 JobMaster 并啟動一個新的 TaskManager 以做代替。注意 ResouceManager 并不關心 Flink 作業的情況，這是 JobMaster 的職責去管理 Flink 作業要做何種反應。
如果 JobMaster 通過 ResouceManager 的通知了解到或者通過心跳超時檢測到 TaskManager 故障，它首先會從自己的 slot pool 中移除該 TaskManager，并將該 TaskManager 上運行的所有 Tasks 標記為失敗，從而觸發 Flink 作業執行的容錯機制以恢復作業。
TaskManager 的狀態已經寫入 checkpoint 并會在重啟后自動恢復，因此不會造成數據不一致的問題。
如果TaskManager通過心跳超時檢測到 ResourceManager 故障，或者收到 zookeeper 的關于ResourceManager失去leadership通知，TaskManager會尋找新的 leader，ResourceManager 并將自己重啟注冊到其上，期間并不會中斷 Task的執行。
如果JobMaster通過心跳超時檢測到ResourceManager故障，或者收到 zookeeper 的關于 ResourceManager 失去 leadership 通知，JobMaster 同樣會等待新的 ResourceManager 變成 leader，然后重新請求所有的TaskManager。考慮到 TaskManager 也可能成功恢復，這樣的話 JobMaster 新請求的 TaskManager 會在空閑一段時間后被釋放。
ResourceManager上保持了很多狀態信息，包括活躍的 container、可用的 TaskManager、TaskManager 和 JobMaster 的映射關系等等信息，不過這些信息并不是 ground truth，可以從與 JobMaster 及 TaskManager 的狀態同步中再重新獲得，所以這些信息并不需要持久化。
如果 TaskManager 通過心跳超時檢測到 JobMaster 故障，或者收到 zookeeper 的關于 JobMaster 失去 leadership 通知，TaskManager 會觸發自己的錯誤恢復，然后等待新的 JobMaster。如果新的 JobMaster 在一定時間后仍未出現，TaskManager 會將其 slot 標記為空閑并告知 ResourceManager。
如果 ResourceManager 通過心跳超時檢測到 JobMaster 故障，或者收到 zookeeper 的關于 JobMaster 失去 leadership 通知，ResourceManager 會將其告知 TaskManager，其他不作處理。
JobMaster 保存了很多對作業執行至關重要的狀態，其中 JobGraph 和用戶代碼會重新從 HDFS 等持久化存儲中獲取，checkpoint 信息會從 zookeeper 獲得，Task 的執行信息可以不恢復因為整個作業會重新調度，而持有的 slot 則從 ResourceManager 的 TaskManager 的同步信息中恢復。
Flink on YARN 部署模式下，因為 JobMaster 和 ResourceManager 都在 JobManager 進程內，如果JobManager 進程出問題，通常是 JobMaster 和 ResourceManager 并發故障，那么 TaskManager 會按以下步驟處理：
按照普通的 JobMaster 故障處理。
在一段時間內不斷嘗試將 slot 提供給新的 JobMaster。
不斷嘗試將自己注冊到 ResourceManager 上。
值得注意的是，新 JobManager 的拉起是依靠 YARN 的 Application attempt 重試機制來自動完成的，而根據 Flink 配置的 YARN Application：keep-containers-across-application-attempts行為，TaskManager 不會被清理，因此可以重新注冊到新啟動的 Flink ResourceManager 和 JobMaster 中。
Flink 容錯機制確保了 Flink 的可靠性和持久性，具體來說它包括作業執行的容錯和守護進程的容錯兩個方面。在作業執行容錯方面，Flink 提供 Task 級別的 Failover 策略和 Job 級別的 Restart 策略來進行故障情況下的自動重試。在守護進程的容錯方面，在on YARN 模式下，Flink 通過內部組件的心跳和 YARN 的監控進行故障檢測。TaskManager 的故障會通過申請新的 TaskManager 并重啟 Task 或 Job 來恢復，JobManager 的故障會通過集群管理器的自動拉起新 JobManager 和 TaskManager 的重新注冊到新 leader JobManager 來恢復。
感謝各位的閱讀！關于“Flink容錯機制之作業執行和守護進程的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
