Zookeeper

Zookeeper 是一个分布式应用程序的分布式协调服务。

提供了：配置、分组、

分层命名空间。类似于文件系统。

zookeeper 的数据存在内存中。

可以作为集群使用。主从。 Leader-Follower 架构。

客户端想连谁连谁，zookeeper 自己会将增删改数据转移到 leader 身上。zookeeper 的 leader 挂了后，可以快速恢复一个 leader（极其高可用）。官方压测 200ms 恢复。

不要把 zookeeper 当数据库用。

zookeeper 是一个目录树结构，它的 node 可以存数据，但少，仅1M。

类型上有持久化节点和临时节点（两个互斥），另外还有一个序列结点（不与其他互斥）。

client 与 node 连接后有 session 的概念，来代表与 client 的连接。依托于这个 session 有了 临时结点 的概念。这样对 client 创建锁有很好的使用。当 session 丢失时 锁 自动消亡。

保证：

• 顺序性。写一定经过 Leader
• 原子性。更新要么成功要么失败，没有部分成功等中间状态。（但不是强一致性，而是最终一致性）
• 单系统映像。看起来是单系统的，在哪里都看到一样。
• 可靠性。有持久化。

Redis 是通过发布订阅来作哨兵单通信的。但 Zookeeper 需要人为得写下 node。

配置文件中 3888 位置表明在没有 leader 时，zookeeper 通过 3888 这个端口进行通信选 leader；选出 leader 后通过 2888 建立连接进行通信；前方 server.1 中的 1 表示自己的一个 ID，zk 是在谦让中选出 leader 的，ID 大者为 leader（但下面四个顺序启动时，第三个启动时已经是 leader，所以 4 会成为 follower）。
将 id 写在 zk 的配置文件 myid 中。

server.1=node01:2888:3888
server.2=node02:2888:3888
server.3=node03:2888:3888
server.4=node04:2888:3888

新起的 node 会 Getting snapshot from leader

以创建目录的形式创建数据，就好像是 目录做为 key，上面存有值 ，目录下面还有子目录。

zookeeper 的数据上是有 *Zxid （事务 ID）的，这个 id 是 leader 维护的，系统中的每个操作都会递交给 leader，所以所有结点的操作都在同一顺序上递增。cZxid 有 64 位，前 32 位表示纪元（首位的 0 省略），即第几个 leader（可以想象为换一个 leader 就是换一个皇帝，就换了一个年号），后 32 位表示修改操作的次数。

cZxid = 0x200000002 // 开头的 c 表示创建，即创建的 id
ctime = Mon Sep 16 21:22:33 CST 2020
mZxid = 0x200000004 // 开头的 m 表示更新操作
ctime = Mon Sep 16 21:22:33 CST 2020
pZxid = 0x200000003 // 这个表示此节点（目录节点）下创建最后一个节点的 id 号
ephemeralOwner = 0x0 // 临时所有者，没有临时所有者表明是持久节点（目录）

（这里的节点，都表示 zookeeper 创建的目录，即 key）
一个客户端连接进来后会自动创建一个 sessionId，在客户端中创建 create -e xxx 时，-e 表示 ephemeral 临时节点，此时 ephemeralOwner 就会显示为 sessionId，表示属于此 sessionId 的临时节点。当客户端退出后，sessionId 自动回收，此临时节点也自动回收。

每个 client 是统一视图，即所有 client 连到 zookeeper 中都看到统一的数据，当 client_1 创建任何节点，client_2 都能看到。

-s 可以 规避并发

create -s /abc/xxx ""// 防并发得创建，会创建出 `/abc/xxx0000000000`，s 表示序列

另一个客户端也创建 -s /abc/xxx 会创建 /abc/xxx0000000001，这是因为 leader 中会维护这个 ID 序列。

---

Zookeeper.jpg