spark技术内幕：master基于zookeeper的high availability（ha）源码实现 详细阐述了使用zk实现的master的ha，那么master是如何快速故障恢复的呢？
处于standby状态的master在接收到org.apache.spark.deploy.master.zookeeperleaderelectionagent发送的electedleader消息后，就开始通过zk中保存的application，driver和worker的元数据信息进行故障恢复了，它的状态也从recoverystate.standby变为recoverystate.recovering了。当然了，如果没有任何需要恢复的数据，master的状态就直接变为recoverystate.alive，开始对外服务了。
一方面master通过
恢复application，driver和worker的状态，一方面通过
在60s后主动向自己发送completerecovery的消息，开始恢复数据完成后的操作。
首先看一下如何通过zookeeperleaderelectionagent提供的接口恢复数据。
获取了原来的master维护的application，driver和worker的列表后，当前的master通过beginrecovery来恢复它们的状态。
恢复application的步骤：
置待恢复的application的状态为unknown，向appclient发送masterchanged的消息
appclient收到后改变其保存的master的信息，包括url和master actor的信息，回复masterchangeacknowledged(appid)
master收到后通过appid后将application的状态置为waiting
检查如果所有的worker和application的状态都不是unknown，那么恢复结束，调用completerecovery()
恢复worker的步骤：
重新注册worker（实际上是更新master本地维护的数据结构），置状态为unknown
向worker发送masterchanged的消息
worker收到消息后，向master回复 消息workerschedulerstateresponse，并通过该消息上报executor和driver的信息。
master收到消息后，会置该worker的状态为alive，并且会检查该worker上报的信息是否与自己从zk中获取的数据一致，包括executor和driver。一致的executor和driver将被恢复。对于driver，其状态被置为running。
beginrecovery的源码实现：
通过下面的流程图可以更加清晰的理解这个过程：
如何判断恢复是否结束？
在上面介绍application和worker的恢复时，提到了每次收到他们的回应，都要检查是否当前所有的worker和application的状态都不为unknown，如果是，那么恢复结束，调用completerecovery()。这个机制并不能完全起作用，如果有一个worker恰好也是宕机了，那么该worker的状态会一直是unknown，那么会导致上述策略一直不会起作用。这时候第二个判断恢复结束的标准就其作用了：超时机制，选择是设定了60s得超时，在60s后，不管是否有worker或者appclient未返回相应，都会强制标记当前的恢复结束。对于那些状态仍然是unknown的app和worker，master会丢弃这些数据。具体实现如下：
但是对于一个拥有几千个节点的集群来说，60s设置的是否合理？毕竟现在没有使用standalone模式部署几千个节点的吧？因此硬编码60s看上去也十分合理，毕竟都是逻辑很简单的调用，如果一些节点60s没有返回，那么下线这部分机器也是合理的。
通过设置spark.worker.timeout，可以自定义超时时间。