ZooKeeper 是如何处理一次 create 请求的？
我们知道 Session 的产生时机是客户端和服务端建立连接，那建立完连接干嘛呢？肯定是要通信，也就是 CRUD 增删改查操作，比如客户端发送一个 create 请求给服务端，再比如客户端发送一个 get 请求给服务端……
今天我们就来剖析下客户端发送给服务端一个 create 请求都需要进行哪些操作。
一、带着问题剖析原理
如果是写请求，那么只能由 Leader 来完成；如果写请求打到了 Follower/Observer 的话，会直接将请求转发给 Leader 处理。
那就涉及到了三个问题：
- 客户端如何发起请求给服务端？
- 服务端是如何接收请求的呢？
- 如果发起的
create请求到 Follower 节点了，那么 Follower 是怎么将请求转发到 Leader 上去的？
假设 Leader 接收到 Follower 转发过来的 create 请求了，那 Leader 是如何处理的呢？这就又产生了第四个问题：
- Leader 如何处理一次
create请求？
其实第三个问题比较广泛，但是我们可想而知的是：Leader 肯定要将 create 请求的数据同步给 Follower 和 Observer 一份，且要保证集群各个节点的数据一致性。那这块是如何实现的呢？
- Leader 如何将数据同步给 Follower 的？
- Leader 如何将数据同步给 Observer 的？
- ZooKeeper 数据同步通过什么机制保证集群内各个节点的数据一致性？
接下来我们就剖析这些问题的实现原理，这些问题搞定了后，一次 create 请求的全过程也自然就明白了。我们先来看第一个问题
二、客户端如何发起请求给服务端？
我们先短暂地回忆一下 Leader 选举的时候是如何将请求互相广播出去的，好像并不是直接交由网络，而是先放到一个内存队列（BlockingQueue）里，然后开辟一个线程不断地从队列里获取数据，最后再将数据通过网络广播出去。其实不管是 Leader 选举，还是客户端与服务端通信建立连接，ZooKeeper 的网络通信都是这么玩的。
我们直接画个流程图来阐述下这个流程：
其实总结一下就是：放到内存队列里，然后开个线程从队列里不停地获取数据，最终由网络发送给服务端。 那服务端是如何接收并处理的呢？
服务端接收就更简单了，既然“你小子”（客户端）是通过网络传输过来的，那我（服务端）自然要通过网络接收你传的这份数据，但是接收完请求就涉及到上面的第三个问题了：这时候有很多节点可以处理请求，假设请求没落在 Leader 上，而是落到了 Follower 上，这时候 Follower 需要把请求转发给 Leader，怎么转发？还是一样的，通过网络转发，然后 Leader 再继续通过网络接收请求。
Leader 接收到 create 请求后该如何处理呢？接下来就剖析下这块原理。
三、Leader 如何处理 create 请求？
我们现有以下几个已知问题：
- Leader 如何将数据同步给 Follower 的？
- Leader 如何将数据同步给 Observer 的？
- ZooKeeper 数据同步通过什么机制保证集群内各个节点的数据一致性？
我们先看 Leader 是采取什么方式将数据同步给其他节点的。
有的同学可能知道 Leader 采取的是 ZAB 协议，ZAB 协议一言以蔽之就是为 ZooKeeper 专门设计的一种支持崩溃恢复和原子广播的协议。 关于 ZAB 的知识我们后面会单独详细剖析它，此处我们先不关心 ZAB 这三个字母是干啥的。
