华为技术架构师总结分享：Zookeeper请求处理原理分析
数据库的原理
我们知道，数据库是用来储存资料的，只是资料可以储存在内存中或磁盘中。而Zookeeper实际是结合了这两种的，Zookeeper中的资料即会储存在磁盘中以达到持久化的目的，也会同步到内存中以到达快速访问的目的。
事实上，用过Zookeeper的同学应该知道，Zookeeper中有两种型别的节点： 持久化节点 和 临时节点 。
持久化节点：会持久化在磁盘中，除非主动删除，将一直存在。临时节点：不会持久化在磁盘中，只会储存在内存中，建立这个临时节点的Session一旦过期，此临时节点也将自动被删除。
数据库处理资料的原理
作为一个数据库，肯定是要接收客户端建立、修改、删除、查询节点等请求的。
在Zookeeper中对于请求分为两类：
事务性请求非事务性请求事务性请求
Zookeeper通常都是以丛集模式执行的，也就是Zookeeper丛集中各个节点的资料需要保持一致的。但是和Mysql丛集不一样的是：
Mysql丛集中，从服务器是异步从主服务器同步资料的，这中间的间隔时间可以比较长。Zookeeper丛集中，当某一个丛集节点接收到一个写请求操作时，该节点需要将这个写请求操作传送给其他节点，以使其他节点同步执行这个写请求操作，从而达到各个节点上的资料保持一致，也就是资料一致性。我们通常说Zookeeper保证CAP理论中的CP就只这个意思。Zookeeper丛集底层是怎么保证资料一致性的，其实是用的 两阶段提交+过半机制 来保证的，后面会单独写一篇文章来介绍这个的底层实现，感兴趣的可以关注一下我的微信公众号： 1点25
事务性请求包括：更新操作、新增操作、删除操作，结合上面的分析，因为这些操作是会影响资料的，所以要保证这些操作在整个丛集内的事务性，所以这些操作就是事务性请求。
非事务性请求
那么非事务性请求就好理解的，像查询操作、exist操作这些不影响资料的操场，就不需要丛集来保持事务性，所以这些操场就是非事务性请求。
Zookeeper在处理事务性请求时，比处理非事务性请求要复杂很多
资料在磁盘中的表示
假设我们现在在Zookeeper中有一个数据节点，节点名为 /datanode ，内容为 125 ，该节点是持久化节点，所以该节点资讯会储存在档案中。
可能大家都会认为是类似下面这样方式储存在磁盘档案中的，方法一：
节点名节点内容/datanode125
但是除开这种表示方法，还有另外一种表示方法， 快照+事务日志 ，比如方法二：
当前快照：
节点名节点内容/datanode120
当前事务日志：
事务ID操作节点名节点内容修改前节点内容修改后1000010update/datanode1201211000011update/datanode121125
乍一看方法二比方法一要更复杂，并且占用的磁盘更多。但是我们上文提到过，Zookeeper丛集中的节点在处理事务性请求时，需要将 事务操作 同步给其他节点，所以这里的事务操作是一定要进行持久化的，以便在同步给其他节点时出现异常进行补偿。所以就出现了 事务日志 。实际上事务日志还执行资料进行 回滚 ，这个在两阶段提交中也是非常重要的。
那么 快照 又有什么用呢？事务日志一定要有，但是随着时间的推移，日志肯定会越来越多，所以肯定不能持久化历史上所有的日志，所以Zookeeper会定时的进行 快照 ，并删除之前的日志。
那么如果按方法二这么储存资料，在对资料进行查询时就不太方便了。上文说到，Zookeeper为了提高资料的查询速度，会在内存中也储存一份资料，那么内存中的这份资料又该怎么存呢？
资料在内存中的表示
Zookeeper中的资料在内存中的表示其实和上文的方法一很类似，只是Zookeeper中的资料是具有档案目录特点的，说白了就是Zookeeper中的资料节点的名字一定要以 “/” 开头，这样就导致Zookeeper中的资料类似一颗树：
一颗具有父子层级的多叉树，在Zookeeper源代码中叫 DataTree 。
请求处理逻辑
请看下图：
请注意，对于上图，Zookeeper真正的底层实现，zk1是Leader，zk2和zk3是Learner，是根据领导者选举选出来的。
非事务性请求直接读取DataTree上的内容，DataTree是在内存中的，所以会非常快。
总结
这篇文章介绍了Zookeeper在处理请求时的几个核心概念：
事务性请求事务日志快照DataTree两阶段提交end：如果你觉得本文对你有帮助的话，记得关注点赞转发，你的支援就是我更新动力。
