任何人都可以让我知道简单散列相对于一致散列的任何优点。我正在查看互联网，找不到一些参数，例如在一致散列与简单散列中添加新节点的时间或从简单散列的一致散列中检索密钥的时间。任何帮助都会很好。

故事

我有 3 个 memcached 服务器正在运行，我关闭其中一个或另一个以调查 PHP-memcached 在服务器无法访问时的行为。

我在 PHP 中定义了 4 台服务器，其中 1 台用于模拟大部分离线的服务器（备用服务器）。当我关闭 1 台服务器（=> 2 台仍然在线）时，第三台服务器->get()给了我一个结果。

当我再关闭一台服务器时（=> 1 仍然在线），它不会找到推送到最后一台服务器的对象。

样本输出

首次运行，4 台服务器中的 3 台启动：

第二次运行，4 台服务器中的 3 台启动：

第三次运行，4 台服务器中的 2 台启动：

第四次运行，4 台服务器中的 1 台启动：

尽管只有一台服务器在线，并且每次在缓存中找不到任何对象时，我都会将对象推送到 memcached，但它不再能够找到密钥。

我认为它也应该只剩下一个服务器。

你能向我解释这种行为吗？

看起来即使我关闭了 20 台服务器中的 19 台，也无法实现安全的东西。

旁白：libketama 真的不再维护了，用它还好吗？lib 背后的逻辑相当不错，并且也用于 varnish 缓存服务器。

附录

我的脚本：

我正在使用 Infinispan 8.2 版。我已经知道节点何时将条目放入缓存。它使用其内部散列在密钥上并选择集群中的主节点。

我知道我们可以用我们的自定义散列函数覆盖这个散列。但我不知道从哪里开始以及如何开始。我搜索了很多文档和网站。但是，没有一个有正确的描述.

我希望有人在这方面帮助我。

提前致谢。

我对经典 Cassandra 中的协调感到好奇。我阅读了 Avinash Lakshman 和 Prashant Malik 撰写的 Facebook 论文，名为 Cassandra - A Decentralized Structured Storage System

论文摘录 每个由键标识的数据项通过散列数据项的键以产生其在环上的位置，然后顺时针遍历环以找到位置大于项位置的第一个节点，从而将其分配给一个节点. 该节点被视为该密钥的协调者。应用程序指定此密钥，Cassandra 使用它来路由请求。因此，每个节点都负责环中它与其在环上的前任节点之间的区域。

我很好奇的部分是环中的最后一个节点，指向环中第一个节点的节点，它协调的范围是多少？

因此，每个节点都对环中它和环上它的前任节点之间的区域负责

我正在尝试像这样可视化协调方案：

问题

不确定如何每个节点都可以成为协调器，但根据每个节点对自身及其前一个节点负责的描述，因为那样您将有协调器重叠。因此，在我的屏幕截图中，如果 180,302、502 和 771 也是协调器，它们会重叠。

我是 Swift 的新手，我正在尝试学习它的功能。关于环和一致的散列算法，我有两个问题要问你。

当我们要存储一个对象时，我们取它的路径（例如“.../v1/account_name/container_name/object_name.ext”），用这个路径输入MD5哈希函数，然后我们得到一个哈希值。从这个哈希值中，我们取前 n 位，其中 n 是部分幂，并使用这些位来获得分区号。现在，如果我们使用分区号访问环，我们可以发现该分区在哪个节点并以这种方式存储对象。

第一个问题：如果该分区已满怎么办？

假设现在 swift 将对象存储在正确的节点中，第二个问题是：swift 如何决定存储副本的位置？

谢谢你们！

我正在使用 redis 集群 3.0.1。

我认为redis集群使用一致的哈希。哈希槽类似于一致性哈希中的虚拟节点。Cassandra的数据分布和redis集群差不多，这篇文章说的是一致性哈希。

但是redis cluster turorial说redis cluster不使用consistent hash。

我想念什么？谢谢。

从我读过的所有内容来看，在一致的哈希中，如果一个节点崩溃，该节点处理的密钥将被重新映射到哈希环中的相邻节点。这在概念上对我来说很有意义。

我不明白这在分布式数据库的实践中是如何工作的。如果节点崩溃了，如何将数据移动到另一个节点？它是否假设有可用的备份/备用集群？还是可以从中复制的冗余节点？

我正在使用 ConsistentHashingGroup，我希望在集群中具有该组的路由的 Akka 节点出现故障时收到通知。

有没有办法在不订阅集群事件的情况下这样做？找到哪些路由放置在崩溃节点上的最佳方法是什么？我想从持久存储中恢复这些路由的数据。

我正在学习 Zookeeper，但我陷入了一些困惑。我浏览了各种论坛和问题，但没有一个能解决我的困惑，最终来到 SO 以澄清以下问题。

1. 据我了解，Zookeeper 在主从架构中工作。那么 Kafka 是如何适应这种架构的呢？Kafka 集群中的每个 Kafka 代理都充当 Zookeeper 服务器集成的客户端，还是生产和消费消息的用户应用程序充当 Zookeeper 集成的客户端？

2. 对于特定的主题/分区，一个 Kafka 代理会参与其中，如果它收到大量消息（它无法处理），是否可以使用一致的哈希分配工作负载以及 Zookeeper 架构如何支持这一点？

更新：Zookeeper 是否类似于 DynamoDB 中用于成员资格和故障检测的 Gossip 协议的变体

TL;DR：在重新散列/重新平衡期间如何处理故障节点中存在的 KEYS 的 READ/WRITE 请求？

假设在数据库的一致性哈希设置中，数据库中的一个节点发生了故障。现在，只有该特定节点上的密钥将在哈希环中的其余节点之间重新哈希/重新平衡。

我的问题是，在重新散列/重新平衡期间如何处理失败节点中存在的 KEYS 读/写请求？

一个简单的答案可能是 READ/WRITE 请求在重新平衡期间由故障节点的副本处理。但是考虑以下情况：

假设，我的复制因子（N）= 3，WRITE quorum（W）= 3 和 READ QUORUM（R）= 3

现在，如果一个节点发生故障，那么在重新平衡期间，我的复制因子将变为 2，即故障节点上只有两个数据副本。

现在，如果 READ 请求到来，由于我的 READ quorum 设置为 3，我的数据库将无法用于该请求，因为它无法找到 READ 请求对应的 3 个副本。

然而，据我所知，一致散列有助于设计 ALWAYS-ON 系统。

这是否意味着在重新平衡/重新散列期间，如果我想要高可用性，我的 R/W quorum 很可能无法满足？