深入了解Zookeeper核心原理

之前的文章Zookeeper基础原理&应用场景详解中将Zookeeper的基本原理及其应用场景做了一个详细的介绍,虽然介绍了其底层的存储原理、如何使用Zookeeper来实现分布式锁。但是我认为这样也仅仅只是了解了Zookeeper的一点皮毛而已。所以这篇文章就给大家详细聊聊Zookeeper的核心底层原理。不太熟悉Zookeeper的可以回过头去看看。

ZNode

这个应该算是Zookeeper中的基础,数据存储的最小单元。在Zookeeper中,类似文件系统的存储结构,被Zookeeper抽象成了树,树中的每一个节点(Node)被叫做ZNode。ZNode中维护了一个数据结构,用于记录ZNode中数据更改的版本号以及ACL(Access Control List)的变更。

有了这些数据的版本号以及其更新的Timestamp,Zookeeper就可以验证客户端请求的缓存是否合法,并协调更新。

而且,当Zookeeper的客户端执行更新或者删除操作时,都必须要带上要修改的对应数据的版本号。如果Zookeeper检测到对应的版本号不存在,则不会执行这次更新。如果合法,在ZNode中数据更新之后,其对应的版本号也会一起更新

继续阅读深入了解Zookeeper核心原理

Zookeeper基础原理&应用场景详解

简单了解Zookeeper

Tips: 如果之前对Zookeeper不了解的话,这里大概留个印象就好了

Zookeeper是一个分布式协调服务,可以用于元数据管理、分布式锁、分布式协调、发布订阅、服务命名等等。

例如,Kafka中就是用Zookeeper来保存其集群中的相关元数据,例如Broker、Topic以及Partition等等。同时,基于Zookeeper的Watch监听机制,还可以用其实现发布、订阅的功能。

在平常的常规业务使用场景下,我们几乎只会使用到分布式锁这一个用途。

Zookeeper内部运行机制

Zookeeper的底层存储原理,有点类似于Linux中的文件系统。Zookeeper中的文件系统中的每个文件都是节点(Znode)。根据文件之间的层级关系,Zookeeper内部就会形成这个这样一个文件树。

在Linux中,文件(节点)其实是分类型的,例如分为文件、目录。在Zookeeper中同理,Znode同样的有类型。在Zookeeper中,所有的节点类型如下:

继续阅读Zookeeper基础原理&应用场景详解

详细了解 InnoDB 内存结构及其原理

最近发现,文章太长的话,包含的信息量较大, 并且需要更多的时间去阅读。而大家看文章,应该都是利用的一些碎片时间。所以我得出一个结论,文章太长不太利于大家的吸收和消化。所以我之后会减少文章的长度,2-3K字就差不多,也能够快速的阅读完。

之前写过一篇文章「简单了解InnoDB原理」,现在回过头看,其实里面只是把缓冲池(Buffer Pool),重做日志缓冲(Redo Log Buffer)、插入缓冲(Insert Buffer)和自适应哈希索引(Adaptive Hash Index)等概念简单的介绍了一下。

除此之外还聊了一下MySQL和InnoDB的日志,和两次写,总的来说算是一个入门级别的介绍,这篇文章就来详细介绍一下InnoDB的内存结构

InnoDB内存结构

其大致结构如下图。

InnoDB内存的两个主要区域分别为Buffer PoolLog Buffer,此处的Log Buffer目前是用于缓存Redo Log。而Buffer Pool则是MySQL或者说InnoDB中,十分重要、核心的一部分,位于主存。这也是为什么其访问数据的效率高,你可以暂时把它理解成Redis那样的内存数据库,因为我们更新和新增当然它不是,只是这样会更加方便我们理解。

继续阅读详细了解 InnoDB 内存结构及其原理