Spark Standalone集群是Master-Slaves架构的集群模式，和大部分的Master-Slaves结构集群一样，存在着Master单点故障的问题。如何解决这个单点故障的问题，Spark提供了两种方案：

• 基于文件系统的单点恢复(Single-Node Recovery with Local File System)
• 基于zookeeper的Standby Masters(Standby Masters with ZooKeeper)

ZooKeeper提供了一个Leader Election机制，利用这个机制可以保证虽然集群存在多个Master，但是只有一个是Active的，其他的都是Standby。当Active的Master出现故障时，另外的一个Standby Master会被选举出来。由于集群的信息，包括Worker， Driver和Application的信息都已经持久化到文件系统，因此在切换的过程中只会影响新Job的提交，对于正在进行的Job没有任何的影响。加入ZooKeeper的集群整体架构如下图所示。

1.基于文件系统的单点恢复
主要用于开发或测试环境。当spark提供目录保存spark Application和worker的注册信息，并将他们的恢复状态写入该目录中，这时，一旦Master发生故障，就可以通过重新启动Master进程（sbin/start-master.sh），恢复已运行的spark Application和worker的注册信息。
基于文件系统的单点恢复，主要是在spark-env里对SPARK_DAEMON_JAVA_OPTS设置：

可以考虑使用NFS的共享目录来保存Spark恢复状态。 

1.1配置

 vi conf/spark-env.sh

export SPARK_DAEMON_JAVA_OPTS="-Dspark.deploy.recoveryMode=FILESYSTEM -Dspark.deploy.recoveryDirectory=/nfs/spark/recovery"

2.Standby Masters with ZooKeeper

用于生产模式。其基本原理是通过zookeeper来选举一个Master，其他的Master处于Standby状态。

将Standalone集群连接到同一个ZooKeeper实例并启动多个Master，利用zookeeper提供的选举和状态保存功能，可以使一个Master被选举，而其他Master处于Standby状态。如果现任Master死去，另一个Master会通过选举产生，并恢复到旧的Master状态，然后恢复调度。整个恢复过程可能要1-2分钟。

注意：

• 这个过程只会影响新Application的调度，对于在故障期间已经运行的 application不会受到影响。
• 因为涉及到多个Master，所以对于应用程序的提交就有了一点变化，因为应用程序需要知道当前的Master的IP地址和端口。这种HA方案处理这种情况很简单，只需要在SparkContext指向一个Master列表就可以了，如spark://host1:port1,host2:port2,host3:port3，应用程序会轮询列表。

该HA方案使用起来很简单，首先启动一个ZooKeeper集群，然后在不同节点上启动Master，注意这些节点需要具有相同的zookeeper配置（ZooKeeper URL 和目录）。

 Master可以在任何时候添加或移除。如果发生故障切换，新的Master将联系所有以前注册的Application和Worker告知Master的改变。

注意：不能将Master定义在conf/spark-env.sh里了，而是直接在Application中定义。涉及的参数是 export SPARK_MASTER_IP=bigdata001，这项不配置或者为空。否则，无法启动多个master。

2.1 配置

vi conf/spark-env.sh

export SPARK_DAEMON_JAVA_OPTS="-Dspark.deploy.recoveryMode=ZOOKEEPER "
export SPARK_DAEMON_JAVA_OPTS="${SPARK_DAEMON_JAVA_OPTS} -Dspark.deploy.zookeeper.url=zk_server1:2181,zk_server_2:2181"