一言以蔽之：分布式系统的协调者
两个核心功能
1.管理和存储数据结点
2.提供对结点的监听服务
三种角色
分别是Leader、Follower、OBSERVER，没有leader的时候，所有zk服务器都处于LOOKING状态，不处于任何角色。一旦leader选举成功，各个角色才各自归位。
Leader：做事务请求的验证，发送Proposal，收集ACK，发PING维护Follower和Observer的存活列表，维护session的生命周期，分配事务id；
Follower：接收client的读写操作，自己处理读操作，将写操作转发到leader，接收Proposal，参与proposal投票，对leader作出ACK，响应leader发送的PING请求，检测leader的存活状态注册watch，触发通知；
Observer：不参与任何投票，leader不会向Observer发Proposal，也不参与leader的选举，它接收读写请求，并转发写请求给leader，它的存在并不能增加宕机容忍性，而是提升集群的非事务处理能力，响应leader发送的PING请求，检测leader的存活状态。
leader选举
选票格式(proposedLeaderId，proposedZxid，logicalclock，proposedEpoch)
初始选票(自己的serverid，自己的lastZxid，自己的logicalClock，自己的currentEpoch)
说明：Logicalclock是选举次数，自进程启动以来经历的第几次选举，为避免因网络过慢导致上轮选举造成影响，故logicclock要达成一致，以最大的那个优先。
PK规则：先比较epoch，epoch相同的话比较zxid，zxid再相同的话比较serverid，值大的那个获胜，参与投票的server如果发现接收到的投票比自己大，那么会更新自己的投票再发送出去。
选举规则：
1、 所有处于looking状态的server都向其它所有server发送投票，初始投票选自己；
2、 接收来自其它server的投票，接收不到就继续发送本地投票，如果PK失败则更新本地投票重新发出；
3、 当收集的投票满足条件，包括本地投票在内的quorum数量的投票都达成一致，等待200ms无异议时，当接收的投票来自于leadering或者following状态时还需要判断leader是否处于leadering状态，以避免建立连接不成重新进入looking状态；
4、 Follower和leader进入各自的角色，leader启动sync端口，follower向leader建立连接，follower向leader注册自己，leader发现follower不足够会重新进入选举阶段。
故障恢复
一个有2N+1个实例组成的zookeeper集群，最大能允许N个实例出现故障，超过N个就会造成服务不可用。那什么情况下会使得集群进入leader选举状态呢？
1、leader出现故障：当leader出现故障时所有的 Follower会进入LOOKING状态重新进行投票选举；
2、当集群中有超过N个实例出现故障，这时leader将接收不到足够quorum数量的PING响应，这时leader 关闭同步端口，断开所有的learner连接，使得整个集群都进入LOOKING状态
3、当选举成功leader角色和Follower角色都已经建立之后，如果在Follower注册、Follower与leader建立连接、同步数据成功的个数，不足quorum数量，都会导致重新进入LOOKING状态重新进行leader选举。
4、learner和leader之间连接是BIO的，learner一直做阻塞读和阻塞写的循环，一旦发现读超时则退回到LOOKING状态重新寻找leader
初始化和数据同步
Leader
1、 对于leader，启动同步端口，为每个learner分配一股learnerHandler和Sender线程；
2、 等待超过集群机器半数的follower注册进入forwarding列表，等待超过机器半数的follower接收到同步数据，完成数据同步；
3、 开启对外服务，启动处理事务的processor。
Follower
1、 对于follower，建立与leader同步端口的连接；
2、 同步epoch，向leader注册自己，完成数据同步；
3、 启动处理事务的processor。
线程模型
WorkerReceiver[myid=1] 用于leader选举
将多个recvWorker收到的投票汇总起来，自身处于looking状态提供给quorumPeer进行投票判断，自身处于learner和leader状态发出自己的投票交给workerSender(用于告诉重新加入的节点leader是谁)
WorkerSender[myid=1] 用于leader选举
负责将要发出的投票添加到各个serverid对应的发送队列中(每个serverid一个队列)
SendWorker：2 用于leader选举
将server2对应的队列数据依次发送给server2
RecvWorker：2 用于leader选举
接收server2过来的投票，以队列方传送给workerReceiver线程
QuorumPeer[myid=1]
用于选举发送投票消息寻找leader，Follower用于初始化数据同步，向leader注册自己，Leader用于初始化监控数据同步完成，Follower在消息广播用作接收leader过来的packet、返回ping，Leader在消息广播用作发ping并心跳检查，启动zookeeperserver，开启对外服务。
数据结构
ZooKeeper所提供的服务主要是通过：数据结构+原语+watcher机制
数据结构：Znode
原语：关于该数据结构的一些操作
Wathcer：通知机制 客户端可以在节点上设置watch，我们称之为监视器。当节点状态发生改变时(Znode的增、删、改)将会触发watch所对应的操作。当watch被触发时，ZooKeeper将会向客户端发送且仅发送一条通知，因为watch只能被触发一次，这样可以减少网络流量。
controller_epoch:最后更新leader和isr的controller代
leader:leader副本的id
version:版本id
leader_epoch:leader副本的代
示例如下：
