0.摘要
Zab是我们为ZooKeeper协调服务设计的崩溃-恢复原子广播算法.ZooKeeper实现了主备模式:主进程执行客户端写请求,然后用Zab协议传播相应的状态变化增量给备进程.由于一个状态变化增量必须依基于先前产生的状态变化序列,Zab必须确保先传输被基于的,然后传输此增量.因为主进程可能崩溃，Zab必须允许主进程崩溃且而自己正常工作.
使用ZooKeeper的应用要求高性能、一致性，而且在一个时刻允许多个未完成写请求存在是很重要的。
(以下叙述原因A、B)
(A) Zab确保：1、至多有一个主进程可以广播状态变化序列并并使这序列进入状态机；2、在选出新主进程时，有一个同步阶段。
从而(1和2)使Zab能支持多个未完成状态变化。
在同步阶段完成前，新主进程不能广播新状态变化。
(B) 再有，Zab给状态变化以id，从而使进程轻易地发现缺失了一些变化。这是有效恢复的关键。
目前，在生产环境下的试验表明 我们的设计下的实现 能 满足我们的应用所需性能。
我们实现的Zab能够达到每秒数万次广播，对于像可扩展web应用的高压力系统这是足够的。
索引词–容错，分布式算法，主从，异步一致性，原子广播。
I.介绍
原子广播是一个通用原语在分布式系统中，而ZooKeeper是使用了原子广播的应用。
(primitive:原始人:原子性:[多条指令组成一个动作,该动作只能做完或不做,不能做一部分]:原语)
ZooKeeper是一个被在生产Web系统中的高可用协调服务用，例如雅虎爬虫用了三年。
此类应用程序经常包含大量进程，并依靠ZooKeeper来执行重要的协调任务，比如可靠地存储配置、保持运行进程的状态。
由于大量应用对ZooKeeper的依赖，(ZooKeeper)协调服务必须能屏蔽失效并从失效中恢复。 [1]
(server:服务器;process:进程. 这篇文章里二者意思一样.可以想象作者假定了每个服务器上一个zookeeper进程)
ZooKeeper 是个复制服务，为前进(为执行写请求序列)它需要多数派服务器没有崩溃。
(replicated:复制; replica:副本。二者含义一样。复制多次产生多个副本。)
用崩溃-恢复协议 [2], [3], [4]，崩溃的服务器能恢复，并重新加入。
ZooKeeper用主从模式 [5], [6], [7]来维持各进程的副本的一致性。
用ZooKeeper，所有来自客户端的(写)请求，由主进程：1、接收；2、执行；3、以事务的形式，用Zab协议，给各个从进程单向传播增量状态变化(序列)。 (Zab:ZooKeeper原子广播)。
当主进程崩溃，(其他)所有进程执行恢复协议 来 ： 1、在恢复正常操作前达成一致；2、选出一个新主进程来广播状态变化(序列)。
(正常操作 : 能正常接收来自客户端的写请求)
一个进程得到多数派进程的支持才能变成主进程。
(majority、quorum(二者含义相同)：多数派：[集群内当时全部机器数被各个机器知道，大于此数二分之一为多数派。] 全部机器自然包括死的、活的)
由于进程会崩溃并恢复，不同的时刻会可能有不同的主进程，当然同一个进程可能做了好几次主进程。
为了唯一确认不同时段内的不同主进程，我们给每个选出的主进程一个实例值。 一个给定的实例值至多对应一个进程。
注意，实例的概念和组播的view[8]部分相同，但有一些关键差异。
组播：1、一个指定的view中的所有进程能广播；2、当任意一个进程加入或离开时候，配置发生变化。
Zab：1、只有当主进程崩溃或失去了多数派的支持时候，所有进程用一个新的view（或主实例）。
(组播的2和Zab的1有类似之处，组播的1和Zab不同)