问题标签 [consistent-hashing]

在google/guava@GitHub中， Hashing类实现了一致的 hashing@wiki。该方法consistentHash需要一个HashCode对象：

我正在实现一个原型分布式键值存储，并希望通过自定义Row键和Column键对键空间进行分区。

这里 class Row（和 class Column）只是一个String字段的包装器，并且有自己的hashCode()方法。我的问题是如何HashCode根据@param r 和@param c生成alocateNodeIndexFor以便调用Hashing#consistentHash？

我有一个库，其中传递了一个字符串用户标识，因此基于该字符串用户标识，我只需要选择这三种颜色中的一种。

假设如果 String userid 是12345那么它可以选择RED，所以下次如果12345传递相同的 userid，那么它应该只选择相同的 RED 颜色。另一个例子，如果 String userid 是98765，那么在这种情况下，BLUE如果下次98765传递相同的用户 id，它可以选择，那么它应该BLUE只选择相同的颜色。

想法适用于相同的用户 ID，它应该始终选择相同的颜色。它不应该是相同的用户 ID，它第一次选择一种颜色，然后第二次选择其他颜色。

我可以在这里的用户 ID 上使用什么样的散列技术，以便我可以始终为相同的用户 ID 选择相同的颜色？

在我的网站中，会上传一些重要的文件，是否需要JavaScript在浏览器端计算文件的校验和，然后golang在服务器端再次计算和比较，以确保服务器获取的文件一致？

我想在上传之前在浏览器端对文件进行校验和，然后在服务器端进行校验和比较以确保一致。但是我怎样才能得到文件的纯二进制数据和校验和呢？我尝试了以下方法，但不起作用：

我希望这里的一些大师可以帮助我

我正在编写一个 C/C++ 代码来使用 SHA1 作为散列算法来实现一致性散列。

我需要实现模块操作如下：

0100 0011....0110 100 mod 0010 1001 = ?

如果除数 ( 0000 1111) 是 2 的幂pow(2,n)，那么很容易，因为最后 n 位被除数就是结果。

SHA1 长度为 160 位（或 40 hexa）。我的问题是如何实现一个长位串到另一个任意位串的模运算？

谢谢你。

当一个节点加入 DHT 网络时，新节点似乎最优的做法是平均划分一致哈希圆上的最大间隔，以最小化重新映射。然而，这仅对 2 ^{n 个}节点是最优的（假设从n =1 开始）；如果键被统一访问，所有其他数字都会创建热点：

• n =2, ¹ / ₂ ¹ / ₂ , 最优
• n =3, ¹ / ₄ ¹ / ₄ ¹ / ₂，¹ / ₃个节点服务¹ / ₂流量的热点
• n =4, ¹ / ₄ ¹ / ₄ ¹ / ₄ ¹ / ₄ , 最优
• n = 5, ¹ / ₈ ¹ / ₈ ¹ / ₄ ¹ / ₄ ¹ / ₄，热点有³ / ₅个节点服务³ / ₄的流量

一种在引起更多重新映射的同时最小化热点的方法是均匀地重新分配新节点：

• n =2, ¹ / ₂ ¹ / ₂
• n =3, ¹ / ₃ ¹ / ₃ ¹ / ₃

通过像下面这样的实现，一些相当少的元素被重新映射（不确定它是否真的被最小化了），热点被消除了，基本的一致哈希算法被保留了。

从那个（字母而不是数字）的转换是：
[abcdefghij]-> [abcde][fghij]-> [abc][defg][hij]->[ab][cde][fg][hij]

是否有其他/更好的解决方案（这是一个已解决的问题）？一般来说，我对 DHT 和分布式算法相对较新，但我没有发现在我读过的任何 DHT/p2p/分布式算法中都解决了这个问题。在我的特定场景中，最小化热点至关重要，而最小化重新映射成本更低。

我已经对 Akka .NET 一致的散列路由器进行了一些实验。在我看来，尽管您可以指定用于散列的密钥，但路由器决定如何在参与者之间分配密钥。

我本来想做一些事情，比如演员 A 接受 A 类型的消息，演员 B 接受 B 类型的消息，等等。这对于一致的散列路由器是否可能？

目前，我们有每个超过 100 GB 的表。有人告诉我，如果我们有很多小桌子，这将更容易处理。这个想法是 Cassandra 在执行压缩和压缩时需要大约等于表大小的可用空间量。如果使用较小的表，则运行这些任务时每个节点上所需的可用空间百分比会更小。

如果我所有的访问都只在大表中通过键进行，那么在我的数据库访问代码前面放置一些一致的哈希逻辑来确定哪个表包含什么键并不难。

Cassandra 在软件中使用许多小表有什么优势吗？是否可以通过更改集群的配置来获得相同的优势？

我正在寻找关于如何在预定义的工作进程之间平均分配工作的想法

我有一个存储在 Mongo 中的“n”个文档数组和“m”个工作进程

目前我已经编写了一个算法，由每个工人在启动时处理

算法：
1. Worker 从其预定义的 worker Number 开始
2. 从 Mongo 获取文档列表
3. ForEach Document in Document List
{
   Magic Number = Mod( Hash( Document Name ), m )
   If( Magic Number == My Worker Number )
   Add记录到我的遗愿清单以执行特定操作
}

这个算法做得相当不错，但它的效率不是很高

因此，我正在寻找一些关于如何使工作人员平均分配“n”个可用文档或在平均值的某个容差范围内（~5%）的想法

当前的基础设施不允许我拥有可以查询 Mongo 并将工作分配给工作人员的 Master

我做了一些关于一致性哈希的在线阅读（亚马逊 Dynamo 和 Memcached 使用），它看起来很有希望，但没有尝试实施和分析它，但想检查是否有任何其他解决方案或想法可以有希望或一致散列是要走的路吗？

我正在尝试使用 AkkaConsistentHashingRoutingLogic来保证具有相同密钥的消息被路由到同一个 Actor。重要的是，具有相同键的消息按 FIFO 顺序处理。不同key的消息可以路由到不同的Actor，自由并行处理。我没有在分布式模式下使用 Akka。

这些消息实际上是从 RabbitMQ 代理读取的 JSON 消息，因此我的 Master Actor 接收到 AMQP 消息并使用路由键作为消息键。相同的密钥也在消息本身中。Actor 是 Spring 应用程序的一部分。

我的主演员看起来像这样：

我最初通过以下方式获得主人一次：

然后只需通过以下方式将消息提交给它：

但是，当我从我的工作人员打印日志时，onReceive()我看到不同的调度程序线程有时被用于同一个键。

同样不清楚为什么有时相同的调度程序线程被用于 Master Actor 和 Worker Actor。这不应该是线程之间的异步消息传递吗？

正如您在此处看到的，带有键 10420186 的 Worker 处理消息的调度程序线程有时是 9，有时是 10。Master actor 有时也使用这两个线程。

我如何确定它ConsistentHashingRoutingLogic确实在工作并且同一个线程使用相同的密钥处理消息？我在路由器初始化中做错了什么吗？