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