分布式高可用集群安装是Standalone集群，这里会有两个master，一个是ALIVE，一个是STANDBY。ALIVE节点是提供服务的，STANDBY是备胎，当ALIVE节点挂了以后，STANDBY会顶替成为新的ALIVE。
我们知道Worker和Application等数据，都会存在内存中，但只是存在内存中，当旧的ALIVE节点挂了以后，数据就丢了，新的ALIVE节点接替整个集群的管理工作时，没有能力从故障中恢复整个集群的状态信息，进而恢复对集群资源的管理和分配。
所以就需要一个持久化引擎，把集群的Worker、Driver和Application的信息持久化，当新的ALIVE节点接替整个集群后，就可以从持久化拿数据对集群状态进行恢复。
持久化引擎有四个，包括用于用于单元测试的、空实现的（也就是没有持久化）、基于文件系统的持久化引擎、基于ZooKeeper的持久化引擎。
基于文件系统的持久化引擎
FileSystemPersistenceEngine，即基于文件系统的持久化引擎。由于Master可能在不同的服务器中，所以这里要求文件系统是分布式的。
我们以对WorkerInfo的操作为例。
当我们想对worker_1进行持久化的时候，FileSystemPersistenceEngine就会创建一个叫做worker_1的文件，然后打开文件输出流，并对数据进行序列化后写入磁盘的。
当我们想对worker_2，worker_3进行持久化的时候，流程和上面一样，这样就有了三个文件，分别为worker_1，worker_2，worker_3。
当我们想对worker_3进行移除持久化的时候，其实就是删除worker_3的文件。
当我们想读取持久化里的信息的时候，就会把worker_1，worker_2文件里的数据读取出来，并进行反序列化（实际还包括app_和driver_，这里略）。
基于ZooKeeper的持久化引擎
ZooKeeperPersistenceEngine，即基于ZooKeeper的持久化引擎。
我们还是以对WorkerInfo的操作为例。
当我们想对worker_1进行持久化的时候，ZooKeeperPersistenceEngine就会在/spark/master_status下面创建worker_1的持久化节点（假装下面的是树形结构）。
当我们想对worker_2，worker_3进行持久化的时候，流程和上面一样，这样就有了三个节点，分别为worker_1，worker_2，worker_3。
当我们想对worker_3进行移除持久化的时候，其实就是删除worker_3的节点。
当我们想读取持久化里的信息的时候，就会把worker_1，worker_2节点里的数据读取出来，并进行反序列化（实际上还包括/spark/master_status节点下的其他数据）
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。