ZooKeeper部分通信总结及后续内容简介

ZooKeeper部分通信总结及后续内容简介

文章目录

• 2021SC@SDUSC
• 前言
• ZooKeeper通信模型
• 服务端与客户端的通信流程
• Client、Follower和Leader三者之间的通信关系
• 总结

2021SC@SDUSC 前言

前面几篇文章对ServerCnxn以及ServerCnxnFactory源码进行了分析和解读。本章将对上述服务端连接进行细节讲解和总结，以进一步了解服务端连接的内容。

ZooKeeper通信模型

这里将用通信模型图来从全局观察ZooKeeper服务端与客户端、服务端与服务端之间是如何通信的。

说明：Client与Follower之间默认通信采用NIO，通过设置配置可采用Netty，而Leader和Follower之间通信采用TCP/IP模式。
1、request：客户端发起请求
2、request：向Leader发起请求，该请求为了进行同步（包括日志信息、数据等等），至于如何同步的，可自行查阅Leader与Follower之间的消息同步机制
3、proposal：Leader对Follower进行回应
4、ack：Follower受到Leader的回应后进行处理反馈给Leader
5、commit：提交处理结果
6、response：客户端接收请求的反馈结果

服务端与客户端的通信流程

1、服务端开启集群（QuorumPeer）==> 启动ServerCnxnFactory服务器连接工厂对之后产生的连接进行维护(至于如何维护的，前几篇的ServerCnxnFactory源码分析进行了说明)，默认为NIO服务端，同时监听2181端口 ==> 当接收到客户端发起的连接请求，则生成ServerCnxn，默认为NIO，即为当前客户端月服务端生成连接(前几篇源码分析中介绍了ServerCnxn服务连接的属性以及为维护该连接的ServerCnxnFactory提供了完善的方法接口) ==> 当客户端与服务端之间生成通信连接后，会创建一个Session对象(后续将对Session源码进行分析)，以便客户端与服务端之间进行通信。
2、客户端开启ZooKeeper ==> 初始化ClientCnxn对象，向服务端发起ConnectionRequest连接请求(后续将对ClientCnxn源码进行分析)

Client、Follower和Leader三者之间的通信关系

Client与Follower之间的通信关系
首先，Client和Follower之间默认采用NIO的通信方式。当Client需要服务时，会读取配置文件确定集群中所有服务器，按照一定的Load Balance算法选取一个Follower作为通信目标，然后发起ConnectionRequest，然后Follower进行一系列 *** 作后建立起这个通信连接通道。这样Client和Follower之间就有了一条由NIO模式构成的通信通道。这条通道会一直保持到Client关闭Session或者因为Client或Follower任一方因某种原因异常中断通信连接。

Follower与Leader之间的通信关系
Follower与Leader之间的通信主要是因为Follower接收到像（create, delete, setData, setACL, createSession, closeSession, sync）这样一些需要让Leader来协调最终结果的命令，将会导致Follower与Leader之间产生通信。由于Leader与Follower之间的关系式一对多的关系，非常适合Client/Server模式，因此他们之间是采用C/S模式，由Leader创建一个socket server，监听各Follower的协调请求。

Server与Server之间的通信关系
当集群中没有选举出Leader时，集群中的所有的Server之间需要进行通信从而选举出Leader。Zookeeper在这个过程中采用了策略模式，可用动态插入选择leader的算法。系统默认提供了3种选择算法，AuthFastLeaderElection，FastLeaderElectionLeaderElection。其中AuthFastLeaderElection和LeaderElection采用UDP模式进行通信，而FastLeaderElection仍然采用TCP/IP模式进行通信。

总结

本章对前面源码分析的内容进行了一次总结，以深入了解通信连接的内容。同时对后续工作的展开进行了说明，即对Session和ClientCnxn等源码进行解读和分析。