Zookeeper集群中server数量总是确定的，所以集群中的server交互采用比较可靠的bio长连接模型；不同于集群中sever间交互zookeeper客户端其实数量是未知的，为了提高zookeeper并发性能，zookeeper客户端与服务器端交互采用nio模型。下面我们主要来讲讲zookeeper的服务器端与客户端的交互。读者对nio不了解的话不妨抽点时间去了解下，对于一些nio框架如netty，mina再如一些web容器如tomcat，jetty底层都实现一套nio框架，对于实现nio框架模型大家不妨去谷歌百度搜一下Doug Lea的scalable io in java 这个ppt。客户端ClientCnxnSocketNIO是zookeeper的nio通讯层的客户端部分，下面伪代码示例其核心代码：ClientCnxnSocketNIO{ doTransport() { if （如果之前连接没有立马连上，则在这里处理OP\_CONNECT事件) { sendThread.primeConnec
下面就用一张图来说明Leader端的处理器链的交互过程 2. 下面就用一张图来说明Follower（Observer类似）端的处理器链的交互过程
各个processor的主要功能1） PrepRequestProcessor 如名字这个处理器主要功能是对请求进行预处理， 将client向server请求二进制数据反序列化成sever中请求操作。PrepRequestProcessor做为leader的第一个处理器，它的请求数据来源主要来自：(1) Leader做一个zk服务接收客户端请求提交到PrepRequestProcessor的队列中(2) 作为集群的leader，在LearnerHanler.run方法中接收learner向leader发送的投票请求，消息类型为Leader.REQUESTPrepRequestProcessor的处理流程：(1) 对于非事物性请求：sync,exists, getData, getChildRen,ping, setWatches 这里只做session的检查看看是否超时(2) 对于事务请求：create, delete,setData,setAcl,check,multi,根据请求的类型创建不同的操作如：type=create è CreateR
这部分内容我们主要讲解zookeeper请求在zookeeper server端的处理流程，对于不同角色的zookeeper具有不同的处理流程， ZookeepeerServer的start方法中会调用setupRequestProcessors()来初始化处理器链，它被子类覆写实现。1. LeaderZooKeeperServer看如上代码主要建立了如下的两个处理器流链(1) PrepRequestProcessor(线程) => ProposalRequestProcessor(调initialize) =>CommitProcessor(线程) => Leader.ToBeAppliedRequestProcessor=>FinalRequestProcessor(2) ProposalRequestProcessor构造器设置另一处理器链, initialize方法启动SyncRequestProcessor线程 SyncRequestProcessor(线程）=> AckRequestProcessor2. Follo
1. Zookeeper集群一旦选举leader后， leader跟follower，observer之间会进行一些列的交互产生epoch，数据同步操作， 以及后续操作的投票处理决策等操作，这些交互过程其实挺复杂的，zookeeper的代码个人觉的没有整理的很清晰导致深入细节的时候看起来很费劲，下面我就对他们之间的交互做整体并尽可能细致的介绍3.1）如下图leader.lead()方法创建并启动LearnerCnxAcceptor线程用来侦听follower.followLeader()或者observer.observerLeader()中通过connectToLeader(addr)来连接leader， 每个连接会构建一个LearnerHandler线程对象来专门负责处理。由于follower与observer的差别在于observer不参与选举投票其他都类似，所以下面我就以leader跟follower的交互进行讲解。3.2）leader通过投票获取个sever的lastAccpetEpoch决策出最新的3.2.1）leader构建LearnerCnxAcceptor