浅谈Zookeeper

基本概念

ZooKeeper是一个开源的分布式协调服务，提供了高可用性、高性能、有序一致性的数据管理功能。它主要用于解决分布式系统中的一致性问题，如配置管理、命名服务、分布式锁等。

Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。

特点

设计目标

①高性能
将数据存储在内存中，直接服务于客户端的所有非事务请求，尤其适合读为主的应用场景
②高可用
一般以集群方式对外提供服务，每台机器都会在内存中维护当前的服务状态，每台机器之间都保持通信。只要集群中超过一般机器都能正常工作，那么整个集群就能够正常对外服务。
③严格顺序访问
对于客户端的每个更新请求，zookeeper都会生成全局唯一的递增编号，这个编号反应了所有事务操作的先后顺序。
 

使用场景

①维护配置信息
Java编程经常会遇到配置项，例如数据库的user、password等，通常配置信息会放在配置文件中，再把配置文件放在服务器上。当需要修改配置信息时，要去服务器上修改对应的配置文件，但在分布式系统中很多服务器都需要使用该配置文件，因此必须保证该配置服务的高可用性和各台服务器上配置的一致性。通常会将配置文件部署在一个集群上，但一个集群涉及的服务器数量是很庞大的，如果一台台服务器逐个修改配置文件是效率很低且危险的，因此需要一种服务可以高效快速且可靠地完成配置项的更改工作。
zookeeper就可以提供这种服务，使用Zab一致性协议保证一致性。hbase中客户端就是连接zookeeper获得必要的hbase集群的配置信息才可以进一步操作。在开源消息队列Kafka中，也使用zookeeper来维护broker的信息。在dubbo中也广泛使用zookeeper管理一些配置来实现服务治理。

②分布式锁服务
一个集群是一个分布式系统，由多台服务器组成。为了提高并发度和可靠性，在多台服务器运行着同一种服务。当多个服务在运行时就需要协调各服务的进度，有时候需要保证当某个服务在进行某个操作时，其他的服务都不能进行该操作，即对该操作进行加锁，如果当前机器故障，释放锁并fall over到其他机器继续执行。

③集群管理
zookeeper会将服务器加入/移除的情况通知给集群中其他正常工作的服务器，以及即使调整存储和计算等任务的分配和执行等，此外zookeeper还会对故障的服务器做出诊断并尝试修复。

④服务动态上下线

⑤生成分布式唯一ID
在过去的单库单表系统中，通常使用数据库字段自带的auto_increment熟悉自动为每条记录生成一个唯一的id。但分库分表后就无法依靠该属性来标识一个唯一的记录。此时可以使用zookeeper在分布式环境下生成全局唯一性id。每次要生成一个新id时，创建一个持久顺序结点，这个节点带有顺序编号，创建操作返回的结点序号，即为新id。

数据结构

zookeeper的数据结点可以视为树状结构（或者目录），树中各节点成为znode，一个znode可以有多个子结点。zookeeper结点在结构上表现为树状，使用路径来定位某个znode。
znode兼具文件和目录两种特点，既像文件一样维护着数据、元信息、ACL、时间戳等数据结构，又像目录一样可以作为路径标识的一部分。ZooKeeper 的设计目标是实现协调服务，而不是真的作为一个文件存储，因此 znode 存储数据的大小被限制在 1MB 以内。

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

数据节点类型：

znode 有两种类型：

• 临时的（ EPHEMERAL ）：客户端会话结束时，ZooKeeper 就会删除临时的 znode。

• 持久的（PERSISTENT ）：除非客户端主动执行删除操作，否则 ZooKeeper 不会删除持久的 znode。

znode的四种形式：

• 持久化目录节点（PERSISTENT）：客户端与Zookeeper断开连接后，该节点依旧存在持久化顺序编号目录节点（PERSISTENT_SEQUENTIAL）

• 客户端与Zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号：临时目录节点（EPHEMERAL）

• 客户端与Zookeeper断开连接后，该节点被删除：临时顺序编号目录节点（EPHEMERAL_SEQUENTIAL）

