預設情況下，Standalone的Spark叢集是Master-Slaves架構的叢集模式，由一臺master來排程資源，這就和大部分的Master-Slaves結構叢集一樣，存在著Master單點故障的問題。如何解決這個單點故障的問題呢？Spark提供了兩種方案：基於檔案系統的單點恢復(Single-Node Recovery with Local Filesystem)和基於zookeeper的Standby Masters(Standby Masters with ZooKeeper)。其中ZooKeeper是生產環境下的最佳選擇。

用ZooKeeper的備用master ZooKeeper提供了一個Leader Election機制，利用這個機制你可以在叢集中開啟多個master並使它們都註冊到ZooKeeper例項，ZooKeeper會管理使其中只有一個是Active的，其他的都是Standby的，Active狀態的master可以提供服務，standby狀態的則不可以。ZooKeeper儲存了叢集的狀態資訊，該資訊包括所有的Worker，Driver 和Application。當Active的Master出現故障時，ZooKeeper會從其他standby的master中選舉出一臺，然後該新選舉出來的master會恢復掛掉了的master的狀態資訊，之後該Master就可以正常提供排程服務。整個恢復過程只需要1到2分鐘。需要注意的是，在這1到2分鐘內，只會影響新程式的提交，那些在master崩潰時已經執行在叢集中的程式並不會受影響。
配置 為了開啟這個恢復模式，你可以用下面的屬性在spark-env中設定SPARK_DAEMON_JAVA_OPTS。

System property	Meaning
spark.deploy.recoveryMode	設定ZOOKEEPER去啟動備用master模式（預設為none）
spark.deploy.zookeeper.url	zookeeper叢集url(如192.168.1.100:2181,192.168.1.101:2181)
spark.deploy.zookeeper.dir	zookeeper儲存恢復狀態的目錄（預設是/spark）

可能的陷阱：如果你在叢集中有多個masters，但是沒有用zookeeper正確的配置這些masters，這些masters不會發現彼此，會認為它們都是leaders。這將會造成一個不健康的叢集狀態（因為所有的master都會獨立的排程）。 列如：

export SPARK_DAEMON_JAVA_OPTS="-Dspark.deploy.recoveryMode=ZOOKEEPER -Dspark.deploy.zookeeper.url=HDP245:2181,HDP246:2181,HDP247:2181 -Dspark.deploy.zookeeper.dir=/spark"
 

在另一個節點上，啟動新的master

用本地檔案系統做單節點恢復

zookeeper是生產環境下最好的選擇，但是如果你想在master死掉後重啟它，FILESYSTEM模式可以解決。當應用程式和worker註冊，它們擁有足夠的狀態寫入提供的目錄，以至於在重啟master 程序時它們能夠恢復。
配置 為了開啟這個恢復模式，你可以用下面的屬性在spark-env中設定SPARK_DAEMON_JAVA_OPTS。

System property	Meaning
spark.deploy.recoveryMode	設定為FILESYSTEM開啟單節點恢復模式（預設為none）
spark.deploy.recoveryDirectory	用來恢復狀態的目錄