ZooKeeper节点数据操作流程及zookeeper的应用场景

系统管理员 2022-09-08 04:59 289阅读 0赞

## zk节点数据操作流程： ##

首先回顾一下Zookeeper中Leader和Follower的作用：

>  Leader：负责进行投票的发起和决议，分布式读写，更新请求转发；
> 
>  Follower：负责接收客户端请求并向客户端返回结果，在选举Leader过程中参与投票（选举机制）；

### **一、写数据流程** ###

以3台服务器的Zookeeper集群为例，一个Leader，两个Follower即server1和server2

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d4MTUyODE1OTQwOQ_size_16_color_FFFFFF_t_70][]

（1）**Client向**Zookeeper的**server1发送**一个写请求，客户端写数据到服务器1上；

（2）如果**server1不是Leader**，那么server1会把接收到的**写请求转发给Leader**；然后Leader会将写请求**转发给每个server**；

server1和server2负责写数据，并且两个Follower的写入数据是一致的，保存相同的数据副本；

server1和server2写数据成功后，通知Leader；

（3）**当Leader收到集群半数以上的节点写成功的消息**后，说明该写操作执行成功；

eg：这里是3台服务器，只要2台Follower服务器写成功就ok

因为client访问的是server1，所以**Leader会告知server1集群中数据写成功**；

（4）被访问的server1进一步通知client数据写成功，这时，客户端就知道整个写操作成功了。

### **二、读数据流程** ###

相比写数据流程，读数据流程就简单得多；因为每台server中数据一致性都一样，所以随便访问哪台server读数据就行；

没有写数据流程中请求转发、数据同步、成功通知这些步骤。

## ZK应用场景： ##

### 1、数据发布与订阅 ###

发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。

发布/订阅一般有两种设计模式：**推模式**和**拉模式**

1.  推: 服务端会推给注册了监控节点的客户端 Wathcer 事件通知。
2.  拉: 客户端获得通知后，然后主动到服务端拉取最新的数据。

**配置信息一般有几个特点:**

1.  数据量小的KV
2.  数据内容在运行时会发生动态变化
3.  集群机器共享，配置一致

![e48a871c608e96a2ce1d1cea992d0e55.png][]

**基于 Zookeeper 的实现方式**

*  数据存储：将数据（配置信息）存储到 Zookeeper 上的一个数据节点
 *  数据获取：应用在启动初始化节点从 Zookeeper 数据节点读取数据，并在该节点上注册一个数据变更 Watcher
 *  数据变更：当变更数据时，更新 Zookeeper 对应节点数据，Zookeeper会将数据变更通知发到各客户端，客户端接到通知后重新读取变更后的数据即可。

### **2、负载均衡** ###

负载均衡是一种手段，用来把对某种资源的访问分摊给不同的设备，从而**减轻单点**的压力。

实现的思路:

1.  首先建立 Servers 节点，并建立监听器监视 Servers 子节点的状态（用于在服务器增添时及时同步当前集群中服务器列表）
2.  在每个服务器启动时，在 Servers 节点下建立**临时子节点** Worker Server，并在对应的字节点下存入服务器的相关信息，包括服务的地址，IP，端口等等
3.  可以**自定义一个负载均衡算法**，在每个请求过来时从 ZooKeeper 服务器中获取当前集群服务器列表，根据算法选出其中一个服务器来处理请求

![0c9441849f978591969867706d8bb4d7.png][]

