我在多个资源中发现了不同的 zookeeper 定义。也许其中一些是断章取义的，但是请看一下：
我曾使用过 Redis 和 Hazelcast，通过与它们进行比较，我会更容易理解 Zookeeper。
您能否将 Zookeeper 与内存数据网格和 Redis 进行比较？
【问题讨论】：
标签： redis apache-zookeeper distributed-computing hazelcast
https://zookeeper.apache.org/doc/current/zookeeperOver.html
默认情况下，Zookeeper 将您的所有数据复制到每个节点，并让客户端观察数据的变化。更改会很快（在有限的时间内）发送给客户。您还可以创建“临时节点”，如果客户端断开连接，这些节点会在指定时间内被删除。 ZooKeeper 针对读取进行了高度优化，而写入非常慢（因为它们通常在写入发生后立即发送到每个客户端）。最后，Zookeeper 中“文件”（znode）的最大大小为 1MB，但通常它们是单个字符串。
综合起来，这意味着 zookeeper 不打算存储大量数据，也绝对不是缓存。相反，它用于管理心跳/了解哪些服务器在线、存储/更新配置以及可能的消息传递（尽管如果您有大量消息或高吞吐量需求，那么 RabbitMQ 之类的东西对于这项任务会更好）。
基本上，ZooKeeper（以及基于它构建的 Curator）有助于处理集群机制——心跳、分发更新/配置、分布式锁等。
其实和Redis没有可比性，但是对于具体的问题...
它不支持任何计算，并且对于大多数数据集，将无法以任何性能存储数据。
它被复制到集群中的所有节点（没有什么像 Redis 集群那样可以分布数据）。所有消息都以原子方式完整处理并按顺序排列，因此没有真正的事务。它可以用于为您的服务实现集群范围的锁（实际上它非常擅长），并且 znode 本身上有很多锁定原语来控制哪些节点访问它们。
当然，但是 ZooKeeper 填补了一个小众市场。它是一种使分布式应用程序与多个实例一起运行的工具，而不是用于存储/共享大量数据的工具。与为此目的使用 IMDG 相比，Zookeeper 会更快，以可预测的方式管理心跳和同步（使用许多 API 使这部分变得容易），并且具有“推送”范例而不是“拉取”，因此节点是非常迅速地通知更改。
链接问题的引文...
Zookeeper 使用的典型示例是分布式内存计算
... 是，IMO，有点误导。您将使用它来编排计算，而不是提供数据。例如，假设您必须处理表的第 1-100 行。您可能会放置 10 个 ZK 节点，名称如“1-10”、“11-20”、“21-30”等。客户端应用程序将由 ZK 自动通知此更改，第一个将获取“ 1-10" 并设置一个临时节点clients/192.168.77.66/processing/rows_1_10
下一个应用程序会看到这一点，然后去下一组处理。要计算的实际数据将存储在其他地方（即 Redis、SQL 数据库等）。如果节点在计算过程中失败，另一个节点可以看到这一点（30-60 秒后）并重新开始工作。
不过，我想说 ZooKeeper 的典型例子是领导选举。假设您有 3 个节点——一个是主节点，另外两个是从节点。如果主节点宕机，从节点必须成为新的领导者。这种类型的东西非常适合 ZK。
【讨论】：
一致性保证 ZooKeeper 是一种高性能、可扩展的服务。读取和写入操作都被设计为快速，尽管读取比写入快。这样做的原因是在读取的情况下，ZooKeeper 可以服务较旧的数据，这又是由于 ZooKeeper 的一致性保证：
顺序一致性 来自客户端的更新将按照发送的顺序应用。
原子性 更新要么成功，要么失败——没有部分结果。
单一系统映像 无论客户端连接到哪个服务器，客户端都会看到相同的服务视图。
可靠性 一旦应用了更新，它将从那时起持续存在，直到客户端覆盖更新。这种保证有两个推论：
如果客户端获得成功的返回代码，则更新将被应用。在某些故障（通信错误、超时等）上，客户端将不知道更新是否已应用。我们采取措施尽量减少失败，但唯一的保证是只有成功的返回代码。 （这在 Paxos 中称为单调性条件。）
客户端通过读取请求或成功更新看到的任何更新，在从服务器故障中恢复时将永远不会回滚。
及时性 保证系统的客户视图在一定的时间范围内是最新的。 （大约几十秒。）客户端将在此范围内看到系统更改，或者客户端将检测到服务中断。
【讨论】：