Zookeeper工作原理

http://blog.csdn.net/shaolinshu/article/details/7927345

Zookeeper依靠Zab协议保证数据一致性：

Zab原子广播保证了可靠提交，全局有序和因果有序

可靠提交(Reliable delivery)：指如果一个message被提交，则所有的server上都会提交

全局有序：指各个Server收到的message有序，这个由TCP协议保证；

因果有序：指如果a发生在b之前，并被一起发送，那么对于每个Server，a都在b之前被执行。

Zab原子广播的三个阶段：

1.leader选举

2.leader和follower同步数据

3.BroadCast

第一阶段Leader选举。

要选出具有最大zxid（事物id）的zk server作为leader，因为其有着最新的操作；如果大家zxid都一样（比如第一次启动），那么选择myid号最大的Server作为leader。Zk支持三种Leader选举算法，默认采用FastLeaderElection算法，还没仔细看。

第二阶段数据同步：

1）follow发送类型为Leader.FOLLOWERINFO的QuorumPacket向Leader注册自己，该packet包含有自己可见的最大zxid

2）Leader根据follow的zxid来选择同步方式，是发整个SnapShot还是只发zxid让follow回滚至自己最后一个SnapShot然后再根据CommitLog去恢复。

发送CommitLog的Txn时，还可能发送了其正在执行的Proposal（因为Leader还在工作，可能收到写请求），这个先缓存起来，待收到Commit消息时提交。

3）follow同步完成（收到Leader.UPTODATE消息），启动FollowZookeeper的消息处理链线程，follow开始接收客户端连接并提供服务。

第三阶段消息循环：

Follow消息循环

Follow在完成同步后启动其消息处理链线程以处理客户端请求。

Follow处理以下几种类型的消息：

1）Leader.PING

回应Leader的心跳，返回己方所有SessionId的信息

2）Leader.PROPOSAL

Leader的写请求提议，发往SyncRequestProcessor处理链处理，先记录在transaction log中，在通过流水线中SendAckRequestProcessor投出自己一票。

3）Leader.COMMIT

表示该transaction被通过，可以提交，把该zxid对应的Request发往CommitRequestProcessor并通过FinalRequestProcessor提交

4）Leader.UPTODATE

消息循环中不处理该消息，这个是同步leader数据结束时发送的消息。

5）Leader.REVALIDATE

reopen session时用来从Leader方查询Session是否有效并根据结果回复握手包prime_connect的回应。

6）Leader.SYNC

同步

Follow消息处理链：

FollowRequestProcessor->CommitProcessor->FinalRequestProcessor
SyncRequestProcessor->SendAckRequestProcessor

FollowRequestProcessor消费NIOServerCnxn读到的Request，对于写请求转发给Leader(Leader.REQUEST消息)，对于读请求发送到CommitRequestProcessor。

CommitRequestProcessor对于读请求直接转发到FinalRequestProcessor，对于写请求缓存直到Leader发来Commit消息才出队提交至FinalREquestProcessor。

FinalRequestProcessor真正把改变写入内存树。

SyncRequestProcessor接收Leader发来的Proposal消息，记录transaction log，并通过SendAckRequestProcessor投出自己的一票。

SendRequestProcessor投出自己的一票。

只有在commit消息到来时，数据才真正被修改，此时只是记录到transaction log，还没被修改。

Leader消息循环：

当Server确定自己是Leader后，启动LearnerCnxAcceptor线程接收follow的连接，发送Leader.NEWLEADER给所有follow，得到多数follow响应后建立Leader方的消息处理链，开始处理客户端请求。

leader的主线程每1/2个tickTime向所有follow发送ping心跳。

对每个follow的消息循环交给LearnerHandler线程（由LearnerCnxAcceptor线程创建）

LearnHandler线程根据Follow的zxid对Follow做同步，同步完成时发送UPTODATE，follow便可以对外提供服务了。

Leader处理以下几种类型的消息：

1）Leader.ACK

follow对Proposal的相应，当收到多数follow的ack时，即可commit该事务

2）Leader.PING

follow的ping消息，该消息包含在follow方的session id，延长这些session的timeout

3）Leader.REVALIDATE

reopen session时，用来延长leader方的session的timeout

4）Leader.REQUEST

follow转发来的写请求，直接进Leader的消息处理链第一个即(PreRequestProcessor)

Leader消息处理链：

PreRequestProcessor->ProposalRequestProcessor->CommitRequestProcessor->Leader.ToBeApplyRequestProcessor->FinalRequestProcessor
SyncRequestProcessor->AckRequestProcessor

PrerequestProcessor所处理的队列包含了客户端的请求和follow转发来的写请求。对于其中的读请求不做任何处理，对于写请求添加txnHeader和txn用于像所有follow发送原子广播的Proposal。

ProposalRequestProcessor对其中的写请求向所有Leader发送Proposal，同时SyncRequestProcessor记录transaction log。所有请求均交由下一个CommitProcessor继续处理。

CommitProcessor的queueRequest队列缓存所有请求，等待Commit消息到来时将请求交由下一条处理链。

Leader.ToBeApplyRequestProcessor缓存了leader已经被commit并准备更新的request，这在和follow进行DIFF类型的同步时，将这些已经通过的Proposal直接交由follow更新内存数据库。该处理链只是用于做DIFF同步。

FinalRequestProcessor做实际的更新。

SyncRequestProcessor记录transaction log，并在一定时间生成snapshot持久化

AckRequestProcessor统计Ack，并在收到多数follow的ACK时通过该请求。

ZookeeperServer的消息处理链这种流水线处理请求的设计模式使得复杂的一致性协议清晰明了，效率很高，值得借鉴。