ijbuhv的专栏

zookeeper在经过选举之后，则是会进入恢复阶段，这个阶段leader会从候选的leader变成真正的leader,follower则会根据leader的数据完成自身的事务日志的同步，而同步的相关的代码则主要是zookeeper中的leader,follower和learnerHandler。zookeeper中内部的大部分的协议类型都是在这个阶段进行的。重要概念在具体介绍这个阶段之前，先介绍一下两个比较重要的概念:acceptedEpoch:表示的是NEWEPOCH消息接收的epoch.

current_epoch:当前的epoch，表示的是真实用来选举的epoch，对于leader的epoch则是用过半的follower的lastAcceptedEppoch+1来确定的accepted_epoch:接受的epoch，表示的是收到的leaderInfo的epoch

zookeeper集群方式运行时，单个服务器会开启三个端口，分别负责和客户端连接，进行leader选举以及leader和Follower之间的广播操作。下面图主要的展示了在集群下zookeeper的网络IO情况。这张图主要展示了一个已经稳定了的三个节点的zookeeper集群的网络IO情况，其中主要包括一个Leader和两个Follower节点。可以看到每个节点都可以和客户端进行连接，客户端用ClientCnxn来处理对应的IO，而对于每个节点则是为每条客户端连接分配了一个ServerCnxn来与客

本次阅读的zookeeper的版本是3.4.19zookeeper的数据的持久化主要是依赖两种文件，第一种是snapshot快照文件，一种是log日志文件。对于snapshot文件存储的是这个DataTree和session内存的快照，对于log文件则是顺序存储的事务日志。下面图展示了这两种文件的格式，可以看到这两种文件的后缀都是一个16进制数，对于snapshot文件表示的是在开始这个快照时其对应的最后一个执行的事务id,这表示在做恢复时这个事务id之后的事务都需要重新执行，对于log文件来..

本次阅读的zookeeper的版本是3.4.19RequestProcessor是zookeeper对用户请求的核心处理逻辑之处，RequestProccssor通过构建成不同的调用链来完成不同角色下对请求的处理的逻辑。下面图展示了Leader角色服务器下对事务消息的处理逻辑，其中黑色线条表示的是RequestProcessor的处理链。可以看到它的第一个处理器是PreRequestProcessor,这个处理器的主要作用有鉴权以及事务请求加上TxnHeader等信息。其后面接的是Pro...

本次阅读的zookeeper的版本是3.4.19SessionTrackerImpl主要是来维护客户端和服务器之间的session，它主要是利用一个轮询线程每次tick检查这一帧需要移除的session并将对应的session移除掉。下面是其对应的数据结构，其中白色底的序列表示的是tick的轮次，绿色底的是对应的session。下面代码是对应的轮询线程的代码，代码很简单，可以看到逻辑就是先等待时间达到下次超时检查时间，然后此次超时时间中需要移除的session标识位关闭，并进行相应的cl...

本次阅读的zookeeper的版本是3.4.19前面介绍了Zookeeper的客户端是通过ClientCnxn来与服务端进行交互，与之相对的服务端为每一个客户端连接维护了一个ServerCnxn来进行网络IO操作，而ServerCnxnFactory则是来创建和维护这些ServerCnxn的。ServerCnxnFactory根据其对应的实现方式分为NIOServerCnxnFactory和NettyServerCnxnFactory这两种形式，其中NioServerCnxnFactory是利用.

本次阅读的zookeeper的版本是3.4.19下面的图展示了zookeeper的客户端的主要架构，可以看到用户是利用Zookeeper来进行相应的接口如(getData,getChildren等)的调用，zookeeper会将用户传入的参数包装成一个Packet,这个Packet中维护了Request,Response以及Watch等数据，它会被加入到outgoingQueue中。SendThread这个线程是一个轮询的线程，它的循环会进行IO操作，其中它的write操作会利用ClientCn.