动物园管理员与内存中的数据网格对Redis

Question

我在多个资源中找到了不同的动物园管理员定义。也许有些是断章取义的，但请看一看：

1. 一个典型的使用动物园管理员的例子是分布式内存计算.
2. ZooKeeper是一个开放源码的Apache™项目，它提供了一个集中式的基础设施和服务，支持跨集群的同步。
3. Apache ZooKeeper是一个开放源代码文件应用程序接口(API)，它允许大型系统中的分布式进程相互同步，以便所有提出请求的客户端都接收一致的数据。

我曾与Redis和Hazelcast合作过，通过与他们的比较，我可以更容易地理解动物园管理员。

你能把动物园管理员和内存中的数据网格和Redis比较一下吗？

1. 如果是分布式内存计算，动物园管理员与内存中的数据网格有什么不同？
2. 如果跨集群同步，那么它与所有其他内存存储有何不同？相同的内存中数据网格还提供集群范围的锁。Redis也有一些交易。
3. 如果这仅仅是关于内存中一致的数据，那么还有其他的选择。Imdg允许你实现同样的目标，不是吗？

Answer 1

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

默认情况下，会将所有数据复制到每个节点，并让客户端查看数据是否发生更改。更改非常快地(在有限的时间内)发送到客户端。您还可以创建“临时节点”，如果客户端断开连接，则在指定的时间内删除这些节点。ZooKeeper对读进行了高度优化，而写入非常慢(因为它们通常在写入完成后立即发送到每个客户端)。最后，中的“文件”(znode)的最大大小是1MB，但通常是单个字符串。

综合起来，这意味着动物园管理员不打算存储大量数据，当然也不是缓存。相反，它用于管理心跳/知道哪些服务器处于联机状态，存储/更新配置，以及可能的消息传递(尽管如果您有大量的消息或高吞吐量的需求，类似于RabbitMQ这样的任务将更适合这项任务)。

基本上，ZooKeeper (以及建立在它之上的管理员)帮助处理集群的机制--心跳、分发更新/配置、分布式锁等等。

这和Redis不太一样，但是对于具体的问题.

1. 它不支持任何计算，而且对于大多数数据集，将无法存储具有任何性能的数据。
2. 它被复制到集群中的所有节点(没有任何东西像Redis集群那样可以分发数据)。所有消息都以原子方式完整地处理，并被排序，因此没有真正的事务。它可以用于为您的服务实现集群范围的锁(实际上它非常好)，而tehre是znode本身上的许多锁定原语，用于控制哪些节点访问它们。
3. 当然，但ZooKeeper填补了一个利基。它是一种使分布式应用程序能够很好地处理多个实例的工具，而不是存储/共享大量数据的工具。与使用IMDG实现这一目的相比，Zookeeper将更快，以一种可预测的方式管理心跳和同步(使用大量的API来简化此部分)，并且具有“推送”模式，而不是“拉”，因此节点很快就会收到更改通知。

引用相关问题的话..。

一个典型的使用动物园管理员的例子是分布式内存计算。

..。海事组织有点误导。您将使用它来编排计算，而不是提供数据。例如，假设您必须处理表的第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。

Answer 2

一致性保证了ZooKeeper是一种高性能、可伸缩的服务。虽然读操作比写操作快，但读和写操作都设计得很快。这样做的原因是，在读取的情况下，ZooKeeper可以提供较旧的数据，这又是由于动物园管理员的一致性保证：

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

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

一个客户端将看到服务的相同视图，而不管它连接到哪个服务器。

一旦应用了更新，可靠性将从那时起一直保持到客户端覆盖更新为止。这项保证有两个推论：

如果客户端获得成功的返回代码，则将应用更新。在某些故障(通信错误、超时等)时，客户端将不知道是否应用了更新。我们采取措施尽量减少失败，但唯一的保证是只有成功的返回码。(这称为Paxos中的单调性条件。)

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

及时，客户对系统的看法是保证在一定的时间范围内的最新的。(大约是几十秒。)在此范围内的客户端将看到系统更改，或者客户端将检测到服务中断。