Zookeeper纸上谈兵——Zookeeper与CAP原则

今天来介绍一下CAP原则，以及Zookeeper对于CAP的取舍。

1. 什么是CAP

CAP原则又称CAP定理，是指在一个分布式系统中，Consistency（一致性）、Availability（可用性）、Partition toltolerance（分区容错性），三者不可同时兼得（指不能同时达到最佳效果）。三者分别介绍如下。

• 一致性，分布式系统的所有主机中在同一时刻可以保证具有完全相同的数据备份。
• 可用性，在集群中，如果部分节点发生故障，是否会影响对客户端读写请求的响应。注意，如果短时间内会有影响，那么也不满足这里所说的可用性。
• 分区容错性，百度百科说分区容错性是指系统能够容忍节点之间的网络通信故障，就是说集群因为网络啊，机器故障等原因，使得集群内机器间的通讯受阻，从而服务器分成了几个区域（分区），集群对这种情况的包容度。每一个节点都可以一个分区，分布式中多个机器存着相同的数据，所以分区容错性是必须的，不然不能体现分布式集群的能力。

2. 三二原则

所谓三二原则就是说，对于一个分布式系统，CAP三者不能同时满足，只能满足其中的两种，由于P是必须的，所以要么是CP，要么是AP。为什么这样呢？我们来分析一下。
由于分区容错性是必须的，所以为了提高容错性，就把数据复制到多个服务器里，也就是备份，这样即便部分机器故障啥的，服务依然能够正常提供，也就是容错性提高了。但这个时候备份的机器越多，要使各个机器之间的数据保持一致就越困难，为了维护一致性，就需要等待所有机器中的数据达成一致，这样是比较耗时的，也就是可用性就变低了，所以一致性可用性要做取舍，一致要提高，必然导致另一者的下降。这就是CAP的三二原则。Zookeeper选择了CP。

3. Zookeeper与CP

Zookeeper遵循的是CP原则，也就是选择了一致性，牺牲了可用性。具体体现在：

• 当Leader挂掉的时候，集群会马上重选Leader。但这个选举时长在30-120秒之间，在这期间Follower都是Looking状态，是不能提供服务的，相当于集群整个就瘫痪了，所以不满足可用性。

那么为什么Zookeeper的选举如此耗时呢？因为Zookeeper要保证各个节点中数据的一致性，它会做两类数据同步：初始化同步与更新同步。可以看一下我上一篇讲ZAB的博客，Leader选举出来以后，Follower需要将Leader的数据同步到自己的缓存之中，这就是初始化同步。另外，如果Leader的数据被修改，Leader会给Follower发广播通知，然后各个Follower会主动去同步Leader更新的数据，这个就是更新同步。在这两个同步的过程中，Zookeeper为了保持数据一致性，如果发现有超过半数的Follower同步时间超时，它会再次进行同步，而这个过程中，集群是不可用的。
以上说的就是Zookeeper的致命问题，可用性低，因为它采取的是CP原则嘛。相较之下，SpringCloud的Eureka在分布式系统中的作用类似于Zookeeper，不过其采用的是AP原则，即牺牲一致性，换取可用性。
下一篇博客来做一下集群安装与搭建。