Zookeeper请求处理原理分析

Zookeeper可以存储数据,因此我们可以将其理解为数据库,实际上,它的基本原理本身就类似于数据库。

一,数据库的原理

我们知道数据库用于存储数据,但数据可以存储在内存或磁盘上。 Zookeeper实际上将两者结合起来,ZooKeeper中的数据将以存储在磁盘上为目的进行持久化,并将同步到内存中以实现快速访问。

实际上,使用Zookeeper的学生应该知道Zookeeper中有两种类型的节点:持久节点和临时节点。

持久节点:将保留在磁盘上并将持续存在直到被主动删除。临时节点:它不会保留在磁盘上,只会存储在内存中。创建此临时节点的会话到期后,此临时节点也将自动删除。

二,数据库处理数据的原理

作为数据库,绝对有必要接收来自客户端的请求以创建,修改,删除和查询节点。

Zookeeper中有两种类型的请求:

交易请求非交易请求

1.交易请求

Zookeeper通常以集群模式运行,即Zookeeper集群中每个节点的数据需要保持一致。但与Mysql集群不同:

在Mysql集群中,从服务器异步同步来自主服务器的数据,两者之间的间隔可能相对较长。在ZooKeeper集群中,当集群节点收到写请求操作时,该节点需要将写请求操作发送给其他节点,以便其他节点可以同步执行写请求操作,以使每个节点上的数据保持一致。也就是说,数据的一致性。我们通常说Zookeeper保证CAP理论中的CP仅仅意味着这一点。 Zookeeper集群的底部是如何确保数据一致性。实际上,它由两阶段提交+半通机制保证。

事务性请求包括:更新操作,新操作,删除操作,结合上述分析,因为这些操作会影响数据,因此要确保这些操作在整个集群中是事务性的,这些操作都是事务性请求。

2.非交易请求

然后很好地理解非事务性请求,例如查询操作,存在操作,这些操作不影响操作数据,不需要集群来维护事务性,因此这些操作是非事务性请求。

处理事务请求时Zookeeper比非事务请求更复杂

第三,磁盘上数据的表示

假设我们现在在Zookeeper中有一个数据节点,节点名是/datanode,内容是125.这个节点是一个持久节点,所以节点信息将保存在文件中。

也许每个人都认为它保存在磁盘文件中,如下所示:方法1:

但除此表示外,还有另一种表示快照+事务日志的方法,例如方法二:

当前快照:

当前的交易日志:

乍一看,方法2比方法1更复杂,它占用更多的磁盘。但正如我们上面提到的,Zookeeper集群中的节点在处理事务请求时需要将事务操作同步到其他节点,因此这里的事务操作必须保持不变,以便在与其他节点同步时可以显示它们。补偿异常。所以出现了事务日志。事实上,事务日志还运行回滚数据,这在两阶段提交中也非常重要。

那么快照的用途是什么?事务日志必须在那里,但随着时间的推移,日志肯定会越来越多,因此当然不可能在历史记录中保留所有日志,因此Zookeeper将定期拍摄快照并删除以前的日志。

然后,如果按方法2中所述存储数据,则在查询数据时不方便。如上所述,Zookeeper将数据的副本存储在内存中,以提高数据的查询速度。如何存储内存中的这些数据?

第四,数据在内存中的表示

ZooKeeper中数据的表示类似于上面的方法,只是ZooKeeper中的数据具有文件目录的特征。说白了,Zookeeper中数据节点的名称必须以“/”开头。 Zookeeper中的数据类似于树:

具有父子层次结构的多叉树在Zookeeper源代码中称为DataTree。

V.请求处理逻辑

请参见下图:

请注意,对于上面的图片,Zookeeper的真正底层实现,zk1是Leader,zk2和zk3是Learner,它是根据领导者选举选择的。

非事务性请求直接读取DataTree的内容,DataTree在内存中,因此它将非常快。

六,总结

本文介绍了Zookeeper处理请求时的几个核心概念:

1.交易请求

2,事务日志

3.快照

4,DataTree

5.两阶段提交

——