前言
CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
这篇我来说明一下三者为什么不可兼得，以及Zookeeper在AC之间的取舍。
CAP为什么不可兼得
① C：Consistency，一致性，数据一致更新，所有数据变动都是同步的。
② A：Availability，可用性，系统具有好的响应性能。
③ P：Partition tolerance，分区容错性。以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择，也就是说无论任何消息丢失，系统都可用。
我用一个列子来具体说明CAP是是什么意思。假设这里有有台服务器，Server1、Server2，每台服务器上有一个数据Value0。
当在Server1上修改了数据为Value1，网络正常情况下Server1会把数据同步到Server2。那么我们去获取数据的时候，无论是从Server1还是Server2都能得到Value1这个最新值并且响应的时间是正常的。能够从两台服务获取最新的数据就是数据的一致性，而在一定的时间内响应给用户则是可用性。
刚刚是在网络正常情况下的假定，现在来看，如果Server1和Server2的通信出了延迟。导致Server1上的数据正常更新了，而Server2上的数据还是旧的。
现在有客户从Server2上获取数据，你是要等到网络延迟变成正常之后把最新的数据返回回去，还是要给用户一个良好的响应时间，把旧的数据返回回去呢？
· 如果要求C（一致性），那么你必须牺牲可用性，让用户等到Server2上的数据变成最新。
· 如果要求A（可用性），那么用户能有一个好的响应时间，只是数据是旧的。
做不到两者都满足的情况下，我们只能在两者之间寻找到平衡点。这就是为什么不能同时满足CAP。需要明确的一点是，对于一个分布式系统而言，分区容错性是一个最基本的要求。因为既然是一个分布式系统，那么分布式系统中的组件必然需要被部署到不同的节点，否则也就无所谓分布式系统了，因此必然出现子网络。而对于分布式系统而言，网络问题又是一个必定会出现的异常情况，因此分区容错性也就成为了一个分布式系统必然需要面对和解决的问题。因此系统架构师往往需要把精力花在如何根据业务特点在C（一致性）和A（可用性）之间寻求平衡。
Zab协议中一致性和可用性的协调
ZAB协议中多次用到“过半”设计策略 ，该策略是zk在A（可用性）与C（一致性）间做的取舍，也是zk具有高容错特性的本质。相较分布式事务中的2PC（二阶段提交协议）的“全量通过”，ZAB协议可用性更高（牺牲了部分一致性），能在集群半数以下服务宕机时正常对外提供服务。