Zookeeper ZAB协议－客户端源码解析

因为在Zookeeper的底层源码中大量使用了NIO，线程和阻塞队列，在了解之前对前面这些有个基础会更容易理解

ZAB 是Zookeeper 的一种原子广播协议，用于支持Zookeeper 的分布式协调一致性和奔溃恢复的一种，但是ZAB 协议的源码比上一篇Zookeeper的Leader选举算法要复杂一些，所以分多篇进行分析

首先来一张简单的架构图，对Zookeeper客户端架构有个基本概念

这里从客户端开始，我们来看一下zk 的一个简单使用，下面是创建zk客户端，然后创建一个节点

new Zookeeper 见Zookeeper

zookeeper.create见zookeeper.create

Zookeeper客户端初始化

Zookeeper

createConnection 实际上是创建了一个ClientCnxn 对象，在这个对象中保存了一些数据，比如苏红zookeeper自身引用，监视器，sessionId，过期时间，配置信息， 这里我们需要重点关注的是创建了两个线程sendThread，eventThread，这两个线程一个是用于发送数据，一个是用于事件处理的，详见ClientCnxn

zk 客户端启动，详见cnxn.start

ClientCnxn

ClientCnxn

ClientCnxn#start

cnxn.start

这里很简单，就是直接启动了初始化创建的两个线程，sendThread,eventThread, 因为这是两个线程，start 方法实际上是调用了该线程的run 方法

sendThread见 sendThread.run

eventThread 见 sendThread.run

SendThread#run

sendThread.run

因为这里暂时只分析主流程，有些分支流程就暂时先跳过了

这里主要是做了几件事，

1：zookeeper服务端连接，见sendThrad.startConnect

2：发送数据，见 ClientCnxnSocketNIO.doTransport

3：保持心跳连接，见

SendThread#startConnect

sendThrad.startConnect

因为我们这里采用的是默认的模式，在上文中已经创建了ClientCnxnSocketNIO这个对象， 实际上就是使用NIO 的方式进行连接，具体如下图，代码很简单，如果有NIO 的基础，应该很好理解，就不再深入分析

ClientCnxnSocketNIO#doTransport

ClientCnxnSocketNIO.doTransport

我们默认是client 已经和ZK server 连接成功了，,这里线程已经启动完成了，然后阻塞在select 方法上，下面我们走zookeeper.create的逻辑zookeeper.create

当执行完create后，selector 被唤醒了，同时outgoingQueue队列中存在数据，然后会执行后续发送数据的IO 操作，我们来看doIO ClientCnxnSocketNIO#doIO

Zookeeper.create

zookeeper.create

在create方法中，主要是构建了请求参数，然后调用socket 的submitRequest,提交请求服务端，详情见clientCnxn.submitRequest

ClientCnxn.submitRequest

clientCnxn.submitRequest

总结一下：这里主要干下面几件事

1： 将请求参数封装成一个Packet,然后放到outgoingQueue阻塞队列中，然sendThread 处理

2： 将当前线程wait 住， 等待完成或者请求超时后唤醒

3： 请求超时后的一些处理

下面进到ClientCnxn.queuePacket

ClientCnxn.queuePacket

ClientCnxn.queuePacket

ClientCnxnSocketNIO#doIO

ClientCnxnSocketNIO#doIO

在这个方法中主要执行两个步骤，因为代码较长，所以这一块分开进行分析

1：执行写事件

总结一下：

1：从一个outgoingQueue队列中拿到一个Packet 数据， 因为前面我们执行create 逻辑的时候，已经往outgoingQueue中放入数据了，所以这里是存在数据的

2： 如果这个Packet没有创建ByteBuffer，那么创建一个ByteBuffer，并且赋值给packet 对象的bb 属性

3： 利用socket将packet数据发送出去

4：发送完成后，将packet数据添加到一个等待服务端响应的链表中

2：执行读事件

因为zk 请求会先发4个字节作为整个报文的长度，所以会创建一个指定大小的buffer空间来接收后续请求。具体读取数据在SendThread#readResponse

SendThread#readResponse

SendThread#readResponse

总结一下：在上述代码中总共干了几件事

1： 根据返回的数据类型，会走一些其他逻辑，比如心跳，权限认证

2： 如果返回的类型是-1， 说明是监听了节点数据变动后返回的结果，那么会创建一个监听结果事件放入到eventThrad 的waitingEvents 队列中，见EventThread#queueEvent

3： 如果是普通的结果，那么会从等待响应队列pendingQueue中删除这次请求的packet

4： 根据packet 重置一些属性，比如事务id，反序列化响应信息

5： 执行结束packet 的方法，然后执行一些逻辑， 见ClientCnxn#finishPacket

ClientCnxn#finishPacket

ClientCnxn#finishPacket

EventThread#run

eventThread.run

下面来看一下事件处理线程

eventThread run 方法总共执行了两个功能

1： 循环从事件的阻塞队列中获取事件

2： 执行事件 ClientCnxn.processEvent

ClientCnxn.processEvent

ClientCnxn.processEvent

// 这里if 判断比较多，所以只展示了其中的一个同步的逻辑,有些分支逻辑是异步回调的逻辑
if (event instanceof WatcherSetEventPair) {
    // each watcher will process the event
    WatcherSetEventPair pair = (WatcherSetEventPair) event;
    for (Watcher watcher : pair.watchers) {
        try { // 在这里调用了我们传入的watcher 的process方法，实现通知
            watcher.process(pair.event);
        } catch (Throwable t) {
            LOG.error("Error while calling watcher ", t);
        }
    }
  }

EventThread#queueEvent

EventThread#queueEvent