分布式带你走进ZooKeeper

Posted 百家分享汇

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了分布式带你走进ZooKeeper相关的知识,希望对你有一定的参考价值。

    过去的2020断断续续的和大家一起分享了Java踩过的坑,以及对数据结构和算法的相关知识。新的一年,希望能多给大家更多我对技术或其他方面的学习分享,以及个人见解,希望能在新的一年与你共同学习和成长。

  

    下面我们就一起来学习下ZooKeeper。

ZooKeeper使用场景?

    ZooKeeper是一个分布式协调服务,由Apache进行维护。

    ZooKeeper可以视为一个高可用的文件系统。

    ZooKeeper可以用于发布/订阅、负载均衡、命令服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等场景。

    最常见的使用场景莫过于Dubbo、Kafka。在Dubbo主要是以注册中心的角色出现,在Kafka中,主要“担任协调者”的角色,同时也存储了消费者和生产者的信息。

    

 ZooKeeper的特性

    1)顺序一致性。所有客户端看到的服务端数据都是一致的;从同一客户端发起的事务请求,最终将会严格地按照顺序被应用到ZooKeeper中。

    2)原子性。所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的,也就是说,要么整个集群中所有的机器都成功应用了某一个事务,要么都没有应用。

    3)高性能。ZooKeeper将数据全量存储在内存中,所以性能很高。由于ZooKeeper的所有更新和删除都是基于事务,因此ZooKeeper在读多写少的应用场景中性能较好,但写操作频繁,性能会达到下滑。

    4)高可用。ZooKeeper的高可用是基于副本机制实现,ZooKeeper还支持故障恢复。

    

ZooKeeper的数据模型

    ZooKeeper的数据模型是一个树形结构的文件系统。

    树种的结点被称为znode,其中根节点为/,每个节点上都会保存自己的数据和节点信息。znode可以存储数据,并且有一个与之相关联的ACL(Access Control Lists)。由于ZooKeeper的设计目的是为了实现协调服务,而不是作为一个文件存储组件,因此znode存储数据的量被限制1MB以内。

    znoe通过路径被引用。znode节点路径必须是绝对路径。

    znode有以下两种类型:

    A、临时的(EPHEMERAL):客户端会话结束时,临时的znode就会被删除。

    B、持久的(PERSISTENT):除非客户端主动执行删除操作,否则持久的znode不会被ZooKeeper删除。


节点信息

    在znode上有一个顺序标志(Sequential)。若创建znode时,设置了顺序标志,则ZooKeeper会使用计数器为znode添加一个递增的数值,即zxid。ZooKeeper正是利用zxid实现了严格的顺序访问控制能力。这也是ZooKeeper能作为分布式锁的原因。

    每个znode节点,都会维护一个数据结构,叫Stat。里面存储了关于节点的全部状态。如下图所示:


ZooKeeper集群角色

    ZooKeeper在解决分布式数据一致性方面,ZooKeeper并没有直接采用Paxos算法,而是采用了ZAB一致性协议。ZAB可以说是一种选举机制,当Leader节点挂了,系统就不能正常工作。此时,就需要通过ZAB协议选举出新的Leader,来进行故障恢复。我们择日再和你一起学习ZAB的协议实现原理及细节(给自己挖个坑)。

    ZooKeeper集群的高可用就是基于ZAB一致性协议。ZooKeeper集群是一个基于主从复制的高可用集群,每个服务器承担三种角色中的其一。

    1)Leader:负责发起并维护与各Follower及Observer间的心跳。所有的写操作必须要通过Leader完成再由Leader将写操作广播给其他服务器。一个ZooKeeper集群中,同一时间只能有一个工作状态的Leader。相当于每个班只有一个班长。

    2)Follower:Leader发起心跳后,Follower会响应Leader的心跳。Follower可直接处理并返回客户端的读请求,同时会将写请求转发给Leader处理,并且负责在Leader处理写请求时对请求进行投票。一个ZooKeeper集群允许同时存在多个Follower。

    3)Observer:与Follower类似,但无投票权。


ZooKeeper-ACL

    ZooKeeper的权限控制是采用ACL(Access Control Lists)。这个ACL上文我们已经提到过会存储在znode。

    当znode创建时,同时会带上一个ACL,这个ACL决定谁可以对它执行何种操作。

    ACL依赖ZooKeeper客户端认证机制。主要包含以下三种:

    1)digest:用户名和密码来识别客户端

    2)sasl:通过kerberos来识别客户端

    3)ip:通过IP来识别客户端。
    另外ACL中主要由下面五种权限组合。

    1)CREATE:允许创建子节点;

    2)READ:允许从节点获取数据并列出其子节点;

    3)WRITE:允许为节点设置数据;

    4)DELETE:允许删除子节点;

    5)ADMIN:允许为节点设置权限。


总结

    这一节,我们主要学习了ZooKeeper的基本概念,以及其顺序一致性、原子性、高性能、高可用四种特性;同时,还讲述了ZooKeeper的数据模型,znode节点存储的内容,以及集群的Leader、Follower、Observer三种角色,ACL的digest、sasl、ip三种认证方式,及ZooKeeper的Create、Read、Write、Delete、Admin五种权限。


思考和讨论

    1、我们都知道分布式场景中有一个CAP理论,ZooKeeper在CAP理论中符合了哪些呢?


欢迎留言与我分享和指正!也欢迎你把这篇文章分享给你的朋友或同事,一起交流。

感谢您的阅读,我们下节再见!





以上是关于分布式带你走进ZooKeeper的主要内容,如果未能解决你的问题,请参考以下文章

瞄一眼,带你走进SparkSQL的世界

瞄一眼,带你走进SparkSQL的世界

万字带你入门 ZooKeeper

从入门到实战,TensorFlow 带你走进深度学习的世界

万字长文带你走进MySql优化(系统层面优化软件层面优化SQL层面优化)

带你走进WebGL的随机美学