zookeeper是什么

引用官网的描述，

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications. Each time they are implemented there is a lot of work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty of implementing these kinds of services, applications initially usually skimp on them, which make them brittle in the presence of change and difficult to manage. Even when done correctly, different implementations of these services lead to management complexity when the applications are deployed.

简单来说，zookeeper是一个分布式协调服务。个人理解其设计的背景是，在当前的微服务普遍是无状态的前提下，将涉及到多个服务之间的状态维护、传递、数据同步，比如分布式事务等这一类复杂的，难以维护，容易出错的过程，统一交给zookeeper这样一个中间件来处理。对调用方来说，所需要处理的仅仅是简单易用的接口和高性能的系统。

zookeeper常见的应用场景包括：

• 数据发布/订阅
• 负载均衡
• 命名服务
• 分布式协调/通知
• 集群管理
• Master 选举
• 分布式锁
• 分布式队列

zookeeper的三个核心内容

数据结构znode

zookeeper使用znode作为基本的数据结构，我们平时对于zookeeper的使用，大部分都是在操作znode。

znode是一种树状结构，每个节点都是一个znode，znode中保存着节点的一些metadata和用户自定义数据。

znode分为持久节点和临时节点，区别在于其存活时间。节点的类型在创建时指定，且不可更改。
持久节点的存活时间不依赖于客户端会话，只有客户端在显式执行删除节点操作时，节点才消失。
临时节点的存活时间依赖于客户端会话，当会话结束，临时节点将会被自动删除（当然也可以手动删除临时节点）。利用临时节点的这一特性，我们可以使用临时节点来进行集群管理，包括发现服务的上下线等。
zk规定，临时节点不能拥有子节点。

同时，节点可设置为顺序节点，对于持久节点和临时节点，均可设置为顺序节点。顺序节点可用来做id生成器等。

znode中的用户数据不建议存储过大，当数据量过大时会显著影响zookeeper的性能。

znode的metadata

版本号

每个znode都有三个版本号：

1. dataVersion

数据版本号，每次对节点进行set操作，dataVersion的值都会增加1（即使设置的是相同的数据）。

2. cversion

子节点的版本号。当znode的子节点有变化时，cversion 的值就会增加1。

3. aclVersion

ACL的版本号，关于znode的ACL（Access Control List，访问控制），可以参考下文

以数据版本号来说明zk中版本号的作用。每一个znode都有一个数据版本号，它随着每次数据变化而自增。ZooKeeper提供的一些API例如setData和delete根据版本号有条件地执行。多个客户端对同一个znode进行操作时，版本号的使用就会显得尤为重要。例如，假设客户端C1对znode /config写入一些配置信息，如果另一个客户端C2同时更新了这个znode，此时C1的版本号已经过期，C1调用setData一定不会成功。这正是版本机制有效避免了数据更新时出现的先后顺序问题。在这个例子中，C1在写入数据时使用的版本号无法匹配，使得操作失败。下图描述了这个情况。

事务ID

对于zk来说，每次的变化都会产生一个唯一的事务id，zxid（ZooKeeper Transaction Id）。通过zxid，可以确定更新操作的先后顺序。例如，如果zxid1小于zxid2，说明zxid1操作先于zxid2发生。
需要指出的是，zxid对于整个zk都是唯一的，即使操作的是不同的znode。

cZxid
Znode创建的事务id。

mZxid
Znode被修改的事务id，即每次对znode的修改都会更新mZxid。

在集群模式下，客户端有多个服务器可以连接，当尝试连接到一个不同的服务器时，这个服务器的状态要与最后连接的服务器的状态要保持一致。Zk正是使用zxid来标识这个状态，上图描述了客户端在重连情况下zxid的作用。当客户端因超时与S1断开连接后，客户端开始尝试连接S2，但S2延迟于客户端所识别的状态。然而，S3的状态与客户端所识别的状态一致，所以客户端可以安全连接上S3。

watcher机制

相比于大部分中间件的响应模式，zk的一大特点就是基于watcher机制，通过异步回调的方式实现了zk服务对客户端的主动调用。整个流程如下图所示，客户端在服务端注册watcher，当服务端某个znode发生了变化后，会判断当前节点是否注册了watcher，如果有的话，会主动推送相应的watchevent到客户端。客户端通过发送过来的path找到watcher，进行相应的操作。

watcher注册的整体过程如下。

watcher回调的整体过程如下。出于对资源节约的考虑，zk服务在每次回调通知客户端后，会删除相应的watcher，如有相应的需要，客户端需要再次主动注册watcher。

ACL权限控制

zookeeper 可以通过 ACL（Access Control List，访问控制表）进行权限控制，对数据进行保护。相比于redis每个连接都可以随意更改所有的数据，zk的数据安全性能得到进一步的保障。

zookeeper 的 acl 通过 [scheme,id,permissions] 来构成权限列表。对于每一个节点，都维护着这样的一个权限列表。

• 1、scheme：代表采用的某种权限机制，包括 world、auth、digest、ip、super 几种。
• 2、id：代表允许访问的用户。
• 3、permissions：权限组合字符串，由 cdrwa 组成，其中每个字母代表支持不同权限， 创建权限 create©、删除权限 delete(d)、读权限 read®、写权限 write(w)、管理权限admin(a)。

ZooKeeper 支持以下权限：

• CREATE: 能创建子节点
• READ：能获取节点数据和列出其子节点
• WRITE: 能设置节点数据
• DELETE: 能删除子节点
• ADMIN: 能设置权限

CREATE权限和DELETE权限从WRITE权限中分离出来，是为了获得更好的访问控制。使用CREATE和DELETE权限的场景如下：
你想让A用户能够设置节点数据，但不允许创建或删除子节点。
有CREATE但无DELETE权限：客户端发出一个在父目录下创建节点的请求。你想让所有客户端能够添加，但是只有创建者能够删除。（这类似于文件的APPEND权限）。

内置的 ACL schemes

ZooKeeper有如下内置的schemes

• world 有个唯一的id, anyone ，代表所有人。
• auth 不使用任何id，代表任何已认证的用户。
• digest 用 username:password 字符串来产生一个MD5串，然后该串被用来作为ACL ID。认证是通过明文发送username:password 来进行的，当用在ACL时，表达式为username:base64 ，base64是password的SHA1摘要的编码。
• ip 使用客户端的主机IP作为ACL ID 。这个ACL表达式的格式为addr/bits ，此时addr中的有效位与客户端addr中的有效位进行比对。

zookeeper的最佳实践

详见参考资料ZooKeeper 的应用场景 - 知乎 (zhihu.com)