ZkeeperZAB协议分析.docVIP

Zookeeper ZAB协议分析 ZAB协议是为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的原 子广播协议。在ZooKeeper中，主要依赖ZAB协议来实现分布式数据一致性， 基于该协议，ZooKeeper实现了一种主备模式的系统架构来保持集群中各个副 本之间的数据一致性。 Atomic broadcast protocol ZAB是Zookeeper原子广播协议的简称，下面我们来讨论协议的内容，注意： 理论与实现是右区别的，如果你对协议的理论不感兴趣，可以直接跳过看实现。 问题的提出 Zookeeper客户端会随机连接到Zookeeper集群的一个节点，如果是读请求， 就直接从当前节点中读取数据；如果是写请求，那么节点就会向leader提交事 务，leader会广播事务，只要奋超过半数节点写入成功，该写请求就会被提交 （类2PC协议）。 那么问题来了： 主从架构下，leader崩溃，数据一致性怎么保证？ 选举leader的时候，整个集群无法处理写请求的，如何快速进行leader选举？ 带着这两个问题，我们来看看ZAB协议是如何解决的 ZAB的四个阶段 术语解释 quorum :集群中超过半数的节点集合 ZAB中的节点有三种状态 ? following :当前节点是跟随者，服从leader节点的命令 ? leading :当前节点是leader ,负责协调事务 ? election/looking :节点处于选举状态 代码实现中多了一种:observing状态，这是Zookeeper引入Observer之后力U 入的，Observer不参与选举，是只读节点，跟ZAB协议没有关系 节点的持久状态 ? history :当前节点接收到事务提议的log ? acceptedEpoch : follower已经接受的leader更改年号的NEWEPOCH提议 currentEpoeh :当前所处的年代 lastZxid : history中最近接收到的提议的zxid （最大的） 在ZAB协议的事务编号Zxid设计中，Zxid是一个64位的数字，其中低32 位是一个简单的单调递増的计数器，针对客户端每一个事务请求，计数器加1; 而高32位则代表Leader周期epoch的编号，每个当选产生一个新的Leader 服务器，就会从这个Leader服务器上取出其本地日志中最大事务的ZXID,并 从中读取epoch值，然后加1，以此作为新的epoch,并将低32位从0 7T?始 计数。 epoch：可以理解为当前集群所处的年代或者周期，每个leader就像皇帝，都有 自己的年号，所以每次改朝换代，leader变更之后，都会在前一个年代的基础上 力口 1。这样就算旧的leader崩溃恢复之后，也没有人听他的了，因为follower只 听从当前年代的leader的命令。* Phase 0: Leader election （选举阶段） 节点在一开始都处于选举阶段，只耍有一个节点得到超半数节点的票数，它就可 以当选准leader。只有到达Phase 3准leader才会成为真正的leader。这一 阶段的目的是就是为了选出一个准leader,然后进入下一个阶段。 协议并没冇规定详细的选举算法，后面我们会提到实现中使用的Fast Leader Election。 Phase 1: Discovery （发现阶段） 在这个阶段，followers跟准leader进行通信，同步followers最近接收的事 务提议。这个一阶段的主要0的是发现当前人多数节点接收的最新提议，并且准 leader生成新的epoch，让followers接受，更新它们的acceptedEpoch phase 1 一个follower只会连接一个leader,如果有一个节点f认为历一个follower p 是leader, f在尝试连接p时会被拒绝，f被拒绝之后，就会进入Phase 0。 Phase 2: Synchronization （同步阶段） 冋步阶段主要是利用leader前一阶段获得的最新提议历史，同步集群中所奋的 副本。只有当quorum都同步完成，准leader才会成为真正的leader。follower 只会接收zxid比自己的lastZxid大的提议。 phase 2 Phase 3: Broadcast （广播阶段） 到了这个阶段，Zookeeper集群才能正式对外提供事务服务，并且leader可以 进行消息广播。同吋如果有新的节点加入，还需要对新节点进行冋步。 phase 3 值得注意的是，ZAB提交事务并不像2PC 一样需要全部follower都ACK, 只需要得到quorum （超过半数的节点）的ACK就可以了。 协议实现 协议的Jav