版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/qq_34993631/article/details/86493860
主备切换发生的场景就是，Active的Master宕掉之后StandBy的Master担任主节点时发生的一系列流程。说白了也就是一个Master恢复的过程。具体的流程如下：
- 首先来说Spark的主备切换可以基于两种机制。一种是基于文件系统的，一种是基于Zookeeper的。基于文件系统的切换要通过手动来完成，基于Zookeeper的系统的切换是自动进行的。
- StandBy的Master使用持久化引擎（比如ZookeeperPersisitenceEngine）去读取storedApps，storedDriver，storedWorks。如果他们三个钟有一个不为空那么就继续走下面的流程。
- 将持久化的Application，Driver，Worker的信息进行再次注册，注册到缓存结构中（本质上是一个Map集合）。
- 将Application与Worker的状态修改为UNKOWN。然后Master向Application的Driver以及对应的Worker发送自己的地址。
- 这些Application与Driver在收到地址之后会发送响应给Master。
- 这时就会发送Master就会调用自己的completeRecovery()方法来过滤掉没有给自己发送响应的Driver与Worker。
- 最后Master就会调用自己的schedule()方法来对正在等待队列中等待的Driver与Application进行调度。
具体的流程图如下图所示：
CompleteRecovery()方法介绍
这个方法的作用主要就是删除那些不合格的Application与Worker。主要调用了removeWorker()与finashApplication()两个方法。在删除之前首先将所有待恢复的Woker与Application的状态修改为UNKOWN。然后Master会更新他们的状态。最后再去删除没有响应的组件。
removeWorker，在driver层面就会首先去判断Driver的Supervise（是否被Master监控）的配置项。如果Driver配置了这个选项的话那么Master就会将它设置成Relunching并且将这个Driver加入到等待队列等待调用。如果没有配置Supervise那么就会将会将这个Driver的状态设置成Finished放入销毁队列等待销毁。在Woker层面直接将Woker的相应信息从Master中的Map缓存中移除。
finashApplication在Executor层面首先会遍历所有的Executor然后逐个将他们从内存移除。
最后当这些组件从内存中移除之后同时也会将他们从持久化的文件中（日志）删除相应的信息。从这里我们可以看出组件删除的路线是缓存-->相关组件的内存-->文件。