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的性能也能不错，基于千兆网络的测试，一般的5节点部署的TPS达到25000左右，而响应时间只有约6ms.

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。