了解Zookeeper总结知识点

小小的人儿居然已存在

已于 2023-09-12 11:04:31 修改

阅读量292

点赞数

分类专栏：分布式大数据文章标签： zookeeper 分布式云原生

于 2023-09-12 10:59:56 首次发布

本文链接：https://blog.csdn.net/qq1049545450/article/details/132809545

版权

大数据同时被 2 个专栏收录

8 篇文章 0 订阅

订阅专栏

分布式

3 篇文章 0 订阅

订阅专栏

ZooKeeper 是什么？

Zookeeper是Apache下的一个开源的分布式协调中间件。是一个CP系统，为分布式系统提供强一致性的数据管理。
底层基于类似文件系统的目录节点树方式进行数据存储。每个节点默认最大大小为1M，用于存储数据或节点信息。Zookeeper通过监控这些数据的状态变化，从而达到基于数据的集群管理。
Zookeeper的一致性通过Zab协议实现，Zab协议有两种模式，分别是恢复模式和广播模式，对应着选主和同步两个阶段。当Leader节点崩掉或无法与大多数Follwer节点通信时，集群进行恢复模式选举出新的Leader节点，然后进入广播模式。

paxos的简化版算法 – Raft

Zookeeper集群中的角色和状态

在ZooKeeper中，节点角色通常可以分为以下几种：

领导者（Leader）：在ZooKeeper集群中，只有一个Leader节点，由集群中的所有节点进行投票选出。Leader节点负责处理所有的写请求，并将写操作广播给所有的Follower节点。
跟随者（Follower）：Follower节点是除了Leader之外的节点，它们负责处理客户端的读请求，并向Leader节点发送写请求。如果Leader节点出现故障，Follower节点会参与投票，从自己和其他节点中选择一个新的Leader。
观察者（Observer）：Observer节点在大多数情况下与Follower节点行为一致，但是它们不参与选举和投票，只同步Leader的广播数据和状态，以及处理客户端的读请求。由于不参与投票，Observer节点不会降低集群的写数据能力。

每个Server在工作过程中有4种状态：

LOOKING：当前Server不知道leader是谁，正在搜寻。
LEADING：当前Server即为选举出来的leader。
FOLLOWING：leader已经选举出来，当前Server与之同步。
OBSERVING：observer的行为在大多数情况下与follower完全一致，但是他们不参加选举和投票，而仅仅接受(observing)选举和投票的结果。

ZooKeeper一致性的保证

顺序一致性：按照客户端发送请求的顺序更新数据。
原子性：更新要么成功，要么失败，不会出现部分更新。
单一性：无论客户端连接哪个server，都会看到同一个视图。
可靠性：一旦数据更新成功，将一直保持，直到新的更新。
实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息或者服务器失效的信息。

如何保障顺序一致性

为了保障顺序一致性，zookeeper采用了递增的事务ID（zxid）来标识事务。所有的提议（proposal）都在被提出是加上zxid，实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

脑裂问题是什么？Zookeeper如何解决脑裂问题

集群节点间若出现网络隔离，网络隔离则可能会将集群划分成新的两个或多个集群，然后这些集群重新进行Leader选举，从而产生多个Leader节点，这将导致数据的不一致。
Zookeeper通过以下机制来解决脑裂问题：

过半机制：只有节点收到超过集群一半的投票才会成为Leader。
冗余通信：冗余更多的通信方式，避免单一通信造成网络隔离。
共享资源：能够访问到共享资源的节点标识在集群中，不能访问到的则不在集群中。

zookeeper有四种类型的节点：

PERSISTENT-持久化目录节点
客户端与 zookeeper 断开连接后，该节点依旧存在
PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
客户端与 zookeeper 断开连接后，该节点依旧存在，只是 Zookeeper 给该节点名称进行顺序编号
EPHEMERAL-临时目录节点
客户端与 zookeeper 断开连接后，该节点被删除
EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
客户端与 zookeeper 断开连接后，该节点被删除，只是 Zookeeper 给该节点名称进行顺序编号

Watcher机制

ZooKeeper的Watcher机制是指客户端对ZooKeeper中的节点进行监听，当节点发生改变（如数据内容改变、被删除或子节点状态改变）时，ZooKeeper会通知已注册了Watcher的客户端。

Watcher机制的实现原理是：当客户端注册Watcher时，ZooKeeper会为该客户端创建一个监视点，并缓存该监视点对应的事件类型和节点。当节点发生改变时，ZooKeeper会检查该改变是否与已注册的监视点匹配，如果匹配，就会触发监视点的通知，并将该通知发送给注册了该监视点的客户端。
Watcher机制的特点是：

异步通知：ZooKeeper采用异步通知的方式向客户端发送事件通知，因此客户端不必在注册监听后轮询阻塞。
一次性触发：每个监视点只会在第一次事件发生时触发一次通知，如果想要继续触发，需要在回调的方法中重新注册监听。
自定义监听器：客户端可以实现Watcher接口，自定义监听器的注册和回调方法，以处理不同的事件类型和节点状态。

总之，Watcher机制是ZooKeeper中实现分布式观察者模式的核心机制之一，可以用于实现发布/订阅、监听节点变化等功能。

Zookeeper的应用场景有哪些

分布式协调：ZooKeeper可以简单的理解为分布式系统中的协调者，可以管理和协调系统中各个组件的行为和状态，以确保系统整体的协调一致性。
分布式锁：通过创建和、监听、删除临时节点来实现分布式锁。
元数据/配置信息管理：ZooKeeper可以作为分布式系统中的元数据和配置信息的管理中心，可以集中管理系统的配置信息和元数据，方便系统的配置和管理。
HA高可用性：通过ZooKeeper可以实现高可用性（HA）的系统架构，当部分节点出现故障时，ZooKeeper可以协调其他节点进行接管，保证系统的正常运行。

Zookeeper在HBASE中的角色担当

协调者：ZooKeeper是HBase集群的"协调器"。HBase依赖ZooKeeper来协调不同组件之间的通信，例如HRegionServer和HMaster。当HRegionServer启动时，它会向ZooKeeper注册并提供状态信息（如是否在线），这些信息可供集群中的其他组件查询和使用。
状态存储：ZooKeeper可以存储和管理HBase集群的状态信息。例如，当HMaster启动时，它会将HBase的系统表-ROOT-加载到ZooKeeper集群，其他组件可以通过ZooKeeper集群获取这些系统表的信息。此外，ZooKeeper还存储了当前系统表.META.的存储所对应的RegionServer信息。
监控与处理：ZooKeeper还负责监控HBase集群中RegionServer的状态变化信息。当RegionServer的状态发生改变时，ZooKeeper会通知集群中的其他组件，例如HMaster，以便它们可以采取相应的行动。因此，ZooKeeper在HBase集群中扮演着重要的角色，确保集群的协调一致性。