zookeeper学习记录(二)背景继上一篇的zookeeper的学习，上一篇主要偏向于zookeeper的总体结构的熟悉和使用
zookeeper学习记录(二)
背景
继上一篇的zookeeper的学习，上一篇主要偏向于zookeeper的总体结构的熟悉和使用层面。 本文主要是记录自己学习其内部的选举算法，一致性处理策略。
过程
在开始之前，推荐几篇比较不错的文章：
http://rdc.taobao.com/blog/cs/?p=162??(选举算法)http://rdc.taobao.com/team/jm/archives/448??(代码解析)zookeeper server
入口：org.apache.zookeeper.server.quorum.QuorumPeerMain
通过QuorumPeerConfig读取zoo.cfg配置文件，myid信息等。 具体的参数可以参考官方文档：?http://zookeeper.apache.org/doc/r3.3.3/zookeeperAdmin.html
主要关注几个参数：
peerType=observer/participant (是否是观察者，或者参与Leader/Follower)electionAlg=0/1/2/3/ (选举算法)server.1=zoo1:2888:3888server.2=zoo2:2888:3888server.3=zoo3:2888:3888group.1=1:2:3 (机器分组)group.2=4:5:6group.3=7:8:9 weight.1=1 (某机器权重)weight.2=1weight.3=1?
创建QuorumPeer，启动服务。QuorumPeer：首先加载本地的zkDatabasestartLeaderElection，发起一次Leader选举。 选举算法：LeaderElection / ?FastLeaderElection /?AuthFastLeaderElection确定自己的角色后，进行响应的角色初始化：
OBSERVING : ?observer.observeLeader();
FOLLOWING : ?follower.followLeader();
LEADING : ?leader.lead();LeaderElection算法：
每个机器节点加入，都发起一次Vote。zookeeper server节点接受到新一轮的Vote，都返回上一轮的Leader选举的最后Vote结果。如果处于LOOKING，比如第一次加入的机器，则Vote自己发起Vote的机器，收集完所有server的Vote结果(包括自己)，统计一下结果，并且判断一下是否超过半数
if (result.winningCount > (self.getVotingView().size() / 2))
?注意：这里的>号，所以如果单台机器启动，无法通过给自己Vote，使自己成为Leader。一定要>=2台机器的参与如果没有超过半数，则记录一下本次的投票结果。下一次Vote时，就直接投给上一轮票数最高的Vote，继续进入步骤3
说明： myid序号大的在Vote选举时比较有优势，同样的票数winner会是myid最大的server，从而保证每次的Vote必然会产生一个唯一的winner。
FastLeaderElection算法：
每个机器节点加入，都向外部建议自己做为Leader。zookeeper server接受到请求后，进行一个抉择：?
if ((newZxid > curZxid) || ((newZxid == curZxid) && (newId > curId)))
?判断当前的zxid和myid是否大于当前Vote，如果是则更新之，并同样广播给所有的server。
注意：
?? ? Notification中有个epoch标志，表明当前发起的Vote的传递的次数。比如A发给B，B更新了自己的Vote后，再发给C。这时发的通知中epoch=2。
?? ? 有点类似图论里的概念，如果notice.epoch < 当前最后一次更新Vote的epoch，则不做任何处理。一个逐步收敛的有向环图单个机器上收到了其他所有机器的Vote结果后，判断出最后的winner结果
Leader处理：启动LearnerCnxAcceptor，监听Follower的请求。针对每个链接的Follower，开启一个新线程LearnerHandler进行处理
然后针对所有的LearnerHandler，while(true)进行心跳检查ping。针对每次ping结果，针对有ack响应的结果进行vote统计，如果发现超过半数失败，则退出当前的Leader模式，这样又是发起新一轮的选举Follower处理：建立socket，链接到Leader server上发起一次syncWithLeader同步请求，此时Leader会根据当前的最大的zxid对比客户端的zxid，发送DIFF/TRUNC/SNAP指令给follower上，保证follower和leader之间的数据一致性。同步完成后，就进入while(true){read , process}的工作模式，开始接受Leader的指令并处理
PING : ?响应Ack
PROPOSAL : ?记录到自己的缓冲队列pendingTxns中，等待sync指令后刷新到zkDataBase中。有点类似2PC阶段事务
COMMIT : ?刷新pendingTxns中的对应记录
SYNC : 客户端的同步request请求Observer处理：建立socket，链接到Leader server上发起一次syncWithLeader同步请求同步完成后，进入while(true){read , process}的工作模式，和Follower有点不同，主要在于其不处理PROPOSAL/COMMIT等2PC阶段。只接受INFORM，Leader告诉最终的更新结果，Observer直接提交到zkDataBase中。
针对Leader/Follower/Observer都有对应的ZooKeeperServer提供客户端的处理，分别是：LeaderZooKeeperServer /?FollowerZooKeeperServer /?ObserverZooKeeperServer 。下面继续来看一下对应的Server处理，主要区别在于RequestProcessors的组织上。
LeaderZooKeeperServer处理：PrepRequestProcessor ->?ProposalRequestProcessor ->?CommitProcessor ->?toBeAppliedProcessor ->?FinalRequestProcessor处理顺序PrepRequestProcessor主要处理ACL控制，不细讲，自己看看代码就懂的ProposalRequestProcessor，处理有点特殊。因为Leader server同样会提供客户端API的create操作，所以需要做特殊处理
1. 如果请求是LearnerSyncRequest，表明是leader做为server提供给客户端服务，并且接受到客户端的sync请求。
2. 否则认为是需要进行决策，发给所有的follower进行投票。(这里的请求可能来自于follower的写动作请求leader决策，也可能是leader做为server自己接收到的请求)，通过AckRequestProcessor先给自己投票。
注意：?ProposalRequestProcessor只会针对create/delete等写操作会发起一次Vote。 读操作会直接交由后续的Processor进行处理CommitProcessor主要是一些等待commit处理的request，接收到sync指令后就会提交到下一个Processor进行处理。
做为leader，会在收集足够的Vote后，自己会给自己发送一次sync指令
做为Follower，会受到Leader发送的Sync指令，然后自己提交commit动作toBeAppliedProcessor： 主要的作用就是记录当前正在提交到zkDatabase中的request数据，保证新的Follower连接上来时，能获取到这些处于内存中"正准备提交"的数据FinalRequestProcessor ： 处理最后的请求，比如读/写请求，此时所有的server都会同步的写入数据。
FollowerZooKeeperServer处理：接受客户端请求： FollowerRequestProcessor ->?CommitProcessor ->?FinalRequestProcessor
1. 客户端接受请求后，针对一些写动作(比如create,delete,setData,setAcl等)，FollowerRequestProcessor会发起一个request，请求leader进行所有server的一致性的控制。 同时会将request请求递交到commitProcessor
2.?CommitProcessor请求，会等待leader的sync request请求，会提取出相对应的request，提交到下一个processor进行处理。
3.?FinalRequestProcessor，处理最终的指令请求。因为一些写动作通过follower->leader的交互已经得到Leader的ack，会保证每个节点都能写入request数据。处理Leader的PROPOSAL/COMMIT：?SyncRequestProcessor -> SendAckRequestProcessor。 (主要是接受Leader广播的其他server的数据变更事件，保证所有server都能得到同步更新)
1. 主要是接受到Leader的PROPOSAL request后，先将request暂存于pendingTxns，并提交到SyncRequestProcessor的queue队列，排队进行后续发送Ack给Leader处理
2. 接受到Leader端的sync/commit指令，将pending的request请求提交到当前server的zkDataBase中。?ObserverZooKeeperServer处理：?接受断乎端请求：?ObserverRequestProcessor ->?CommitProcessor ->?FinalRequestProcessorObserverZooKeeperServer处理和FollowerZooKeeperServer基本类似，只不过它不会处理Leader的PROPOSAL/COMMIT事件，也就是不会参与Vote处理。
哈哈，图画起来挺累人的，这里盗用了taobao同学画的图，原文可参考前面推荐的图。Leader处理：
?Follower处理：
?Leader/Follower之间的消息传递：
?最后
感慨几下：
1. 彪悍的图，画的比较精细，不是真正了解Follower/Leader之间的数据处理，不太容易看的懂
2.?zookeeper开发者仅仅通过Tree树状结构，可以实现分布式一致性控制，可以衍生出Barrier,Lock等功能。感叹人的智慧
3.?感叹淘宝的同学，发觉在rdc.taobao.com/上有n多人研究分布式的相关内容，而且文章质量都不错。为啥同样是阿里的子公司，学习的氛围咋就差这么多呢，可能一个原因还是数据量的问题。
