zookeeper简单介绍

最新推荐文章于 2024-04-14 21:45:16 发布

讲不出再见

最新推荐文章于 2024-04-14 21:45:16 发布

阅读量60

点赞数

分类专栏： zookeeper 文章标签： leader节点 Follower节点 Observer节点 watcher监控 ACL

本文链接：https://blog.csdn.net/dgh112233/article/details/117484304

版权

zookeeper 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

1. 数据节点

2. watcher 监控机制和 ACL 访问控制

2.1 watcher 监控机制

2.2 ACL 访问控制

3. Leader节点、Follower节点和Observer节点

真心推荐一本书：从Paxos到Zookeeper分布式一致性原理与实践

1. 数据节点

数据节点其实就可以直接理解为目录，跟windows里面的文件夹很像，文件夹下面可以创建子文件夹，文件夹本身可以包含很多数据与内容。

数据节点分为4种类型：持久节点（PERSISTENT）、持久顺序节点（PERSISTENT_SEQUENTIAL）、临时节点（EPHEMERAL）、临时顺序节点（EPHEMERAL_SEQUENTIAL）。

1. 持久节点（PERSISTENT）：节点创建好之后，会一直存在，除非主动删除它。

2. 持久顺序节点（PERSISTENT_SEQUENTIAL）：也是持久的、如果为此节点创建子节点时，子节点的名字会自动跟一个自增的数字后缀，表明子节点创建的先后顺序。

3. 临时节点（EPHEMERAL）：临时的，客户端会话什么时候失效，这个临时节点就什么时候被删除，另外，临时节点不能有子节点。

4. 临时顺序节点（EPHEMERAL_SEQUENTIAL）：临时的，节点名后面会自动跟一个自增的数字后缀，表示临时节点的创建先后顺序。

每个数据节点除了包含子数据节点和自身的内容数据外，还包含了属性、状态等等，会有一个对象专门存储着。状态属性包含如下：

其中，借助版本号是可以完成原子性操作的，只要操作前与操作后的版本号一致，就说明在此期间节点没有被修改过，可以放心完成操作，原理就是 Java 中的 cas 原理。

2. watcher 监控机制和 ACL 访问控制

2.1 watcher 监控机制

数据节点理解为目录之后，那每个节点都会有一个唯一的路径。

客户端向 zookeeper 服务端注册 watcher 事件，即告诉服务端：我想要监控哪个节点，这个节点一旦发生了什么类型的事件，你就赶紧通知我，我好做相应的处理。

zookeeper 服务端收到客户端的 watcher 注册后，用 hash 结构存储起来，key 就是监控节点的路径（唯一性），value 就是监控事件的具体内容。如果某个节点发生变动，服务端会查看一下是否该节点有 watcher 事件，如果有，再看一下事件类型是否符合，如果符合，则发送事件通知给客户端，告诉它。

客户端收到通知后，通过回调的方式执行相应的处理。

2.2 ACL 访问控制

这就是权限管理，可以设置：权限策略是什么，在此策略下，哪些用户能够访问哪些数据节点，能够对这些数据节点执行哪些操作。

权限策略：

1. IP 策略：用 IP 地址来做访问控制，设置可以访问某个节点的客户端IP有哪些，只有 IP 符合的客户端才能访问该节点。

2. Digest 策略：常用的策略，类似于账户密码，你只要给出正确的密码，就能够访问节点。

3. Word 策略：这个好像没什么用，类似一个 Digest 策略，只不过密码固定为 “world:anyone”。

4. Super 策略：允许有超级用户存在，超级用户可以对任意节点做任意操作。

权限：

1.CREATE：允许客户端在该节点下面创建子节点。

2. DELETE：允许删除该节点下的子节点。

3. READ：读取该节点自身，及其子节点。

4. WRITE：允许修改节点。

5. ADMIN：允许设置该节点的ACL权限。

可定义访问控制机制。

3. Leader节点、Follower节点和Observer节点

Follower 节点提供读功能，如果收到写请求，会转发给 Leader 节点。

Observer 节点提供读功能，如果收到写请求，会转发给 Leader 节点。

leader 节点是zookeeper集群的核心，符合管理和协调整个集群，能为客户端提供读写功能，当收到客户端的写请求时，自己完成写入，并将写请求转发给所有 Follower 节点，等超过半数的 Follower 节点都收到后，再给它们发一个“执行写入”的命令即可。当 leader 出问题时，如果被认为宕机了，那么所有 Follower 节点会进行一个投票，选出新的 leader 节点，重构集群，继续提供服务。

可以理解到，leader 节点就一个，如果想提升集群的读吞吐量，就需要更多的 Follower 节点，但是 Follower 节点一多，当写请求到来时，leader 节点需要协调更多的 Follower 节点去完成写操作，影响性能。于是就有了Observer 节点，只提供读服务，不参与投票，也不参与写请求的协同写入，只是老实地同步着 leader 节点的数据，提供读服务而已。因此，可以适当地考虑增加 Observer 节点来增加集群的读吞吐量，适当减少 Follower 节点，以减少性能开销。