Zookeeper、内存数据网格和Redis的区别

Question

我在多个资源中找到了不同的Zookeeper定义。也许其中一些被脱离了上下文，但请看一下：

1. Zookeeper使用的一个典型例子是分布式内存计算...

2. ZooKeeper是一个开源Apache™项目，提供集中式基础设施和服务，实现集群间的同步。

3. Apache ZooKeeper是一个开源的文件应用程序接口(API)，允许大型系统中的分布式进程相互同步，以便所有请求数据的客户端接收一致的数据。

我曾经使用过Redis和Hazelcast，通过与它们进行比较，我更容易理解Zookeeper。

你能否将Zookeeper与内存数据网格和Redis进行比较？

1. 如果是分布式内存计算，那么Zookeeper与内存数据网格有什么区别？
2. 如果是集群同步，那么它与所有其他内存存储区别在哪里？相同的内存数据网格还提供集群范围的锁定。Redis也有某种类型的事务。
3. 如果只是关于内存一致性数据，那么还有其他替代方案。IMDG允许您实现相同的功能，不是吗？

- VB_

Answer 1

https://zookeeper.apache.org/doc/current/zookeeperOver.html

Zookeeper默认将所有数据复制到每个节点，并允许客户端监视数据更改。更改会非常快地发送给客户端（在有限的时间内）。您还可以创建“临时节点”，如果客户端断开连接，则这些节点将在指定时间内被删除。ZooKeeper高度优化了 读取 ，而写入非常慢（因为它们通常会立即发送给每个客户端，只要写入发生）。最后，Zookeeper中“文件”的最大大小（znode）为1MB，但通常它们是单个字符串。

综合起来，这意味着zookeeper不适合存储大量数据，也绝对不是缓存。相反，它用于管理心跳/知道哪些服务器在线，存储/更新配置以及可能的消息传递（尽管如果您有大量的消息或高吞吐量需求，则类似RabbitMQ的东西将更适合此任务）。

基本上，ZooKeeper（以及建立在其上的Curator）有助于处理群集的机械部分--心跳，分发更新/配置，分布式锁等。

它与Redis没有太多可比性，但针对具体的问题...

1. 它不支持任何计算，并且对于大多数数据集，无法以任何性能存储数据。

2. 它被复制到群集中的所有节点（没有类似Redis分片的东西可以分配数据）。所有消息都会被完整地原子性处理并排序，因此没有真正的事务。它可以用来为您的服务实现全局集群锁定（实际上非常擅长这个），并且znode本身有很多锁定原语来控制哪些节点访问它们。

当然，但ZooKeeper填补了一个空缺。它是一个工具，用于使分布式应用程序与多个实例协调，而不是用于存储/共享大量数据。与使用IMDG来实现此目的相比，Zookeeper将更快，以可预测的方式管理心跳和同步（具有许多API可使此部分易于操作），并且具有“推”范例而非“拉”范例，因此节点会迅速通知更改。引自链接问题的引语... ...

Zookeeper使用的典型示例是分布式内存计算

我认为这有点误导。您将使用它来编排计算，而不是提供数据。例如，假设您必须处理表的第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个节点 - 一个是主节点，另外2个是从节点。如果主节点停止工作，则必须成为新领袖的从节点。这种情况非常适合使用ZK。

- Robert Fraser

---

这是网络上最优秀的Zookeeper定义之一。 - Nether

Answer 2

一致性保证 ZooKeeper是一个高性能、可扩展的服务。读写操作都被设计为快速，尽管读取比写入更快。这是因为在读取的情况下，ZooKeeper可以提供旧数据，这反过来又是由于ZooKeeper的一致性保证：

顺序一致性 客户端的更新将按照发送的顺序应用。

原子性 更新要么成功，要么失败——没有部分结果。

单一系统映像 无论连接到哪个服务器，客户端都将看到相同的服务视图。

可靠性 一旦更新被应用，它将从那时起持久存在，直到客户端覆盖该更新。这个保证有两个推论：

如果客户端得到了成功的返回代码，更新将已经应用。在某些故障（通信错误、超时等）的情况下，客户端将不知道更新是否已经应用。我们采取措施最小化故障，但唯一的保证只存在于成功的返回代码中。（这被称为Paxos中的单调条件。）

通过读取请求或成功更新看到的任何更新，在从服务器故障中恢复时都不会回滚。

时效性 客户对系统的视图在一定的时间范围内保证是最新的。（大约几十秒钟的量级。）要么客户端在此期限内看到系统更改，要么客户端将检测到服务中断。

- Prateek Bansal