ZooKeeper源码阅读（一）：ZAB协议

ZooKeeper内部有一个in-memory DB，表示为一个树形结构。每个树节点称为Znode(相关的代码在DataTree.java和DataNode.java中)



客户端可以连接到zookeeper集群中的任意一台。



对于读请求，直接返回本地znode数据。写操作则转换为一个事务，并转发到集群的Leader处理。Zookeeper提交事务保证写操作(更新)对于zookeeper集群所有机器都是一致的。



ZooKeeper中提交事务的协议并不是Paxos，而是由二阶段提交协议改编的ZAB协议。



Zab可以满足以下特性

Reliable delivery：如果消息m被一个server递交(commit)了，那么m也将最终被所有server递交。

Total order：如果server在递交b之前递交了a，那么所有递交了a、b的server也会在递交b之前递交a。

Casual order：对于两个递交了的消息a、b，如果a因果关系优先于(causally precedes)b，那么a将在b之前递交。



第三条的因果优先指的是同一个发送者发送的两个消息a先于b发送，或者上一个leader发送的消息a先于当前leader发送的消息。

 

Zab协议中Server有两个模式：broadcast模式、recovery模式(Leader宕机或follower不构成quorum)

Leader在开始broadcast之前，必须有一个同步更新过的follower的quorum(多数派)。

Server在Leader服务期间恢复在线时，将进入recovery模式，与Leader进行同步。


Broadcast模式使用二阶段提交，但是简化了协议，不需要abort。follower要么ack，要么抛弃Leader，因为zookeeper保证了每次只有一个Leader。另外也不需要等待所有Server的ACK，只需要一个quorum应答就可以了。



Follower收到proposal后，写到磁盘(尽可能批处理)，返回ACK。

Leader收到大多数ACK后，广播COMMIT消息，自己也deliver该消息。

Follower收到COMMIT之后，deliver该消息。


然而，这个简化的二阶段提交不能处理Leader失效的情况，所以增加了recovery模式。切换Leader时，需要解决下面两个问题。


Never forget delivered messages

Leader在COMMIT投递到任何一台follower之前宕机，只有它自己commit了。新Leader必须保证这个事务也必须commit。



Let go of messages that are skipped

Leader产生某个proposal，但是在宕机之前，没有follower看到这个proposal。该server恢复时，必须丢弃这个proposal。



新Leader在propose新消息之前，必须保证事务日志中的所有消息都proposed并且committed。

为了保证follower看到有proposal，以及递交的消息，Leader向follower发送follower没有见过的PROPOSAL，以及最后提交的消息的编号之前的COMMIT。


因为Proposal是保存在follower的事务日志中，并且顺序有保证，因此COMMIT的顺序也是确定的。解决的第一个问题。


上个没有把proposal发送出去的Leader重启后，新Leader将告诉它截断事务日志，一直截断到follower的epoch对应的最后一个commit位置。


关于ZAB的详细证明可以参考Zab - High-performance broadcast for primary-backup systems

参考:http://blog.csdn.net/m_vptr/article/details/9325405