• 客户端与Zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

「注意」：创建ZNode时设置顺序标识，ZNode名称后会附加一个值，顺序号是一个单调递增的计数。

每个 znode 节点在存储数据的同时，都会维护一个叫做 Stat 的数据结构，里面存储了关于该节点的全部状态信息。如下：

集群角色

Zookeeper 集群的每个服务器承担如下三种角色中的一种。

• Leader(领导者)：它负责 发起并维护与各 Follwer 及 Observer 间的心跳。所有的写操作必须要通过 Leader 完成再由 Leader 将写操作广播给其它服务器。一个 Zookeeper 集群同一时间只会有一个实际工作的 Leader。

• Follower(跟随者)：它会响应 Leader 的心跳。Follower 可直接处理并返回客户端的读请求，同时会将写请求转发给 Leader 处理，并且负责在 Leader 处理写请求时对请求进行投票。一个 Zookeeper 集群可能同时存在多个 Follower。

• Observer(观察者)：角色与 Follower 类似，但是无投票权。

zookeeper的工作原理

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。

Zab协议 的全称是 Zookeeper原子广播。Zookeeper 是通过 Zab 协议来保证分布式事务的最终一致性。Zab协议要求每个 Leader 都要经历三个阶段：发现，同步，广播。

Zab协议有两种模式，它们 分别是恢复模式（选主）和广播模式（同步）。

当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加 上了zxid。

ZAB 协议定义了两个可以无限循环的流程：

• 选举 Leader：用于故障恢复，从而保证高可用。

• 原子广播：用于主从同步，从而保证数据一致性。

选举Leader

ZooKeeper 的故障恢复

ZooKeeper 集群采用一主（称为 Leader）多从（称为 Follower）模式，主从节点通过副本机制保证数据一致。

• 如果 Follower 节点挂了 - ZooKeeper 集群中的每个节点都会单独在内存中维护自身的状态，并且各节点之间都保持着通讯，只要集群中有半数机器能够正常工作，那么整个集群就可以正常提供服务。

• 如果 Leader 节点挂了 - 如果 Leader 节点挂了，系统就不能正常工作了。此时，需要通过 ZAB 协议的选举 Leader 机制来进行故障恢复。

ZAB 协议的选举 Leader 机制简单来说，就是：基于过半选举机制产生新的 Leader，之后其他机器将从新的 Leader 上同步状态，当有过半机器完成状态同步后，就退出选举 Leader 模式，进入原子广播模式。

当zk集群中的一台服务器出现以下两种情况之一时，就会开始leader选举。

（1）服务器初始化启动。

（2）服务器运行期间leader不可用。

投票信息中包含两个最基本的信息。

sid：即server id，用来标识该机器在集群中的机器序号，在zk的配置文件上配置。

zxid：即zookeeper事务id号。

ZooKeeper状态的每一次改变, 都对应着一个递增的Transaction id,，该id称为zxid.，由于zxid的递增性质, 如果zxid1小于zxid2,，那么zxid1肯定先于zxid2发生。创建任意节点，或者更新任意节点的数据， 或者删除任意节点，都会导致Zookeeper状态发生改变，从而导致zxid的值增加。

以（sid，zxid）的形式来标识一次投票信息。

例如：如果当前服务器要推举sid为1，zxid为8的服务器成为leader，那么投票信息可以表示为（1，8）

集群中的每台机器发出自己的投票后，也会接受来自集群中其他机器的投票。每台机器都会根据一定的规则，来处理收到的其他机器的投票，以此来决定是否需要变更自己的投票。

选举规则如下：

（1）初始阶段，都会给自己投票。

（2）当接收到来自其他服务器的投票时，都需要将别人的投票和自己的投票进行pk，规则如下：

优先检查zxid。zxid比较大的服务器优先作为leader。如果zxid相同的话，就比较sid，sid比较大的服务器作为leader。

注意：zxid比较大的服务器优先作为leader的原因是，zxid比较大，意味着这个写操作晚发生，这个节点有集群全部的写信息，选举完成和follower同步的时候，不会遗漏数据。

