zookeep学习记录

1、简介

官网地址：https://zookeeper.apache.org/

gitee源码地址：https://gitee.com/apache/zookeeper?utm_source=alading&utm_campaign=repo

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和HBase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

2、CAP原理

C：Consistency

即一致性，访问所有的节点得到的数据应该是一样的。强一致性，弱一致性，最终一致性

注：zk是最终一致性，内部多种事务来用户最终访问保证强一致性

A：Availability

即可用性，所有的节点都保持高可用性。延迟和阻塞均不满足高可用。

P：Partiton tolerance

即分区容忍性，这里的分区是指网络意义上的分区。由于网络是不可靠的，所有节点之间很可能出现无法通讯的情况，在节点不能通信时，要保证系统可以继续正常服务。

C和A不能同时存在，如有三台服务器1,2,3；如果用户在1服务器上写入数据，为了保证三台服务器数据一致性的前提下，必须将2,3服务器进行阻塞，在数据同步完成后，用户才能从2,3上读取数据，这样保证了一致性，却将2,3服务器的可用性降低了，如果保证可用性，则在1,2,3上读取到的数据会不一致。

zk选择的是CP。

3、zk选举机制

server选举中的三种状态：

        LOOKING：选举leader中的状态
　　 LEADING：选举出来的leader
　　 FOLLOWING：已选举出leader，其它服务器的状态

zk集群必须保证半数以上的机器存活该集群才是运行中的状态，所以选择单数服务器。

如上图所示，有五台服务器，服务器myid分别为1,2,3,4,5。注意服务器id不能相同

集群初始化选举

此时五台服务器各持一票，开始广播选举，server1与serve2相比serve1的myid要小，所以将自己的选票投给server2，此时serve1为0票，server2为2票，票数未过半，继续选举；serve2与serve3相比，server2的myid小，将手中的2票投给server3，此时serve3持3票，对于五台服务器而言已经过半，这时server3当选为leader，并广播出去不在进行后续选举，此时server4和serve5自动变为follow，不用再进行选举流程。 

无法与leader通信或者leader服务器挂了

服务id :sid（id）,服务的标识

服务器中存放的最大数据ID ： zxid事务id

选举/投票纪元：epoch，即第几轮选举

epoch大的胜出；epoch相同ZXID大的胜出；epoch、zxid相同sid大的胜出