zookeeper会话流程

会话创建请求

1. I/O 层接受来自客户端的请求,

zookeeper中每个NIOServerCnxn实例维护每一个客户端连接,客户端与服务端的所有通信都是由NIOServerCnxn负责的, 其负责统一接收来自客户端的所有请求, 并将请求从底层网络I/O中完整的读出来

2. 判断是否是客户端会话创建请求

NIOServerCnxn在负责网络通信的同时, 自然也承担了客户端会话的载体, 每一个会话都会对应一个NIOServerCnxn载体,

3. 反序列ConnectRequest请求

一旦确定当前客户端请求是"会话创建"请求, 服务端就可以对其进行反序列化, 并生成一个ConnectRequest请求实体

4. 判断是否是ReadOnly客户端
5. 检查客户端zxid

服务端zxid必定大于客户端zxid,如果小于服务端不接受客户端创建会话的请求

6. 协商sessionTimeOut

会话创建

8. 为客户端生成sessionID
   9.注册会话

向sessiontracker中注册会话, 维护了两个重要的数据结构,sessionWithTimeout和sessionsById,前者根据sessionID保存了会话的超时时间, 而后者根据sessionID保存了所有会话实体

10. 会话激活

分桶策略

11. 生成会话密码

预处理

12. 请求交付给zookeeper的PrepRequestProcessor处理

典型的责任链模式,

13. 创建事务请求头

对于事务请求, zookeeper首先会为其创建事务请求头, 事务请求头是每个zookeeper事务请求非常重要的一部分

14. 创建事务请求体
15. 注册与激活会话

事务处理

16. 将请求交给ProposalRequestProcessor处理器
    三个子处理流程:
    1. Sync流程
    2. Proposal流程
    3. Commit流程
       16-1 Sync

使用SyncRequestProcessor处理器记录事务日志的过程,如果是事务请求会以事务日志的形式记录下来, Leader和Follower服务器的请求处理链路中都会有这个处理器, 完成事务日志记录后, 每个Follower都会向Leader服务器发送ACK消息

16-2 Proposal流程

1. 发起投票
2. 生成提议
3. 广播提议
4. 收集投票
5. 将请求放入 toBeApplied队列
6. 广播Commit消息

16-3: Commit流程

1. 请求交付给CommitProcessor处理器
2. 处理queuedRequests队列请求
3. 标记nextPending
4. 等待Proposal
5. 投票通过
6. 提交请求
    commit流程会对比之前标记的nextPending和committedRequest队列中第一个请求是否一致, 然后交给下一个请求处理器: FinalRequestProcessor

事务应用

17. 交付给FinalRequestProcessor处理器

请求流转到FinalRequestPorcessor处理后首先检查outstandingChanges队列中请求的有效性