zookeeper集群结构

zookeeper参考Paxos协议，设计了Zab协议，其使用Zab协议来实现分布式数据一致性

Zookeeper使用一个单一主进程来接收并处理客户端的所有事务请求，即写请求。当服务器数据的状态发生变更后，集群采用Zab原子广播协议，以事务提案Proposal的形式广播到所有的副本进程上，其保证一个全局的变更序列，即可以为每个事务分配一个全局递增的xid

Zab协议

zookeeper采用的Zab协议（ZooKeeper Atomic Broadcast，ZooKeeper原子广播协议），Zab协议分为两个阶段：Leader Election领导选举和Atomic Broadcast原子广播

基于Zab协议，zookeeper实现了一种主备模式（Leader、Follower）的系统架构来保持集群中各副本之间的数据一致性，使得zookeeper成为了解决分布式数据一致性问题的解决方案

zookeeper中有三种类型的节点leader、follower、observer（follower、observer属于learner）
分为三个步骤

Leader包装写请求，生成唯一zxid，发起提议，广播给所有Follower
Follower收到提议后，写入本地事务日志，根据自身情况，是否同意该事务的提交
Leader收到过半的follower同意(ZAB协议需要Follower有一半以上返回Ack信息就可以提交，减少了同步阻塞时间)，自己先添加事务。然后对所有的learner节点发送提交事务请求

zxid是一个64位的数字，高32位表示纪元epoch(代表了每代Leader的唯一性)，低32位表示事务标识xid(代表了每代Leader中事务的唯一性)，每个Leader都会具有一个不同的epoch值，表示一个时代。

每次新的选举开启时都会生成一个新的epoch，新的leader产生，就会更新所有zkserver的zxid中的epoch。

xid为zk的事务id，每一个写操作都是一个事务，都会有一个xid，xid是一个递增的流水号，每一个写操作都需要由leader发起一个提案，由所有follower表决是否同意本次操作，每个提案都具有一个zxid

领导选举

当zookeeper集群启动时，会选举出一个节点为Leader，其他节点为Follower。如果Leader挂了之后，会从follower中选举出新的Leader（谁的数据最新，谁就有优先被选为Leader的资格【比较事务id】），并让所有节点恢复到一个正常的状态

这里Leader挂会有两种可能：

Leader没挂，只是由于某种原因某个Follower无法与Leader建立连接，如follower2认为leader挂了，就会发起leader选举，但是其他的follower发现leader没挂，会拒绝follower2的选举申请，并告知当前已存在的leader信息，follower2去重新建立连接
Leader真的挂了，选举时会先比较epoch，如果epoch相同则比较zxid，如果zxid相同，则比较sid(都是大的当选)

三个值的含义

epoch 相当于Leader任期的编号，每投完一次票，这个编号就会增加

zxid 事务id

sid 服务器id

原子广播

领导选举阶段完成之后，就会进入原子广播阶段，同步Leader节点和各个Follower节点之间的数据，确保Leader和Follower节点具有相同的状态，所有的写操作都会发送到Leader节点，并通过广播的方式将数据同步到其他Follower节点，如果超过半数成功响应，则执行commit操作(先commit自己，在发送commit给所有follower)

集群

zookeeper集群中的每个节点都会在内存中维护当前服务器状态，并且每个节点之间都会保持通信，只要集群中存在超过半数以上的节点可以正常工作，那么整个集群就可以正常的提供服务