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过程

持久化引擎去读取持久化的storedApps，storedDrivers，storedWorkers。
判断其中如果有一个是非空的，开始恢复集群。
将持久化的Application，Driver，Worker的信息重新进行注册，注册到Master内部的缓存结构中。
将App和Worker的状态都修改为UNKNNOW然后向App对应的driver和Worker发送Standby Master的地址。
Master接收到工作中的Driver、Worker发送来的响应消息，使用completeRecovery()方法对没有响应的Driver、Worker进行处理，过滤掉他们的信息。
调用Master的schedule()方法，调度正在等待资源的App和Driver。