问题标签 [consistent-hashing]

假设我们有一个用户表，用户 id 将其分区为整数 1,2,3...n 。我可以使用用于分区表的一致性哈希的方式吗？

好处是，如果分区数量增加或减少，旧索引可以相同。

问题A。

使用一致性哈希算法做分区表是个好主意吗？

问题B。

任何关系数据库都支持这个吗？

我猜一些 nosql 数据库已经在使用它。

但是这里的数据库是指关系数据库。

我刚刚在一次采访中遇到了这个问题。在第一反应中，我只是按长度回答了 mod，但是如果将表划分为更多部分，则会受到挑战，那么它会导致问题。

在项目 voldemort 设计页面上：

http://project-voldemort.com/design.php

据说哈希环覆盖区间[0, 2^31-1]。

现在，区间 [0, 2^31-1] 代表 2^31 个总数，而最大的数 2^31-1 只是 31 位全部设置为 1。（为了说服自己，请考虑 2^3- 1. 2^3=8 是 0x1000。2^3-1=7 是 0x111)。

因此，如果使用普通的 32 位地址字来存储该值，则您有 1 位空闲。

因此，为什么 2^31-1 是上限？额外的位是否用于某种系统簿记？

（例如，1 个额外的位将为安全地添加两个有效的散列地址提供空间而不会溢出）。

最后，这个选择是voldemort特有的，还是在其他一致的哈希方案中看到的？

基本上，我想实现以下算法并分析使用这些算法构建的系统在不同条件下的行为。

• 八卦协议
• 多个 paxos
• 一致的哈希

我的兴趣在于这些算法。我基本上是在寻找一种可以让我快速编写这些算法并深入理解这些算法的编程语言。

我应该选择哪种语言？Java、Scala、Erlang 或其他任何东西。

目前，我知道 Java 和 C++。

我正在使用hash_ring包在服务器之间分发对象。我假设分布是统一的，因为它基于 MD5 散列。不幸的是，事实并非如此。

我正在使用使用生成的随机密钥uuid.uuid4()。我已经证实，MD5 本身实际上确实提供了均匀分布。但是，当我使用分配时hash_ring.HashRing，大多数和最少填充的存储桶之间存在 20-30% 的差异。

• hash_ring可以通过调整一些设置来改善分布的均匀性吗？
• 在 Python 中进行一致性哈希还有其他好的选择吗？

我用来测试分布均匀性的代码：

打印出来的是：

为了比较，我直接使用 MD5 进行了不一致的散列：

结果更好：

在工作负载分布到多个节点的分布式系统中，处理多个请求同时操作相同数据的竞争条件的两种方法是使用一致散列和分布式锁。一致的散列将确保对一组数据进行操作的所有请求都发送到同一个工作人员，而分布式锁将确保一次只有一个工作人员可以对任何一组数据进行操作。

我的问题是这两种方法的优缺点是什么，哪些可能是有利的？

诚然，一致性哈希是分布式缓存应用程序中广泛使用的技术。当节点数量动态变化时，它提供了一个很好的解决方案。并且当虚拟节点合并时，负载均衡问题也将得到解决。

我只是想知道这种技术有什么缺点或限制吗？

谢谢！

我正在寻找类似Consistent Hashing之类的东西，但要保证分配最终尽可能公平（不仅仅是随机密钥的平均） - 有没有这样的事情，如果有，我在哪里可以找到它？

编辑：在我的具体情况下，这组键是预先知道的（和“小”）。确切地说，这些密钥将始终存在，并且必须在任何给定时间点分别分配给每个节点。

可能重复：
python-memcache 是否使用一致的散列？

python-memcached 是否支持一致性哈希？我发现了一些关于这个的线程，但大多数都超过 2 年了。

干杯

MongoDB 具有详细记录的分片功能。

我所需要的只是更简单（部署和配置）和更快的一致散列类型的数据分布（如 Dynamo、Cassandra 或 Voldemort）。有没有办法用 MongoDB 实现这一点？

我正在研究在我正在编写的一些 java 代码中使用一致的哈希算法。guava Hashing 库有一个consistentHash(HashCode, int)方法，但文档相当缺乏。我最初的希望是，我可以只使用consistentHash()简单的会话亲和性来在一组后端服务器之间有效地分配负载。

有没有人有一个如何使用这种方法的真实例子？特别是我关心管理从目标范围中移除存储桶。

例如：

导致输出：

我想要的是在删除列表中较早的服务器后将该标识符（“someId”）映射到同一台服务器。所以在上面的示例中，删除后我想我希望存储桶 0 映射到“server1”，存储桶 1 映射到“server3”，存储桶 2 映射到“server4”，存储桶 3 映射到“server5”。

我是否应该维护一个单独的（比列表更复杂的）数据结构来管理存储桶的删除和添加？我想我可能已经设想了一个更复杂的哈希 API，它可以在为我添加和删除特定存储桶之后管理重新映射。

注意：我知道示例代码使用了一个小的输入和存储桶集。我在 100 个存储桶中尝试了 1000 次输入，结果是一样的。当我将 更改为 99 时，映射到存储桶 0-98 的输入保持不变，buckets并且存储桶 99 分布在剩余的 99 个存储桶中。