breezes

ZAB: ZooKeeper的Atomic Broadcast协议

ZooKeeper的主要功能是维护一个高可用且一致的数据库,数据库内容复制在多个节点上,总共2f+1个节点中只要不超过f个失效,系统就可用。实现这一点的核心是ZAB,一种Atomic Broadcast协议。所谓Atomic Broadcast协议,形象的说就是能够保证发给各复本的消息顺序相同( 准确的定义就很复杂了,我也没完全搞懂)。

由于Paxos的名气太大,所以我看ZAB的时候首先就想为什么要搞个ZAB,ZAB相比Paxos有什么优点?这里首要一点是Paxos的一致性不能达到ZooKeeper的要求。举个例子。假设一开始Paxos系统中的leader是P1,他发起了两个事务<t1, v1>(表示序号为t1的事务要写的值是v1)和<t2, v2>,过程中挂了。新来个leader是P2,他发起了事务<t1, v1'>。而后又来个新leader是P3,他汇总了一下,得出最终的执行序列<t1, v1'>和<t2, v2>,即P2的t1在前,P1的t2在后。

这样的序列为什么不能满足ZooKeeper的需求呢?ZooKeeper是一个树形结构,很多操作都要先检查才能确定能不能执行,比如P1的事务t1可能是创建节点“/a”,t2可能是创建节点“/a/aa”,只有先创建了父节点“/a”,才能创建子节点“/a/aa”。而P2所发起的事务t1可能变成了创建“/b”。这样P3汇总后的序列是先创建“/b”再创建“/a/aa”,由于“/a”还没建,创建“a/aa”就搞不定了。

为了保证这一点,ZAB要保证同一个leader的发起的事务要按顺序被apply,同时还要保证只有先前的leader的所有事务都被apply之后,新选的leader才能在发起事务。

ZAB的核心思想,形象的说就是保证任意时刻只有一个节点是leader,所有更新事务由leader发起去更新所有复本(称为follower),更新时用的就是两阶段提交协议,只要多数节点prepare成功,就通知他们commit。各follower要按当初leader让他们prepare的顺序来apply事务。因为ZAB处理的事务永远不会回滚,ZAB的2PC做了点优化,多个事务只要通知zxid最大的那个commit,之前的各follower会统统commit。

如果没有节点失效,那ZAB上面这样搞下就完了,麻烦在于leader失效或leader得不到多数节点的支持时怎么处理。这里有几个关键点:

1、leader所follower之间通过心跳来检测异常;

2、检测到异常之后的节点若试图成为新的leader,首先要获得大多数节点的支持,然后从状态最新的节点同步事务,完成后才可正式成为leader发起事务;

3、区分新老leader的关键是一个会一直增长的epoch;

当然细节很多了,这里就不说了因为我也没完全搞懂,要了解详情请看《Zab: High-performance broadcast for primary-backup systems.》这篇论文。

除了能保证顺序外,ZAB的性能也能不错,基于千兆网络的测试,一般的5节点部署的TPS达到25000左右,而响应时间只有约6ms。

评论

热度(3)