分布式高可用集群装置是 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 节点下的其余数据）