redis之Zookeeper vs 内存数据网格 vs Redis
我在多个资源中发现了不同的 zookeeper 定义。也许其中一些是断章取义的，但请看一下:
我使用过 Redis 和 Hazelcast，通过与它们进行比较，我会更容易理解 Zookeeper。
您能否将 Zookeeper 与内存数据网格和 Redis 进行比较？
- 如果是分布式内存计算，zookeeper 与内存数据网格有何不同？
- 如果跨集群同步，那么它与所有其他内存存储有何不同？同样的内存数据网格也提供集群范围的锁。 Redis 也有某种事务。
- 如果它只是关于内存中一致的数据，那么还有其他选择。 Imdg 允许您实现相同的目标，不是吗？
请您参考如下方法:
https://zookeeper.apache.org/doc/current/zookeeperOver.html
默认情况下，Zookeeper 将您的所有数据复制到每个节点，并让客户端观察数据的变化。更改会非常快速地(在有限的时间内)发送给客户。您还可以创建“临时节点”，如果客户端断开连接，这些节点将在指定时间内删除。 ZooKeeper 针对读取 进行了高度优化，而写入速度非常慢(因为它们通常在写入发生后立即发送到每个客户端)。最后，Zookeeper 中"file"(znode) 的最大大小为 1MB，但通常它们是单个字符串。
总而言之，这意味着 zookeeper 不打算存储大量数据，而且绝对不是缓存。相反，它用于管理心跳/了解哪些服务器在线、存储/更新配置，以及可能的消息传递(尽管如果您有大量消息或高吞吐量需求，RabbitMQ 之类的工具将更适合此任务)。
基本上，ZooKeeper(和建立在其上的 Curator)有助于处理集群机制——心跳、分发更新/配置、分布式锁等。
其实和Redis并没有什么可比性，但是对于具体的问题...
它不支持任何计算，对于大多数数据集，将无法存储具有任何性能的数据。
它被复制到集群中的所有节点(没有像 Redis 集群那样可以分发数据的地方)。所有消息都以原子方式完整处理并排序，因此没有真正的事务。它可用于为您的服务实现集群范围的锁(事实上它非常擅长)，并且 znode 本身有很多锁定原语来控制哪些节点访问它们。
当然可以，但是 ZooKeeper 填补了一个空缺。它是一种使分布式应用程序能够很好地处理多个实例的工具，而不是用于存储/共享大量数据的工具。与为此目的使用 IMDG 相比，Zookeeper 会更快，以可预测的方式管理心跳和同步(有很多 API 使这部分变得容易)，并且有一个“推”范式而不是“拉”，所以节点是很快收到更改通知。
链接问题的引文...
A canonical example of Zookeeper usage is distributed-memory computation
... 是，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。
1.本站遵循行业规范，任何转载的稿件都会明确标注作者和来源；2.本站的原创文章，请转载时务必注明文章作者和来源，不尊重原创的行为我们将追究责任；3.作者投稿可能会经我们编辑修改或补充。