Zookeeper实现负载均衡demo：[https://blog.csdn.net/qq\_35044419/article/details/119925004][https_blog.csdn.net_qq_35044419_article_details_119925004]

### **3、命名服务** ###

zookeeper的命名服务有两个应用方向，**一个是提供类似JNDI的功能**，利用zookeepeer的树型分层结构，可以把系统中各种服务的名称、地址以及目录信息存放在zookeeper，需要的时候去zookeeper中读取。

另一个，**是利用zookeeper顺序节点的特性，制作分布式的ID生成器**，写过数据库应用的朋友都知道，我们在往数据库表中插入记录时，通常需要为该记录创建唯一的ID，在单机环境中我们可以利用数据库的主键自增功能。但在分布式环境则无法使用，有一种方式可以使用UUID，但是它的缺陷是没有规律，很难理解。利用zookeeper顺序节点的特性，我们可以生成有顺序的，容易理解的，同时支持分布式环境的序列号。

### 4、**分布式通知/协调** ###

ZooKeeper中特有watcher注册与异步通知机制，能够很好的实现分布式环境下不同系统之间的通知与协调，实现对数据变更的实时处理。使用方法通常是不同系统都对ZK上同一个znode进行注册，监听znode的变化（包括znode本身内容及子节点的），其中一个系统update了znode，那么另一个系统能够收到通知，并作出相应处理

*  另一种心跳检测机制：检测系统和被检测系统之间并不直接关联起来，而是通过zk上某个节点关联，大大减少系统耦合。
 *  另一种系统调度模式：某系统有控制台和推送系统两部分组成，控制台的职责是控制推送系统进行相应的推送工作。管理人员在控制台作的一些操作，实际上是修改了ZK上某些节点的状态，而ZK就把这些变化通知给他们注册Watcher的客户端，即推送系统，于是，作出相应的推送任务。
 *  另一种工作汇报模式：一些类似于任务分发系统，子任务启动后，到zk来注册一个临时节点，并且定时将自己的进度进行汇报（将进度写回这个临时节点），这样任务管理者就能够实时知道任务进度。

总之，使用zookeeper来进行分布式通知和协调能够大大降低系统之间的耦合

### **5、集群管理与Master选举** ###

1、集群机器监控：这通常用于那种对集群中机器状态，机器在线率有较高要求的场景，能够快速对集群中机器变化作出响应。这样的场景中，往往有一个监控系统，实时检测集群机器是否存活。过去的做法通常是：监控系统通过某种手段（比如ping）定时检测每个机器，或者每个机器自己定时向监控系统汇报“我还活着”。 这种做法可行，但是存在两个比较明显的问题：

*  集群中机器有变动的时候，牵连修改的东西比较多。
 *  有一定的延时。

利用ZooKeeper有两个特性，就可以实时另一种集群机器存活性监控系统：

*  客户端在节点 x 上注册一个Watcher，那么如果 x?的子节点变化了，会通知该客户端。
 *  创建EPHEMERAL类型的节点，一旦客户端和服务器的会话结束或过期，那么该节点就会消失。

例如，监控系统在 /clusterServers 节点上注册一个Watcher，以后每动态加机器，那么就往 /clusterServers 下创建一个 EPHEMERAL类型的节点：/clusterServers/\{hostname\}. 这样，监控系统就能够实时知道机器的增减情况，至于后续处理就是监控系统的业务了。

**2、**Master选举则是zookeeper中最为经典的应用场景了。

在分布式环境中，相同的业务应用分布在不同的机器上，有些业务逻辑（例如一些耗时的计算，网络I/O处理），往往只需要让整个集群中的某一台机器进行执行，其余机器可以共享这个结果，这样可以大大减少重复劳动，提高性能，于是这个master选举便是这种场景下的碰到的主要问题。

利用ZooKeeper的强一致性，能够保证在分布式高并发情况下节点创建的全局唯一性，即：同时有多个客户端请求创建 /currentMaster 节点，最终一定只有一个客户端请求能够创建成功。利用这个特性，就能很轻易的在分布式环境中进行集群选取了。

另外，这种场景演化一下，就是动态Master选举。这就要用到?EPHEMERAL\_SEQUENTIAL类型节点的特性了。

上文中提到，所有客户端创建请求，最终只有一个能够创建成功。在这里稍微变化下，就是允许所有请求都能够创建成功，但是得有个创建顺序，于是所有的请求最终在ZK上创建结果的一种可能情况是这样： /currentMaster/\{sessionId\}-1 ,?/currentMaster/\{sessionId\}-2 ,?/currentMaster/\{sessionId\}-3 ….. 每次选取序列号最小的那个机器作为Master，如果这个机器挂了，由于他创建的节点会马上小时，那么之后最小的那个机器就是Master了。

*  在搜索系统中，如果集群中每个机器都生成一份全量索引，不仅耗时，而且不能保证彼此之间索引数据一致。因此让集群中的Master来进行全量索引的生成，然后同步到集群中其它机器。另外，Master选举的容灾措施是，可以随时进行手动指定master，就是说应用在zk在无法获取master信息时，可以通过比如http方式，向一个地方获取master。
 *  在Hbase中，也是使用ZooKeeper来实现动态HMaster的选举。在Hbase实现中，会在ZK上存储一些ROOT表的地址和HMaster的地址，HRegionServer也会把自己以临时节点（Ephemeral）的方式注册到Zookeeper中，使得HMaster可以随时感知到各个HRegionServer的存活状态，同时，一旦HMaster出现问题，会重新选举出一个HMaster来运行，从而避免了HMaster的单点问题

### 6、分布式锁 ###

分布式锁，这个主要得益于ZooKeeper为我们保证了数据的强一致性。锁服务可以分为两类，一个是**保持独占**，另一个是**控制时序**。

*  所谓保持独占，就是所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。通常的做法是把zk上的一个znode看作是一把锁，通过create znode的方式来实现。所有客户端都去创建 /distribute\_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。
 *  控制时序，就是所有视图来获取这个锁的客户端，最终都是会被安排执行，只是有个全局时序了。做法和上面基本类似，只是这里 /distribute\_lock 已经预先存在，客户端在它下面创建临时有序节点（这个可以通过节点的属性控制：CreateMode.EPHEMERAL\_SEQUENTIAL来指定）。Zk的父节点（/distribute\_lock）维持一份sequence,保证子节点创建的时序性，从而也形成了每个客户端的全局时序。

### **7、分布式队列** ###

队列方面，简单地讲有两种，一种是常规的先进先出队列，另一种是要等到队列成员聚齐之后的才统一按序执行。对于第一种先进先出队列，和分布式锁服务中的控制时序场景基本原理一致，这里不再赘述。

第二种队列其实是在FIFO队列的基础上作了一个增强。通常可以在 /queue 这个znode下预先建立一个/queue/num 节点，并且赋值为n（或者直接给/queue赋值n），表示队列大小，之后每次有队列成员加入后，就判断下是否已经到达队列大小，决定是否可以开始执行了。这种用法的典型场景是，分布式环境中，一个大任务Task A，需要在很多子任务完成（或条件就绪）情况下才能进行。这个时候，凡是其中一个子任务完成（就绪），那么就去 /taskList 下建立自己的临时时序节点（CreateMode.EPHEMERAL\_SEQUENTIAL），当 /taskList 发现自己下面的子节点满足指定个数，就可以进行下一步按序进行处理了。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d4MTUyODE1OTQwOQ_size_16_color_FFFFFF_t_70]: /images/20220829/9c0cf39333664b5fad692561547f52ed.png
[e48a871c608e96a2ce1d1cea992d0e55.png]: /images/20220829/f4bd23265c1a4973bf4ed1a662788c43.png
[0c9441849f978591969867706d8bb4d7.png]: /images/20220829/f9b2e7514fcc439f996a688fa6111565.png
[https_blog.csdn.net_qq_35044419_article_details_119925004]: https://blog.csdn.net/qq_35044419/article/details/119925004