Master作為Spark Standalone模式中的核心，如果Master出現異常，則整個叢集的執行情況和資源都無法進行管理，整個叢集將處於無法工作的狀態。
Spark在設計的時候考慮到了這種情況，Master可以起一個或者多個Standby Master，當Master出現異常的時候，Standy Master 將根據一定規則確定一個接管Master。在Standalone模式中Spark支援下面集中策略（spark-env.sh配置spark.deploy.recoveryMode）：

• ZOOKEEPER：叢集的元資料持久化到Zookeeper中，當Master出現異常後，Zookeeper會通過選舉機制選出新的Master，新的Master接管時需要從Zookeeper中獲取之前叢集的持久化資訊，並根據這些資訊恢復叢集狀態。
• FILESYSTEM：叢集的元資料持久化到本地的檔案系統中，當Master出現問題後只要在該機器上重新啟動Master，重啟後的Master會根據之前的持久化資訊恢復叢集狀態。
• CUSTOM：自定義恢復方式，對StandaloneRecoveryModeFactory抽象類進行實現並把該類配置到系統中，當Master出現異常時，根據自定義方式恢復叢集。
• NONE：不持久化叢集的元資料，Master出現異常時，新啟動的Master不進行恢復叢集狀態，而是直接接管叢集。

Master異常切換過程圖



Master切到StandbyMaster過程

1. 持久化引擎去讀取持久化的storedApps，storedDrivers，storedWorkers。
2. 判斷其中如果有一個是非空的，開始恢復叢集。
3. 將持久化的Application，Driver，Worker的資訊重新進行註冊，註冊到Master內部的快取結構中。
4. 將App和Worker的狀態都修改為UNKNNOW然後向App對應的driver和Worker傳送Standby Master的地址。
5. Master接收到工作中的Driver、Worker傳送來的響應訊息，使用completeRecovery()方法對沒有響應的Driver、Worker進行處理，過濾掉他們的資訊。
6. 呼叫Master的schedule()方法，排程正在等待資源的App和Driver。

相關原始碼

持久化引擎去讀取持久化的storedApps，storedDrivers，storedWorkers，如果其中有一個是非空的，則去開始恢復叢集。



使用completeRecovery()方法對沒有響應的Driver、Worker進行處理，過濾掉他們的資訊。



遍歷移除所有worker


移除Driver