Zookeeper（三）通信机制

Zookeeper 的通信架构

client 与 follower 之间

client 与 follower 之间采用 NIO（非阻塞 IO）的通信方式。当 client 需要与 Zookeeper service 打交道时，首先读取配置文件确定集群内的所有 server 列表，按照一定的 load balance 算法选取一个 follower 作为一个通信目标。这样 client 和 follower 之间就有了一条由 NIO 模式构成的通信通道。这条通道会一直保持到 client 关闭 session 或者因为 client 或 follower 任一方因某种原因异常中断通信连接（正常情况下, client 与 follower 在没有请求发起的时候都有心跳检测）。

follower 与 leader 之间

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

集群在选择 leader 过程中

系统默认提供了 3 种选择算法，AuthFastLeaderElection，FastLeaderElection，LeaderElection。其中 AuthFastLeaderElection 和 LeaderElection 采用 UDP 模式进行通信，而 FastLeaderElection 仍然采用 TCP/IP 模式。

Zookeeper 的通信流程

session 创建

当启动一个 Zookeeper client 的时候，首先按照一定的算法查找出 follower，然后与 follower 建立起 NIO 连接。当连接建立好后，发送 create session 的命令。当 server 收到 create session 命令，先从本地的 session 列表中查找看是否已经存在有相同 session_id，存在则关闭原 session 重新创建新的 session。创建 session 的过程将需要发送到 leader，再由 leader 通知其他 follower，大部分 follower 都将此操作记录到本地日志再通知 leader 后，leader 发送 commit 命令给所有 follower，连接客户端的 follower 返回创建成功的 session 响应。

Zookeeper 查询命令

Zookeeper 查询命令主要用来查询服务器端的数据，而不会更改数据。所有的查询命令都可以即刻从 client 连接的 server 立即返回，不需要 leader 进行协调。查询命令包括：

exists：判断指定 path 的 node 是否存在，如果存在则返回 true，否则返回 false；
getData：从指定 path 获取该 node 的数据；
getACL：获取指定 path 的 ACL；
getChildren：获取指定 path 的 node 的所有孩子结点。

所有的查询命令都可以设置 watcher，通过它来跟踪指定path的数据变化。一旦指定的数据发生变化（create，delete，modified，children_changed，setData，setACL），watcher 监听器被触发，服务端会将数据变化通知给客户端，随后 watcher 即失效，想要永久监听必须重复设置 watcher。

Zookeeper 修改命令

Zookeeper 修改命令主要是用来修改节点数据或结构，或者权限信息。任何修改命令都需要提交到 leader 进行协调，协调完成后才返回。修改命令主要包括：

createSession：请求 server 创建一个session；
create：创建一个节点；
delete：删除一个节点；
setData：修改一个节点的数据；
setACL：修改一个节点的 ACL；
closeSession：请求 server 关闭 session。

任何修改命令都需要 leader 协调。在 leader 的协调过程中，需要 3 次 leader 与 follower 之间的来回请求响应，并且在此过程中还会涉及事务日志的记录。