ZK是什么？为啥分布式系统都爱用它？

摘要

听说很多大型分布式系统都在用ZK，它到底是个啥？🤔 我自己刚开始接触ZK的时候也是一头雾水，这不就是个动物园管理员嘛（ZooKeeper直译）？后来用多了才发现，这玩意确实是分布式系统的“管理员”...

听说很多大型分布式系统都在用ZK，它到底是个啥？🤔 我自己刚开始接触ZK的时候也是一头雾水，这不就是个动物园管理员嘛（ZooKeeper直译）？后来用多了才发现，这玩意确实是分布式系统的“管理员”，不过管的是机器和服务之间的协调工作。

ZK本质上是一个分布式应用程序协调服务，简单来说，就是帮分布式系统中的各个节点“传话”、“同步”和“协调”。它来自Apache，用Java写的，在分布式环境下能提供高可靠的数据管理。

🍁 ZK的数据模型：像文件系统一样的树

ZK的数据模型，咱们可以把它想象成一个类似文件系统的树形结构🌲。树上的每个节点，ZK里叫znode。每个znode都有一个唯一的路径标识，比如 /services/serviceA。znode不仅可以存储数据（不过一般不建议存太大，最多1M吧），还可以有子节点，这就让它能很好地组织各种数据。

🍁 ZK的节点类型：持久和临时，有序和无序

ZK的节点有几种类型，理解这个很重要：

持久节点（PERSISTENT）：创建了就不会轻易消失，除非你主动删掉它。
临时节点（EPHEMERAL）：这个就比较有意思了，它的生命周期和客户端的会话绑定。如果创建它的客户端会话失效（比如断连了），这个节点就会被ZK自动清理掉。这个特性经常用来做服务注册和故障发现。
有序节点（SEQUENTIAL）：创建这种节点时，ZK会自动在节点名后面加上一个单调递增的数字后缀。这在实现分布式锁或者公平队列的时候非常有用。

平常我是这样理解和使用这些节点的：持久化节点放那些需要长期存在的配置信息，临时节点拿来登记服务实例地址，服务挂了连接断了节点自动清理，这样就能实时知道哪些服务是可用的。

🍁 ZK的特点：靠谱的分布式协调员

ZK能这么受欢迎，主要是因为它提供了几个非常重要的特性：

顺序一致性：客户端的更新请求都会按照发出的顺序被执行。
原子性：更新操作要么成功，要么失败，没有中间状态。
单一系统映像：客户端不管连接到ZK集群中的哪个服务器，看到的数据视图都是一致的。
可靠性：一旦一个更新操作被应用，结果就会一直保持，直到下次更新。
实时性：在一定的时间范围内，客户端能保证读到最新的数据。

这些特性加起来，就让ZK成了一个非常可靠的分布式协调工具。

🍁 ZK能干啥？应用场景还挺多

ZK的应用场景其实挺丰富的，我这里列举几个常见的：

配置管理：可以把系统的配置信息存在ZK的某个znode里，然后让所有应用实例都监听这个节点。一旦配置有变，ZK会通知所有实例，它们就能动态获取新配置了。这样就实现了集中式的配置管理和动态更新。
命名服务：通过znode的路径，可以提供一个全局唯一的名称，类似于域名解析。
分布式锁：利用临时顺序节点的特性，可以实现分布式锁。多个客户端在竞争锁时，都在指定的锁目录下创建临时顺序节点，序号最小的那个获得锁。没获取锁的就监听自己前一个序号节点的变化，当前一个节点被删除（锁释放）时，就轮到它了。这样就形成了一个公平的锁获取队列。
集群管理和Master选举：利用临时节点（尤其是临时顺序节点）可以很方便地实现集群机器的监控和Master选举。比如，机器启动时在特定目录下创建一个临时节点注册自己，机器下线节点自动消失，其他机器就能感知到变化。Master选举也是类似，所有候选者创建临时顺序节点，序号最小的成为Master。