参考：CAP 定理的含义
其他：
1,对zk的CP模型的理解。
P 指的是分区容错，个人理解是奇数节点中有少于半数的节点宕机（我理解为等价于出现网络分区故障），zk依然可以提供服务支持。
C 一致性，因为zk的数据处理（非事务型）是需要半数以上的节点返回成功，zk就返回客户端成功，所以这个不是强一致性（所有follow节点都要返回成功），是弱一致性。
为什么不是A呢？zookeeper 的leader节点挂了之后，zk将不再提供服务，所有的follow节点都处于 Looking状态去进行选举。
所以ZK不是AP，是CP 而且是 弱一致性模型。
2，对zk的选举的理解
zk的选举是根据每个节点上的 zxid和myid来处理的。
zxid是事务ID，其实每次 事务性数据操作，每个节点会更新成最新的zxid.
--2.1 服务器启动时期的leader选举
1), 每个server会发出一个投票。
对server1和server2来说，投票以（myid,zxid）来表示，即server1为（1,0），server2是（2，0）。
都会先投自己一票，然后再投给集群中其他所有机器。
2), 接收来自各个服务器的投票。
每个server接收其他server的投票，然后检查是否是本轮投票，是否来自LOOKING状态的服务器。
3), 处理投票。
接收到其他服务器的投票后，会跟自己的投票进行PK，规则如下：
* 优先检查zxid。zxid比较大的server作为leader。
* 如果zxid相同，那么就比较myid，myid比较大的作为leader。
然后怎么处理呢？server1（1,0）一看接收到（2,0）的比自己大，就会更新自己的投票为（2,0），然后
再次将投票发出去。server2不需要更改，只是再次将自己的投票发出去。
4), 统计投票。
每次投票后，服务器都会统计所有的投票，判断是否已经有过半的机器接收到相同的投票信息。当server1和server2都接收到相同的投票信息（2,0）后，即认为选出了leader。
5), 改变服务器状态。
一旦确定了Leader，每个server会更新自己的状态：如果是Follower，那么就会变更为 FOLLOWING，如果是Leader,就会变更为 LEADING。
--2.2 服务器运行期间的Leader选举
一旦leader节点挂了，那么Follower节点会立即开始leader选举。选举流程和启动时期的选举流程基本一致。
1), 变更状态。
当Leader挂了之后，剩下的非Observer节点会将自己的服务器状态变更为 LOOKING,然后开始进入 Leader选举流程。
2), 每个server会发出一个投票。
3), 接收来自各个服务器的投票。
4), 处理投票。
5), 统计投票。
6), 改变服务器状态。
即只有第一步是特有的 其他的全部一致。
传送门：Zookeeper之脑裂
