为了应对master奔溃，我们需要有备用的master。当主master奔溃时，备用的master能接管主master的工作。然而，当涉及到master请求时， 故障转移就没有那么简单了。新的主master必须恢复当老的master奔溃时系统的状态。为了恢复master的状态，我们不能依赖拉取来自错误的master的状态，因为它已经奔溃了；我们必须从其他的地方来获取，这个地方就是Zookeeper。

恢复状态不是唯一重要的问题。假设这样一个情景：主master正常运行，但是备份master怀疑主master奔溃了。这种错误的怀疑是可能发生的，比如主master的负载非常高导致它的消息被延迟了。备份master会执行所有必要的步骤去接管主master的角色，最终可能会导致它开始执行主master的角色，变成了第二个主master。更糟糕的是，如果某些worker由于网络分区的原因无法和主master进行通信，它们最终可能会追随第二个主master。这种场景导致了一个被称之为“脑裂”(split-brain)的问题:系统内两个或者多个部分独立的发展，导致了行为的不一致性。作为接下来应对master失败的部分方案，避免“脑裂“场景的发生是至关重要的。