原子广播

①读操作

Leader/Follower/Observer 都可直接处理读请求，从本地内存中读取数据并返回给客户端即可。

由于处理读请求不需要服务器之间的交互，Follower/Observer 越多，整体系统的读请求吞吐量越大，也即读性能越好。

②写 Leader

由上图可见，通过 Leader 进行写操作，主要分为五步：

1. 客户端向 Leader 发起写请求。

2. Leader 将写请求以事务 Proposal 的形式发给所有 Follower 并等待 ACK。

3. Follower 收到 Leader 的事务 Proposal 后返回 ACK。

4. Leader 得到过半数的 ACK（Leader 对自己默认有一个 ACK）后向所有的 Follower 和 Observer 发送 Commmit。

5. Leader 将处理结果返回给客户端。

过程类似数据库中的两阶段提交协议。



注意

• Leader 不需要得到 Observer 的 ACK，即 Observer 无投票权。

• Leader 不需要得到所有 Follower 的 ACK，只要收到过半的 ACK 即可，同时 Leader 本身对自己有一个 ACK。上图中有 4 个 Follower，只需其中两个返回 ACK 即可，因为 $$(2+1) / (4+1) > 1/2$$ 。

• Observer 虽然无投票权，但仍须同步 Leader 的数据从而在处理读请求时可以返回尽可能新的数据。

③写 Follower/Observer



Follower/Observer 均可接受写请求，但不能直接处理，而需要将写请求转发给 Leader 处理。

除了多了一步请求转发，其它流程与直接写 Leader 无任何区别。

watch机制

简单地说：client端会对某个znode 注册一个watcher事件，当该znode发生变化时，这些client会收到ZooKeeper的通知，然后client可以根据znode变化来做出业务上的改变等。

经典使用场景：zookeeper为dubbo提供服务的注册与发现，作为注册中心，但是大家有没有想过zookeeper为啥能够实现服务的注册与发现吗？

这就不得不说一下zookeeper的灵魂 Watcher（监听者）。



什么是watcher？

watcher 是zooKeeper中一个非常核心功能 ，客户端watcher 可以监控节点的数据变化以及它子节点的变化，一旦这些状态发生变化，zooKeeper服务端就会通知所有在这个节点上设置过watcher的客户端 ，从而每个客户端都很快感知，它所监听的节点状态发生变化，而做出对应的逻辑处理。



简单的介绍了一下watcher ，那么我们来分析一下，zookeeper是如何实现服务的注册与发现。zookeeper的服务注册与发现，主要应用的是zookeeper的znode节点数据模型和watcher机制，大致的流程如下：

• 服务注册：服务提供者（Provider）启动时，会向zookeeper服务端注册服务信息，也就是创建一个节点，例如：用户注册服务com.xxx.user.register，并在节点上存储服务的相关数据（如服务提供者的ip地址、端口等）。

• 服务发现：服务消费者（Consumer）启动时，根据自身配置的依赖服务信息，向zookeeper服务端获取注册的服务信息并设置watch监听，获取到注册的服务信息之后，将服务提供者的信息缓存在本地，并进行服务的调用。

• 服务通知：一旦服务提供者因某种原因宕机不再提供服务之后，客户端与zookeeper服务端断开连接，zookeeper服务端上服务提供者对应服务节点会被删除（例如：用户注册服务com.xxx.user.register），随后zookeeper服务端会异步向所有消费用户注册服务com.xxx.user.register，且设置了watch监听的服务消费者发出节点被删除的通知，消费者根据收到的通知拉取最新服务列表，更新本地缓存的服务列表。



上边的过程就是zookeeper可以实现服务注册与发现的大致原理。

Zookeeper面试常见11个连环炮_面试_田维常_InfoQ写作社区

深入浅出 ZooKeeper_zookeeper_vivo互联网技术_InfoQ写作社区

【菜鸟教程】Zookeeper基础入门【上】_win10 zookeeper 菜鸟教程-CSDN博客

ZooKeeper学习笔记-CSDN博客