为什么引入新的协议（对比）

这个时候paxos总是被吊出来

我们知晓目前有一个比较好的候选算法：paxos。它可以提供一系列重要的特性，比如

• 不管多少节点失败都可以保证安全性。（即不产生坏的错误结果）
• 允许 程序崩溃和恢复
• 三次通信进行一次提交

但是，对用对paxos研究，我们发现可以简化paxos协议以获得更高的吞吐。

首先，paxos是允许消息丢失和重排的。但是，如果我们采用TCP通信的话，我们就可以保证所有交付的消息都是FIFO。这样我们就可以保证同时多个提案的因果有序。但是paxos因为没有FIFO实现，所以也就不能保证因果有序。

其次，在paxos中，为了减少竞争，我们一般只有一个提议者。这个提议者就是leader。当paxos从leader崩溃恢复之后，新的leader需要确保所有部门交付的消息完全交付。然后按照之前的提案编号进行提案。因为多个leader可以给同一个事务（实例）进行提案，就会出现以下2个问题：

• 提案可能会冲突。 paxos利用majority机制解决这个问题
• 针对具体的实例，或者事务，我们并不知道其是否已经提交了。

那么ZAB为了避免以上的问题，他保证针对一个消息提案只能有一个编号，这就简化了选票和恢复的过程。在paxos中，如果一个服务认为自己是leader，那么他就会用一个更高的选票编号去获取leader地位。但是ZAB中，新的leader是需要在得到其他大多数服务认可之后才可以做leader的。

在ZAB中我们使用固定的计数器，由leader维护，并且leader负责跟其他follower服务同步。但是这个固定计数器不能再所有服务上启用，以达到负载均衡。但是我们还是采用了这种方法，因为以下的原因：

• 客服端可以连接到任意机器上，并且这些机器可以响应read请求，从某种意义上来说，这也是负载均衡。

• 涉及到的服务器数量是比较小的。换句话说 固定序列号协议 交流不会产生很大影响。所以通信上不会成为该协议的瓶颈。（ps.这块理解不太透彻，附上原文。）

  The number of servers involved is small. This means that the network communication overhead does not become the bottleneck that can a↵ect fixed sequencer protocols;

• 没有必要开发更复杂的协议，因为 simple is best.

使用一个leader要求我们需要处理 leader故障以保证服务可用。这里采用的是 一些与视图变化相关的技术，比如Keidar and Dolev协议[10]。但是与其不同的是， zab不使用群组通信。并且服务的加入与离开，不会导致视图变更。除非是leader崩溃。