CAP 和 Zookeeper

引言

很长一段时间，我执着于将Zookeeper归类为CP系统还是AP系统。对于Zookeeper的C或者A，我感到迷惑，网络上有很多文章都将Zookeeper 标注为一个 CP 系统，但是我不那么认为，因为 Zookeeper 采用投票机制，所以它的一致性并不强烈；同时很多文章中说在Zookeeper 投票期间是丧失了可用性的，我同样也有一些疑问。

怎么理解 CAP

2000年7月，来自加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC（Principles of Distributed Computing）会议上，首次提出了著名的 CAP 猜想（Towards Robust Distributed Systems）。2年后，来自麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 Brewer 教授 CAP 猜想的可行性。从此，CAP 理论正式在学术上成为了分布式计算领域的公认定理，并深深地影响了分布式计算的发展。
CAP 理论告诉我们：

It is impossible for a web service to provide the three following guarantees : Consistency, Availability and Partition-tolerance.

一个分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容错性（P：Partition tolerance）这三个基本要求，最多只能同时满足其中的两项。

分区容错性

要理解分区容错性，先来看CAP定理中对P的定义：

In order to model partition tolerance, the network will be allowed to lose arbitrarily many messages sent from one node to another.

意思是，具有分区容错性的网络要允许部分信息的丢失，而不能影响使用。那么允许信息丢失的情况会有很多种，比如网络异常，某个节点宕机，各种客观的原因使得Partition tolerance 成为一个必选项。

可用性

For a distributed system to be continuously available, every request received by a non-failing node in the system must result in a response.

定义：系统中非故障节点接收到的每个请求都必须要有响应。
在某些方面，这是对可用性的弱定义：它并没有限制程序的运行时间，因此允许无限计算。但是，当需要满足分区容错性的需求时，就必须对时间有一个要求，所以，代入到CAP的场景中时，则可以这样来定义：在有限的时间，返回确定的结果。

一致性

Under this consistency guarantee, there must exist a total order on all operations such that each operation looks as if it were completed at a single instant.

将一致性的概念表达的最容易理解的方法是将其作为原子操作看待，一致性是现在大多数服务所期望的条件。这里的一致性是一种非常强的一致性，或者说是线性化的一致性。在这个一致性保证下，所有操作都必须有一个总的顺序，这样每个操作看起来就像是在一个瞬间完成的。这相当于要求分布式共享内存的请求像在单个节点上执行一样，一次只响应一个操作。

理解

当2002年 CAP 理论一经证明之后，就引起了业界大范围的讨论，甚至作为衡量一个分布式服务特性的依据。那么在分布式系统中，除了必选项P之外，C和A是不是只能二选一呢？
显然并不是的，CAP 中的一致性是一种强一致性，要求多节点组成的集群服务要能像单节点一样运作，操作具备原子性，数据在时间、时序上都有要求。这对于分布式系统来说，是很难达到的，或者说，代价是很高的。
如果不考虑响应时间的话，或者说，响应时间可以无限大的话，那么一致性和可用性是都可以满足的，而加上响应时间的考虑，有可能在保证一致性的同时，响应时间就变得特别久，而变得不可用。那么，这个响应时间是否可用的临界点又是多少呢？这是个模糊的问题，当确定1s内响应是可用的时候，那么1.01s就是不可用的吗？并没有那么严格，所以，这里就有了弱可用性。
同样的，对于强一致性的条件来说，但如果放宽那些要求，也可以衍生出其他的一致性类型：

• 顺序一致性
• 最终一致性

上面引出弱可用性和弱一致性，只是为了说明，在更多的情况下，还是采用折中的方式，使服务满足弱一些的一致性，同时还能满足弱可用性。也因此，之后会有 BASE 理论的诞生。
说了那么多，对于现代分布式系统来说，使用 CAP来描述一个分布式服务，是不太准确的。大多数服务本身拥有更多的特性，更丰富的功能来维持服务的运行，而不只是简单的说可用性，还是一致性。有篇文章很棒：Please stop calling databases CP or AP。

Zookeeper

那ZooKeeper又怎么样呢？它用了 ZAB 协议，所以人们一般认为它明确的选择了一致性而放弃了可用性（也就是CP系统）。
但是在ZooKeeper的文档里面，很清楚的说了ZooKeeper 不能保证可线性化的读操作：

ZooKeeper does not guarantee that at every instance in time, two different clients will have identical views of ZooKeeper data.

每个连接到某个节点的客户端在读数据的时候，即使别的节点有更新的数据，也只能看到那个节点本地的数据。这样读操作就比需要收集quorum或者访问leader要更快，但这也说明ZooKeeper默认不满足CAP的一致性定义。
那 ZooKeeper 的可用性呢？他要求达到大多数quorum，来达到共识，才能处理一个写操作。如果你有网络分区，一边有大多数节点，一边有少部分节点。那么拥有大多数节点的分区还可以继续工作，但是少部分节点的分区就算节点们都正常工作着，还是不能处理写操作。所以ZooKeeper 的写操作在网络分区的情况下，是不满足CAP的可用性（即使拥有大多数节点的分区还是可以处理写操作的）。
有意思的是，ZooKeeper 3.4.0 加入了一个只读的模式。在这个模式下，少部分节点的分区还可以继续处理读操作 – 不需要投票! 这个读操作是满足CAP可用性的。所以ZooKeeper默认设置既不是一致的(CP)也不是可用的(AP)，只是"P"。但是你有选择通过用sync命令来让它成为CP。并且在正确的设置下，读操作(不包括写)其实是CAP可用的。
所以，为什么还要纠结 Zookeeper 到底是 CP 还是 AP 呢？什么都不是，也可以什么都是，whatever。其实，使用CAP来简单描述一个复杂的分布式系统，本身就是错的。
最后，重复下，Please stop calling databases CP or AP。

引用

《Paxos到Zookeeper:分布式一致性原理与实践》
Towards Robust Distributed Systems
CAP 证明
Please stop calling databases CP or AP
cap-faq