zookeeper之服务端会话请求<十三>

在前面api中，简单介绍了客户端链接zookeeper服务器，客户端开始建立Zookeeper对象，链接状态就会变成CONNECTING状态，同时客户端开始等待服务端返回的建立结果，链接成功后，客户端状态变为CONNECTED（下图显示api中展现的链接状态）

那么咱们再来看一看在建立会话的过程当中，服务器都作了些什么，通常客户端的状态介于CONNECTING和CONNECTED之间,在整个生命周期中，固然还有其余的状态(下图是从官网文档中复制的)，针对客户端的请求，可能的状态转换。若是出现诸如会话超时、权限检查或是客户端主动退出程序等状况，客户端的状态就会直接变动为CLOSE状态。

zookeeper服务端的处理，大致分为1.接求接受；2.会话建立；3预处理；4.事务处理；5.事务应用；6.会话响应。而后去去网上偷了一张图过来（会话建立处理流程示意图），可让你们看的更加懂，那篇博客也能够获益颇多（http://blog.csdn.net/zdy0_2004/article/details/53616146）

 

 

一·接受请求

    NIOServerCnxn负责从底层I/O中读出内容（客户端与服务端的全部通讯都是由NIOServerCnxn负责，维护一个客户端链接），主要处理方法是readConnectRequest

反序列化为readConnectRequest,使用的是jute，前一篇已经介绍，下面是readConnectRequest的主要属性

  private int protocolVersion;

  private long lastZxidSeen;

  private int timeOut;

  private long sessionId;

  private byte[] passwd;

 

判断客户端ZXID，若是大于服务器的ZXID，那么这台服务器将不接受客户端的"会话建立"的请求，返回的msg，其中有句 client must try another server，倒还没看到zk api是否有重试其余服务的😎！

设置超时时间，就是会和zoo.cfg比较。

判断是否须要从新建立会话，而后就是下一步的事情啦。

二·会话建立

在ZooKeeperServer中的createSession中建立会话，为客户端生成集群惟一的sessionID，激活密码sessianpasswd

三·预处理

 以后就将请求交给了PrepRequestProcessor，放入LinkedBlockingQueue<Request> submittedRequests中，建立事务请求

  

四·事务处理

将请求交给ProposalRequestProcessor处理器。与提议相关的处理器，从ProposalRequestProcessor开始，请求的处理将会进入三个子处理流程，分别是Sync流程、Proposal流程、Commit流程。

五·事务应用

交付给FinalRequestProcessor处理器。FinalRequestProcessor处理器检查outstandingChanges队列中请求的有效性， 事务应用。以前的请求处理仅仅将事务请求记录到了事务日志中，而内存数据库中的状态还没有改变，所以，须要将事务变动应用到内存数据库。

六·会话响应

建立响应ConnectResponse。会话建立成功后的响应，包含了当前客户端和服务端之间的通讯协议版本号、会话超时时间、sessionID和会话密码， 序列化ConnectResponse， I/O层发送响应给客户端。