在ZooKeeper源码解析(7)-请求处理(上)的末尾，我们只是提到主要处理请求的方法是PreRequestProcessor中的pRequest()方法，而并没有深入的介绍这个方法的实现．
在这篇文章中，我会介绍创建节点这种请求的处理过程．其他的请求，跟它类似，就不一一深入介绍了．
我们先大体看一下pRequest()方法的实现．
我们可以看到，对于每个请求，都会创建对应的Request对象，然后通过pRequest2Txn()方法进行调用．
上面我们贴出了处理CreateRequest的全部代码．
注释中基本上已经写的很详细了．
这里主要就是总结一下过程：
- 验证Session是否有效
- 验证要创建的节点的路径是否正确
- 验证客户端是否有权限创建节点
- 创建对应类型的节点的ChangeRecord，主要有下面几种类型:
- PERSISTENT
- PERSISTENT_SEQUENTIAL
- EPHEMERAL
- EPHEMERAL_SEQUENTIAL
- 如果要创建SEQUENTIAL类型的节点，那么先生成一个顺序的路径名
- 创建一个代表此次操作的CreateTxn
我们可以看到，上面只是创建了ChangeRecord以及CreateTxn，而并没有把它进行持久化，或者应用到DataTree中．
这是为什么呢？
因为这只是PreRequestProcessor中进行的操作，后面还有好几个RequestProcessor等着进行操作呢．
要将ChangeRecord应用到DataTree，我们首先需要Leader根据Zab算法确定此次操作能够被多半Follower知道吧．
所以这里才不会应用到DataTree．
另外，上面代码中的还涉及到了ACL．
ZooKeeper中内置了下面几种ACL permission以及Schema：
经过PreRequestProcessor的处理之后，只是进行了第一步的处理，后面还有其他的处理．
我们从LeaderZooKeeperServer的setupRequestProcessor()方法中，可以看到，它设置了好几个RequestProcessor，来对请求进行一系列的处理．
我们可以看到，LeaderZooKeeperServer就设置了这么几个RequestProcessor: PreRequestProcessor -> ProposalRequestProcessor -> CommitProcessor -> ToBeAppliedRequestProcessor -> FinalRequestProcessor
其处理过程如下：
- 对请求进行预处理
- 通过Zab算法确定能够提交
- 如果收到了半数Follower的同意，则提交Proposal
- 应用到DataTree
- 给客户端一个回复
基本上一个请求的处理就是这样，其它的我也没有细看，应该都差不多．请读者自行阅读源码来了解其他请求的处理过程．
