Spark - Leader选举 spark

流程 Leader选举模式包括ZOOKEEPER、基于文件系统的、默认空实现以及自定义实现的，选举模式和持久化引擎是对应的。

持久化引擎	Leader选举模式
基于文件系统	MonarchyLeaderAgent
基于ZooKeeper	ZooKeeperLeaderElectionAgent
空实现	MonarchyLeaderAgent

MonarchyLeaderAgent是服务启动的时候，就直接成为Leader节点，而ZooKeeperLeaderElectionAgent是基于ZooKeeper的Leader来选举的。
拉取数据当成为Leader节点的时候，Master就会去持久化引擎里拉取ApplicationInfo、DriverInfo、WorkerInfo等信息（拉取的过程在持久化引擎里说过了），如果这些数据都是空的，就直接变成ALIVE状态，对外提供服务。

文章图片

如果不是空的，那就需要把数据进行还原，这样原ALIVE节点的数据就不会丢失。
恢复Application Master拿到ApplicationInfo数据后，就开始对Application进行注册，把Application的状态改为UNKNOWN，然后发消息给对应的Application，告知他Master地址已经变更，此消息将携带被选举为领导的Master和此Master的masterWebUiUrl属性。

文章图片

Application接收到新的Master的通知，就断开了和旧的Master的连接，并指向新的master，然后发信息给Master说我已经知道了。
Master收到消息后，把Application的状态改为WAITING。
恢复Driver 【Spark - Leader选举】遍历从持久化引擎中读取的DriverInfo，将每个DriverInfo添加到drivers缓存。
恢复Worker Master拿到WorkerInfo数据后，就开始对Worker进行注册，把WorkerInfo的状态改为UNKNOWN，然后发消息给对应的Application，告知他Master地址已经变更，此消息将携带被选举为领导的Master和此Master的masterWebUiUrl属性。

文章图片

Worker接收到新的Master的通知，把Master的相关信息进行了变更，然后发消息给Master，这个消息携带了Worker的ID、这个Worker里的Executor的信息列表。

文章图片

Master收到消息后，对Worker和Executor的信息进行了恢复，并把WorkerInfo的状态改为ALIVE。
调度 Application和Worker恢复的时候，都会先把状态改为UNKNOWN。

文章图片

等Application响应的时候，再把状态改为WAITING或者ALIVE。

文章图片

此时如果状态为UNKNOWN的WorkerInfo或ApplicationInfo说明还没发消息给Master，Master不确定他们是否存活，所以在调度之前就需要移除他们。
对Application、Driver、Worker等信息进行恢复后，就开启了资源调度。资源调度之前已经讲过，这里就不再累述。