Zookeeper之reliable

最近在负责zookeeper的跨机房同步方案，所以又把zookeeper深入研究了一下，总结一些结果在这里。至于zookeeper的跨机房同步方案先不在这里说，打算另外单写。

这里我主要想说一个问题，zookeeper是什么？

zookeeper的网站上是这要描述zookeeper的：Apache ZooKeeper is an effort to develop and maintain an open-source server which enables highly reliable distributed coordination.

这里有1个关键词，reliable。这个词充分说明zookeeper是一个什么系统。不过还是太抽象了，我们先分析一些具体内容，最后在分析完之后，再回来扣这个主题。

这里先说一下zookeeper的一些关键概念：ensemble, leader，follower，quorum (major quorum)，voter，observer。

zookeeper是一个分布式的集群系统(ensemble)，集群中的一台机器是leader，其他的机器都是follower，所有的写请求都由leader来处理，leader接到写请求后，会要求所有的follower都接受这个写请求，follower完成写请求后会给leader发送ack，leader收到quorum个follower的ack后，则这次写请求成功。quorum是个数字，这个数字表示一个阈值，超过这个阈值，就表示成功。major quorum是其中一种quorum，表示有大多数就是成功，比如3个中的2个，5个中的3个，7个中的4个等。zookeeper也有其他quorum，比如weight和group。leader，follower都是voter，voter是参与zab协议的节点。observer是不参与zab协议的节点，它只接受leader发送过来的写请求，不会给leader回复ack。

上面提到了zab协议，它是一个一致性协议，它包括2部分。上面刚刚描述的写入过程是它的第二部分，也即是一个简化的2阶段提交。它的第一部分是一个选主过程，配合协议的第二部分，协议能保证选出一个数据最新的节点为leader。有了leader之后，因为所有的写入都是leader的来出来的，也即对于写入来说已经不是一个分布式系统了，所以可以有一些非分布式系统的一些特性，比如，保证严格递增的sequence这个特性，zookeeper可以用来实现leader选举，虽然zookeeper本身的leader选举是靠zab这样的分布式一致性协议来实现的，但是它暴露出去的用来实现leader选举的功能，不是通过zab实现的，是通过”单点”来实现的。

上面用了”单点”这个词，但zookeeper绝对不是一个存在单点的系统，从上面的分析来看，quorum这个特性让zookeeper能够容忍(n-1)/2个节点的loss，在损失了(n-1)/2个节点后，zookeeper仍然能过选举出一个数据最新的leader，并且保证写入操作达到quorum的要求。所以说zookeeper是能够保证数据在灾难的情况下不对，并且保证在灾难的情况下服务的可用性。也就是说zookeeper保证数据的可靠性和服务高可用性。

在zab协议的第二部分中，leader在收到quorum个ack就返回成功了，所以应用这时是有可能读到就数据的，所以zookeeper不是一个”强一致性”系统，是”最终一致性系统”，这么说可能不正确，但是如果我们放在跨机房同步的场景下，特别是使用observer作为数据的同步方式，那么这个”最终一致性”的特性就非常明显了。

所以说zookeeper的核心是zab这个一致性协议，但是zookeeper并不是一个”强一致性”系统，数据的一致性也不是zookeeper的核心特性，这也就是zookeeper的一句话简介里，只出现了reliable这个词，没有出现consistent这个词。reliable充分说明了zookeeper的核心特性，也就是它保证的是数据不丢失的可靠性，和服务的高可用性，这2个特性都可以用reliable来概括。