Zookeeper

一、ZooKeeper1、Zookeeper 的数据模型 zk 提供的命名空间类似与文件系统，ke-value 形式存储，每个节点都是一个路径标识。每个节点都会保存自己的数据和节点信息。2、节点的分类 节点特性：同一级节点名称是唯一的

• 持久节点：客户端与服务端断开后节点不会被删除（默认）

• 持久顺序节点：客户端与 zk 断开后不会删除节点，并且在建立节点时按照创建顺序编号

• 临时节点：客户端与 ZK 断开后就会删除节点

• 临时顺序节点：客户端与 zk 断开后会删除节点，在建立的时候给节点顺序编号 3、zk 的应用场景

• 配置管理

• 分布式协调器

• 注册中心

• 分布式锁 4、zk 的工作原理 zk 的核心是原子广播，这个机制保证了各个 Server 之间的同步，实现这个机制的协议叫做 ZAB 协议（脱胎与 paxos 算法）Zab 协议有两种模式，他们分别是恢复模式（选主）和广播模式（同步）为了保证事务顺序的一致性，zk 采用了递增的事务 id 号（zxid）来标识事务，所有的选举在提出的时候都加上了 zxid，实现中 zxid 是一个 64 位的数字，高 32 位是 epoch 用来标识 leader 关系是否改变，每次 leader 被选出来，它都会有一个新的 epoch 标识当前属于那个 leader 的统治时期，低 32 位用于递增计数。Server 在工作时的三种状态： - looking：当前 Server 不知道 leader 是谁正在寻找 - leading：当前 Server 即为选出来的 leader - following：正在与选出的 Server 同步中 5、zk 的 watch 机制 整个 watcher 事件机制，分为客户端注册、服务端处理，服务端触发机制通知、客户端回调四个过程。![[Pasted image 20231201152535.png]]6、zk 的数据同步流程 zk 中，主要依赖 ZAB 协议来实现分布式数据一致性。ZAB 协议分为两部分：消息广播、崩溃恢复。 消息广播:(采用 2PC 的事务提交方案)zk 使用单一的主进程 Leader 来接收和处理客户端所有事务请求、并采用 ZAB 协议的原子广播协议，将事务请求以 Proposal(提案)提议广播到所有的 Follower 节点，当集群中过半的额 Follower 服务器进行正确的 ACK 反馈，那么 Leader 会进一步发送 commit 消息，将此次提案进行提交。 崩溃恢复： 由于 Leader 服务器出现崩溃或者是由于网络导致过半的 Follower 与之失去通信，那么就会进入到崩溃恢复模式，需要选举出一个新的 Leader 服务器。在这个过程中可能会出现两种数据不一致的隐患，需要 ZAB 协议的特性进行避免。

• 1、Leader 服务器发送完 commit 后，立即崩溃

• 2、Leader 刚提出 Proposal 后，立即崩溃 ZAB 协议的恢复模式采用了以下策略：

• 1、选举 zxid 最大的节点作为新的 Leader

• 2、新的 Leader 将九十五日志中尚未提交的消息进行处理 7、分布式锁实现原理 排它锁 排它锁就是只有一个线程能持有锁，实现方式,(如：创建锁 /exclusive_lock/lock)利用 zk 在同级节点的唯一性，在获取锁时调用 create()接口，在/exclusive_lock 的路径下建立一个相同的临时节点 lock，最终只有一个节点能创建成功，那么这个客户端就获得了分布式锁，同时没有获得锁的其他节点可以在/exclusive_lock 节点上注册一个子节点变更的 watcher 监听事件，以便重新争取获得锁。 共享锁 共享锁，如果事务 T1 对数据对象 O1 加上了共享锁，那么当前的事务只能对哦、O1 进行读取，其他的事务只能对他加共享锁，知道该对象的所有共享锁都释放。 定义锁: /shared_lock/[hostname]-请求类型 W/R-序号 可以使用 curator 工具包封装的 API 帮助我们实现分布式锁