目录
Phase 0: Leader election(选举阶段,Leader不存在)
Phase 1: Discovery(发现阶段,Leader不存在)
Phase 2: Synchronization(同步阶段,Leader不存在)
Phase 3: Broadcast(广播阶段,Leader存在)
Zab也是一个强一致性算法,也是(multi-)Paxos的一种,全称是Zookeeper atomic broadcast protocol,是Zookeeper内部用到的一致性协议。相比Paxos,也易于理解。其保证了消息的全局有序和因果有序,拥有强一致性。Zab和Raft也是非常相似的,只是其中有些概念名词不一样。
名词概念
为了读懂后面的内容,有些术语需要了解:
Peer:节点。代表了系统中的进程,往往系统有多个进程,也就有多个节点提供服务
Quorum:多数。当有N个Peer,多数就代表Q(Q>N/2)个Peer
Leader:主节点,最多存在一个。代表zookeeper系统中主要的工作进程,Leader才是真正处理所有zookeeper写请求的节点,写请求会从Leader广播到Quorum Follower
Follower:从节点,可以有多个。如果client对zookeeper发起一个读请求,Follower可以直接处理。如果client对zookeeper发起一个写请求,Follower需要转发到唯一的Leader,再有Leader处理并发起广播
Election:说明节点处于选举状态。整个集群都处于选举状态中。
Epoch:逻辑时钟,相当于paxos中的proposerID,Raft中的term,相当于一个国家,朝代纪元(每个 leader 就像皇帝,都有自己的年号,所以每次改朝换代,leader 变更之后,都会在前一个年代的基础上加 1。这样就算旧的 leader 崩溃恢复之后,也没有人听他的了,因为 follower 只听从当前年代的 leader 的命令。)
zxid:事务id。zk为了保证消息有序性,提出了事务编号这个概念。zxid是一个二元组<e,c>,e代表选举纪元(如果将选举理解更皇帝的选举,这纪元代表年号),c代表事务的计数,同一纪元内每次出现写请求,c自增(代表某个年号内经过了多少年)。容易理解,纪元不变时,计数不断增加,纪元变化时,计数清零(是一个 64 位的数字,低 32 位是一个简单的单调递增的计数器,针对客户端每一个事务请求,计数器加 1;高 32 位则代表 Leader 周期 epoch 的编号,每个当选产生一个新的 Leader 服务器,就会从这个 Leader 服务器上取出其本地日志中最大事务的ZXID,并从中读取 epoch 值,然后加 1,以此作为新的 epoch,并将低 32 位从 0 开始计数。)
history: a log of transaction proposals accepted; 历史提议日志文件
acceptedEpoch: the epoch number of the last NEWEPOCH message accepted; 集群中的最近最新Epoch
currentEpoch: the epoch number of the last NEWLEADER message accepted; 集群中的最近最新Leader的Epoch
lastZxid: zxid of the last proposal in the history log; 历史提议日志文件的最后一个提议的zxid
vote:选票,代表二元组<zi,i>。zk会给每个peer打上唯一标识,即i,二元组的i就代表了选举的peer,而zi代表了这个peer上最新的zxid
state:节点状态,目前只有这三种election、leading、following
lastCommittedZxid:最近提交成功的事务
oldThreshold:日志中记录最早提交成功的事务。之所以设置一个最早的门槛,就是觉得没有必要保留非常久远以前的事务,以便减少对内存的占用以及数据同步带来的网络开销
协议实现
Zab协议中描述的如下四个阶段
Phase 0: Leader election(选举阶段,Leader不存在)
节点在一开始都处于选举阶段,只要有一个节点得到超半数Quorums节点的票数的支持,它就可以当选prospective leader。只有到达 Phase 3 prospective leader 才会成为established leader(EL)。
Phase 1: Discovery(发现阶段,Leader不存在)
在这个阶段,PL收集Follower发来的acceptedEpoch,并确定了PL的Epoch和Zxid最大,则会生成一个NEWEPOCH分发给Fo