本文转载自公众号
程序员小灰
Zookeeper的数据模型
Zookeeper的数据模型是什么样子呢?它很像数据结构当中的树,也很像文件系统的目录。
树是由节点所组成,Zookeeper的数据存储也同样是基于节点,这种节点叫做Znode。
但是,不同于树的节点,Znode的引用方式是路径引用,类似于文件路径:
/ 动物 / 仓鼠
/ 植物 / 荷花
这样的层级结构,让每一个Znode节点拥有唯一的路径,就像命名空间一样对不同信息作出清晰的隔离。
data:
Znode存储的数据信息。
ACL:
记录Znode的访问权限,即哪些人或哪些IP可以访问本节点。
stat:
包含Znode的各种元数据,比如事务ID、版本号、时间戳、大小等等。
child:
当前节点的子节点引用,类似于二叉树的左孩子右孩子。
这里需要注意一点,Zookeeper是为读多写少的场景所设计。Znode并不是用来存储大规模业务数据,而是用于存储少量的状态和配置信息,每个节点的数据最大不能超过1MB。
Zookeeper的基本操作和事件通知
Zookeeper包含了哪些基本操作呢?这里列举出比较常用的API:
create
创建节点
delete
删除节点
exists
判断节点是否存在
getData
获得一个节点的数据
setData
设置一个节点的数据
getChildren
获取节点下的所有子节点
这其中,exists,getData,getChildren属于读操作。Zookeeper客户端在请求读操作的时候,可以选择是否设置Watch。
Watch是什么意思呢?
我们可以理解成是注册在特定Znode上的触发器。当这个Znode发生改变,也就是调用了create,delete,setData方法的时候,将会触发Znode上注册的对应事件,请求Watch的客户端会接收到异步通知。
具体交互过程如下:
1.客户端调用getData方法,watch参数是true。服务端接到请求,返回节点数据,并且在对应的哈希表里插入被Watch的Znode路径,以及Watcher列表。
2.当被Watch的Znode已删除,服务端会查找哈希表,找到该Znode对应的所有Watcher,异步通知客户端,并且删除哈希表中对应的Key-Value。
Zookeeper的一致性
Zookeeper的集群长成什么样呢?就像下图这样:
Zookeeper Service集群是一主多从结构。
在更新数据时,首先更新到主节点(这里的节点是指服务器,不是Znode),再同步到从节点。
在读取数据时,直接读取任意从节点。
为了保证主从节点的数据一致性,Zookeeper采用了ZAB协议,这种协议非常类似于一致性算法Paxos和Raft。
在学习ZAB之前,我们需要首先了解ZAB协议所定义的三种节点状态:
Looking :选举状态。
Following :Follower节点(从节点)所处的状态。
Leading :Leader节点(主节点)所处状态。
我们还需要知道最大ZXID的概念:
最大ZXID也就是节点本地的最新事务编号,包含epoch和计数两部分。epoch是纪元的意思,相当于Raft算法选主时候的term。
假如Zookeeper当前的主节点挂掉了,集群会进行崩溃恢复。ZAB的崩溃恢复分成三个阶段:
1.Leader election
选举阶段,此时集群中的节点处于Looking状态。它们会各自向其他节点发起投票,投票当中包含自己的服务器ID和最新事务ID(ZXID)。
接下来,节点会用自身的ZXID和从其他节点接收到的ZXID做比较,如果发现别人家的ZXID比自己大,也就是数据比自己新,那么就重新发起投票,投票给目前已知最大的ZXID所属节点。
每次投票后,服务器都会统计投票数量,判断是否有某个节点得到半数以上的投票。如果存在这样的节点,该节点将会成为准Leader,状态变为Leading。其他节点的状态变为Following。
这就相当于,一群武林高手经过激烈的竞争,选出了武林盟主。
2.Discovery
发现阶段,用于在从节点中发现最新的ZXID和事务日志。或许有人会问:既然Leader被选为主节点,已经是集群里数据最新的了,为什么还要从节点中寻找最新事务呢?
这是为了防止某些意外情况,比如因网络原因在上一阶段产生多个Leader的情况。
所以这一阶段,Leader集思广益,接收所有Follower发来各自的最新epoch值。Leader从中选出最大的epoch,基于此值加1,生成新的epoch分发给各个Follower。
各个Follower收到全新的epoch后,返回ACK给Leader,带上各自最大的ZXID和历史事务日志。Leader选出最大的ZXID,并更新自身历史日志。
3.Synchronization
同步阶段,把Leader刚才收集得到的最新历史事务日志,同步给集群中所有的Follower。只有当半数Follower同步成功,这个准Leader才能成为正式的Leader。
自此,故障恢复正式完成。
什么是Broadcast呢?简单来说,就是Zookeeper常规情况下更新数据的时候,由Leader广播到所有的Follower。其过程如下:
1.客户端发出写入数据请求给任意Follower。
2.Follower把写入数据请求转发给Leader。
3.Leader采用二阶段提交方式,先发送Propose广播给Follower。
4.Follower接到Propose消息,写入日志成功后,返回ACK消息给Leader。
5.Leader接到半数以上ACK消息,返回成功给客户端,并且广播Commit请求给Follower。
Zab协议既不是强一致性,也不是弱一致性,而是处于两者之间的单调一致性。它依靠事务ID和版本号,保证了数据的更新和读取是有序的。
Zookeeper的应用
1.分布式锁
这是雅虎研究员设计Zookeeper的初衷。利用Zookeeper的临时顺序节点,可以轻松实现分布式锁。
2.服务注册和发现
利用Znode和Watcher,可以实现分布式服务的注册和发现。最著名的应用就是阿里的分布式RPC框架Dubbo。
3.共享配置和状态信息
Redis的分布式解决方案Codis,就利用了Zookeeper来存放数据路由表和 codis-proxy 节点的元信息。同时 codis-config 发起的命令都会通过 ZooKeeper 同步到各个存活的 codis-proxy。
此外,Kafka、HBase、Hadoop,也都依靠Zookeeper同步节点信息,实现高可用。
几点补充:
1.ZAB协议相对比较复杂,小灰对此也只是浅层次的理解,有兴趣的小伙伴们可以去官方社区进行进一步学习。
————————————
Zookeeper的数据模型
Zookeeper的数据模型是什么样子呢?它很像数据结构当中的树,也很像文件系统的目录。
树是由节点所组成,Zookeeper的数据存储也同样是基于节点,这种节点叫做Znode。
但是,不同于树的节点,Znode的引用方式是路径引用,类似于文件路径:
/ 动物 / 仓鼠
/ 植物 / 荷花
这样的层级结构,让每一个Znode节点拥有唯一的路径,就像命名空间一样对不同信息作出清晰的隔离。
data:
Znode存储的数据信息。
ACL:
记录Znode的访问权限,即哪些人或哪些IP可以访问本节点。
stat:
包含Znode的各种元数据,比如事务ID、版本号、时间戳、大小等等。
child:
当前节点的子节点引用,类似于二叉树的左孩子右孩子。
这里需要注意一点,Zookeeper是为读多写少的场景所设计。Znode并不是用来存储大规模业务数据,而是用于存储少量的状态和配置信息,每个节点的数据最大不能超过1MB。
Zookeeper的基本操作和事件通知
Zookeeper包含了哪些基本操作呢?这里列举出比较常用的API:
create
创建节点
delete
删除节点
exists
判断节点是否存在
getData
获得一个节点的数据
setData
设置一个节点的数据
getChildren
获取节点下的所有子节点
这其中,exists,getData,getChildren属于读操作。Zookeeper客户端在请求读操作的时候,可以选择是否设置Watch。
Watch是什么意思呢?
我们可以理解成是注册在特定Znode上的触发器。当这个Znode发生改变,也就是调用了create,delete,setData方法的时候,将会触发Znode上注册的对应事件,请求Watch的客户端会接收到异步通知。
具体交互过程如下:
1.客户端调用getData方法,watch参数是true。服务端接到请求,返回节点数据,并且在对应的哈希表里插入被Watch的Znode路径,以及Watcher列表。
2.当被Watch的Znode已删除,服务端会查找哈希表,找到该Znode对应的所有Watcher,异步通知客户端,并且删除哈希表中对应的Key-Value。
Zookeeper的一致性
Zookeeper的集群长成什么样呢?就像下图这样:
Zookeeper Service集群是一主多从结构。
在更新数据时,首先更新到主节点(这里的节点是指服务器,不是Znode),再同步到从节点。
在读取数据时,直接读取任意从节点。
为了保证主从节点的数据一致性,Zookeeper采用了ZAB协议,这种协议非常类似于一致性算法Paxos和Raft。
在学习ZAB之前,我们需要首先了解ZAB协议所定义的三种节点状态:
Looking :选举状态。
Following :Follower节点(从节点)所处的状态。
Leading :Leader节点(主节点)所处状态。
我们还需要知道最大ZXID的概念:
最大ZXID也就是节点本地的最新事务编号,包含epoch和计数两部分。epoch是纪元的意思,相当于Raft算法选主时候的term。
假如Zookeeper当前的主节点挂掉了,集群会进行崩溃恢复。ZAB的崩溃恢复分成三个阶段:
1.Leader election
选举阶段,此时集群中的节点处于Looking状态。它们会各自向其他节点发起投票,投票当中包含自己的服务器ID和最新事务ID(ZXID)。
接下来,节点会用自身的ZXID和从其他节点接收到的ZXID做比较,如果发现别人家的ZXID比自己大,也就是数据比自己新,那么就重新发起投票,投票给目前已知最大的ZXID所属节点。
每次投票后,服务器都会统计投票数量,判断是否有某个节点得到半数以上的投票。如果存在这样的节点,该节点将会成为准Leader,状态变为Leading。其他节点的状态变为Following。
这就相当于,一群武林高手经过激烈的竞争,选出了武林盟主。
2.Discovery
发现阶段,用于在从节点中发现最新的ZXID和事务日志。或许有人会问:既然Leader被选为主节点,已经是集群里数据最新的了,为什么还要从节点中寻找最新事务呢?
这是为了防止某些意外情况,比如因网络原因在上一阶段产生多个Leader的情况。
所以这一阶段,Leader集思广益,接收所有Follower发来各自的最新epoch值。Leader从中选出最大的epoch,基于此值加1,生成新的epoch分发给各个Follower。
各个Follower收到全新的epoch后,返回ACK给Leader,带上各自最大的ZXID和历史事务日志。Leader选出最大的ZXID,并更新自身历史日志。
3.Synchronization
同步阶段,把Leader刚才收集得到的最新历史事务日志,同步给集群中所有的Follower。只有当半数Follower同步成功,这个准Leader才能成为正式的Leader。
自此,故障恢复正式完成。
什么是Broadcast呢?简单来说,就是Zookeeper常规情况下更新数据的时候,由Leader广播到所有的Follower。其过程如下:
1.客户端发出写入数据请求给任意Follower。
2.Follower把写入数据请求转发给Leader。
3.Leader采用二阶段提交方式,先发送Propose广播给Follower。
4.Follower接到Propose消息,写入日志成功后,返回ACK消息给Leader。
5.Leader接到半数以上ACK消息,返回成功给客户端,并且广播Commit请求给Follower。
Zab协议既不是强一致性,也不是弱一致性,而是处于两者之间的单调一致性。它依靠事务ID和版本号,保证了数据的更新和读取是有序的。
Zookeeper的应用
1.分布式锁
这是雅虎研究员设计Zookeeper的初衷。利用Zookeeper的临时顺序节点,可以轻松实现分布式锁。
2.服务注册和发现
利用Znode和Watcher,可以实现分布式服务的注册和发现。最著名的应用就是阿里的分布式RPC框架Dubbo。
3.共享配置和状态信息
Redis的分布式解决方案Codis,就利用了Zookeeper来存放数据路由表和 codis-proxy 节点的元信息。同时 codis-config 发起的命令都会通过 ZooKeeper 同步到各个存活的 codis-proxy。
此外,Kafka、HBase、Hadoop,也都依靠Zookeeper同步节点信息,实现高可用。
几点补充:
1.ZAB协议相对比较复杂,小灰对此也只是浅层次的理解,有兴趣的小伙伴们可以去官方社区进行进一步学习。
2.本漫画纯属娱乐,还请大家尽量珍惜当下的工作,切勿模仿小灰的行为哦。
最后给大家推荐一个牛逼的公号,stormzhang,大家都喊他张哥,GitHub 中国区前十开发者,非科班 0 基础自学的编程,后又从技术转型管理与产品,目前在某创业公司担任技术产品负责人。
张哥的公众号主要分享自己过来人的真实经验,包括编程、职场、思维与互联网等,其中很多观点对技术人的认知有很大提升,我自己也一直在关注,强烈推荐大家关注。
————————————
Zookeeper的数据模型
Zookeeper的数据模型是什么样子呢?它很像数据结构当中的树,也很像文件系统的目录。
树是由节点所组成,Zookeeper的数据存储也同样是基于节点,这种节点叫做Znode。
但是,不同于树的节点,Znode的引用方式是路径引用,类似于文件路径:
/ 动物 / 仓鼠
/ 植物 / 荷花
这样的层级结构,让每一个Znode节点拥有唯一的路径,就像命名空间一样对不同信息作出清晰的隔离。
data:
Znode存储的数据信息。
ACL:
记录Znode的访问权限,即哪些人或哪些IP可以访问本节点。
stat:
包含Znode的各种元数据,比如事务ID、版本号、时间戳、大小等等。
child:
当前节点的子节点引用,类似于二叉树的左孩子右孩子。
这里需要注意一点,Zookeeper是为读多写少的场景所设计。Znode并不是用来存储大规模业务数据,而是用于存储少量的状态和配置信息,每个节点的数据最大不能超过1MB。
Zookeeper的基本操作和事件通知
Zookeeper包含了哪些基本操作呢?这里列举出比较常用的API:
create
创建节点
delete
删除节点
exists
判断节点是否存在
getData
获得一个节点的数据
setData
设置一个节点的数据
getChildren
获取节点下的所有子节点
这其中,exists,getData,getChildren属于读操作。Zookeeper客户端在请求读操作的时候,可以选择是否设置Watch。
Watch是什么意思呢?
我们可以理解成是注册在特定Znode上的触发器。当这个Znode发生改变,也就是调用了create,delete,setData方法的时候,将会触发Znode上注册的对应事件,请求Watch的客户端会接收到异步通知。
具体交互过程如下:
1.客户端调用getData方法,watch参数是true。服务端接到请求,返回节点数据,并且在对应的哈希表里插入被Watch的Znode路径,以及Watcher列表。
2.当被Watch的Znode已删除,服务端会查找哈希表,找到该Znode对应的所有Watcher,异步通知客户端,并且删除哈希表中对应的Key-Value。
Zookeeper的一致性
Zookeeper的集群长成什么样呢?就像下图这样:
Zookeeper Service集群是一主多从结构。
在更新数据时,首先更新到主节点(这里的节点是指服务器,不是Znode),再同步到从节点。
在读取数据时,直接读取任意从节点。
为了保证主从节点的数据一致性,Zookeeper采用了ZAB协议,这种协议非常类似于一致性算法Paxos和Raft。
在学习ZAB之前,我们需要首先了解ZAB协议所定义的三种节点状态:
Looking :选举状态。
Following :Follower节点(从节点)所处的状态。
Leading :Leader节点(主节点)所处状态。
我们还需要知道最大ZXID的概念:
最大ZXID也就是节点本地的最新事务编号,包含epoch和计数两部分。epoch是纪元的意思,相当于Raft算法选主时候的term。
假如Zookeeper当前的主节点挂掉了,集群会进行崩溃恢复。ZAB的崩溃恢复分成三个阶段:
1.Leader election
选举阶段,此时集群中的节点处于Looking状态。它们会各自向其他节点发起投票,投票当中包含自己的服务器ID和最新事务ID(ZXID)。
接下来,节点会用自身的ZXID和从其他节点接收到的ZXID做比较,如果发现别人家的ZXID比自己大,也就是数据比自己新,那么就重新发起投票,投票给目前已知最大的ZXID所属节点。
每次投票后,服务器都会统计投票数量,判断是否有某个节点得到半数以上的投票。如果存在这样的节点,该节点将会成为准Leader,状态变为Leading。其他节点的状态变为Following。
这就相当于,一群武林高手经过激烈的竞争,选出了武林盟主。
2.Discovery
发现阶段,用于在从节点中发现最新的ZXID和事务日志。或许有人会问:既然Leader被选为主节点,已经是集群里数据最新的了,为什么还要从节点中寻找最新事务呢?
这是为了防止某些意外情况,比如因网络原因在上一阶段产生多个Leader的情况。
所以这一阶段,Leader集思广益,接收所有Follower发来各自的最新epoch值。Leader从中选出最大的epoch,基于此值加1,生成新的epoch分发给各个Follower。
各个Follower收到全新的epoch后,返回ACK给Leader,带上各自最大的ZXID和历史事务日志。Leader选出最大的ZXID,并更新自身历史日志。
3.Synchronization
同步阶段,把Leader刚才收集得到的最新历史事务日志,同步给集群中所有的Follower。只有当半数Follower同步成功,这个准Leader才能成为正式的Leader。
自此,故障恢复正式完成。
什么是Broadcast呢?简单来说,就是Zookeeper常规情况下更新数据的时候,由Leader广播到所有的Follower。其过程如下:
1.客户端发出写入数据请求给任意Follower。
2.Follower把写入数据请求转发给Leader。
3.Leader采用二阶段提交方式,先发送Propose广播给Follower。
4.Follower接到Propose消息,写入日志成功后,返回ACK消息给Leader。
5.Leader接到半数以上ACK消息,返回成功给客户端,并且广播Commit请求给Follower。
Zab协议既不是强一致性,也不是弱一致性,而是处于两者之间的单调一致性。它依靠事务ID和版本号,保证了数据的更新和读取是有序的。
Zookeeper的应用
1.分布式锁
这是雅虎研究员设计Zookeeper的初衷。利用Zookeeper的临时顺序节点,可以轻松实现分布式锁。
2.服务注册和发现
利用Znode和Watcher,可以实现分布式服务的注册和发现。最著名的应用就是阿里的分布式RPC框架Dubbo。
3.共享配置和状态信息
Redis的分布式解决方案Codis,就利用了Zookeeper来存放数据路由表和 codis-proxy 节点的元信息。同时 codis-config 发起的命令都会通过 ZooKeeper 同步到各个存活的 codis-proxy。
此外,Kafka、HBase、Hadoop,也都依靠Zookeeper同步节点信息,实现高可用。
几点补充:
1.ZAB协议相对比较复杂,小灰对此也只是浅层次的理解,有兴趣的小伙伴们可以去官方社区进行进一步学习。
————————————
Zookeeper的数据模型
Zookeeper的数据模型是什么样子呢?它很像数据结构当中的树,也很像文件系统的目录。
树是由节点所组成,Zookeeper的数据存储也同样是基于节点,这种节点叫做Znode。
但是,不同于树的节点,Znode的引用方式是路径引用,类似于文件路径:
/ 动物 / 仓鼠
/ 植物 / 荷花
这样的层级结构,让每一个Znode节点拥有唯一的路径,就像命名空间一样对不同信息作出清晰的隔离。
data:
Znode存储的数据信息。
ACL:
记录Znode的访问权限,即哪些人或哪些IP可以访问本节点。
stat:
包含Znode的各种元数据,比如事务ID、版本号、时间戳、大小等等。
child:
当前节点的子节点引用,类似于二叉树的左孩子右孩子。
这里需要注意一点,Zookeeper是为读多写少的场景所设计。Znode并不是用来存储大规模业务数据,而是用于存储少量的状态和配置信息,每个节点的数据最大不能超过1MB。
Zookeeper的基本操作和事件通知
Zookeeper包含了哪些基本操作呢?这里列举出比较常用的API:
create
创建节点
delete
删除节点
exists
判断节点是否存在
getData
获得一个节点的数据
setData
设置一个节点的数据
getChildren
获取节点下的所有子节点
这其中,exists,getData,getChildren属于读操作。Zookeeper客户端在请求读操作的时候,可以选择是否设置Watch。
Watch是什么意思呢?
我们可以理解成是注册在特定Znode上的触发器。当这个Znode发生改变,也就是调用了create,delete,setData方法的时候,将会触发Znode上注册的对应事件,请求Watch的客户端会接收到异步通知。
具体交互过程如下:
1.客户端调用getData方法,watch参数是true。服务端接到请求,返回节点数据,并且在对应的哈希表里插入被Watch的Znode路径,以及Watcher列表。
2.当被Watch的Znode已删除,服务端会查找哈希表,找到该Znode对应的所有Watcher,异步通知客户端,并且删除哈希表中对应的Key-Value。
Zookeeper的一致性
Zookeeper的集群长成什么样呢?就像下图这样:
Zookeeper Service集群是一主多从结构。
在更新数据时,首先更新到主节点(这里的节点是指服务器,不是Znode),再同步到从节点。
在读取数据时,直接读取任意从节点。
为了保证主从节点的数据一致性,Zookeeper采用了ZAB协议,这种协议非常类似于一致性算法Paxos和Raft。
在学习ZAB之前,我们需要首先了解ZAB协议所定义的三种节点状态:
Looking :选举状态。
Following :Follower节点(从节点)所处的状态。
Leading :Leader节点(主节点)所处状态。
我们还需要知道最大ZXID的概念:
最大ZXID也就是节点本地的最新事务编号,包含epoch和计数两部分。epoch是纪元的意思,相当于Raft算法选主时候的term。
假如Zookeeper当前的主节点挂掉了,集群会进行崩溃恢复。ZAB的崩溃恢复分成三个阶段:
1.Leader election
选举阶段,此时集群中的节点处于Looking状态。它们会各自向其他节点发起投票,投票当中包含自己的服务器ID和最新事务ID(ZXID)。
接下来,节点会用自身的ZXID和从其他节点接收到的ZXID做比较,如果发现别人家的ZXID比自己大,也就是数据比自己新,那么就重新发起投票,投票给目前已知最大的ZXID所属节点。
每次投票后,服务器都会统计投票数量,判断是否有某个节点得到半数以上的投票。如果存在这样的节点,该节点将会成为准Leader,状态变为Leading。其他节点的状态变为Following。
这就相当于,一群武林高手经过激烈的竞争,选出了武林盟主。
2.Discovery
发现阶段,用于在从节点中发现最新的ZXID和事务日志。或许有人会问:既然Leader被选为主节点,已经是集群里数据最新的了,为什么还要从节点中寻找最新事务呢?
这是为了防止某些意外情况,比如因网络原因在上一阶段产生多个Leader的情况。
所以这一阶段,Leader集思广益,接收所有Follower发来各自的最新epoch值。Leader从中选出最大的epoch,基于此值加1,生成新的epoch分发给各个Follower。
各个Follower收到全新的epoch后,返回ACK给Leader,带上各自最大的ZXID和历史事务日志。Leader选出最大的ZXID,并更新自身历史日志。
3.Synchronization
同步阶段,把Leader刚才收集得到的最新历史事务日志,同步给集群中所有的Follower。只有当半数Follower同步成功,这个准Leader才能成为正式的Leader。
自此,故障恢复正式完成。
什么是Broadcast呢?简单来说,就是Zookeeper常规情况下更新数据的时候,由Leader广播到所有的Follower。其过程如下:
1.客户端发出写入数据请求给任意Follower。
2.Follower把写入数据请求转发给Leader。
3.Leader采用二阶段提交方式,先发送Propose广播给Follower。
4.Follower接到Propose消息,写入日志成功后,返回ACK消息给Leader。
5.Leader接到半数以上ACK消息,返回成功给客户端,并且广播Commit请求给Follower。
Zab协议既不是强一致性,也不是弱一致性,而是处于两者之间的单调一致性。它依靠事务ID和版本号,保证了数据的更新和读取是有序的。
Zookeeper的应用
1.分布式锁
这是雅虎研究员设计Zookeeper的初衷。利用Zookeeper的临时顺序节点,可以轻松实现分布式锁。
2.服务注册和发现
利用Znode和Watcher,可以实现分布式服务的注册和发现。最著名的应用就是阿里的分布式RPC框架Dubbo。
3.共享配置和状态信息
Redis的分布式解决方案Codis,就利用了Zookeeper来存放数据路由表和 codis-proxy 节点的元信息。同时 codis-config 发起的命令都会通过 ZooKeeper 同步到各个存活的 codis-proxy。
此外,Kafka、HBase、Hadoop,也都依靠Zookeeper同步节点信息,实现高可用。
几点补充:
1.ZAB协议相对比较复杂,小灰对此也只是浅层次的理解,有兴趣的小伙伴们可以去官方社区进行进一步学习。