我被问到consistent hash的一些缺点。但我认为它的成本比传统的哈希％N哈希要多一点。正如标题所提到的，如果一致哈希是非常好的，为什么不使用呢？
你知道更多吗？谁可以告诉我一些？
答案 0 :(得分：2)
实现consistent hashing并非易事，在许多情况下，您有一个很少或永远不需要重新映射的哈希表，或者可以快速重新映射的哈希表。
答案 1 :(得分：2)
我所知道的一致散列的唯一缺点是实现它比简单散列更复杂。更多代码意味着有更多地方可以引入错误，但现在有免费的选项。
从技术上讲，一致的散列会消耗更多的CPU;查询排序列表以确定将对象映射到哪个服务器是O（log n）操作，其中n是服务器数X每个服务器的插槽数，而简单散列是O（1）。
但实际上，O（log n）速度太快并不重要。 （例如，8台服务器每台服务器X 1024个槽= 8192项，log2（8192）=最差情况下最多13次比较。）原作者对其进行了测试，发现使用一致性散列计算缓存服务器的时间仅为20微秒建立。同样，一致的散列消耗空间来存储已排序的服务器插槽列表，而简单的散列不占用空间，但所需的数量是微不足道的，大约为Kb。
为什么不为人所知？如果我不得不猜测，我会说这只是因为学术思想传播到行业需要时间。 （原始论文写于1997年。）
答案 2 :(得分：0)
我假设你特意谈论哈希表，因为你提到mod N.如果我错误的话，请纠正我，因为哈希用于各种不同的事情。
原因是一致的散列并没有真正解决哈希表迫切需要解决的问题。在重新散列中，哈希表可能需要重新分配其大部分元素，无论是什么，可能是大多数元素。这是因为我们可能会重新增加我们的表的大小，这通常是二次方的;例如，一旦桌子开始变得太满，它就会非常典型。
因此，在一致的哈希术语中，我们不只是添加节点;我们将节点数量增加一倍。这意味着，无论如何，最好的情况是，我们移动了一半的元素。当然，一致的散列技术可以减少这些动作，并试图接近这个理想，但最好的情况改善只是2倍的恒定因子，这不会改变我们的整体复杂性。
从另一端接近，在大多数应用程序中，哈希表都是关于缓存性能的。让它们快速进入的所有兴趣都在于尽可能快地计算内容，尽可能少地触及内存。无论你如何看待它，添加一致的散列可能会超过2倍的减速;最终，一致的哈希会变得更糟。
最后，整个问题从另一个角度来看并不重要。我们希望重新加速，但重要的是我们根本不会重复。在任何正常的实际情况中，当程序员看到他因重新散列而出现问题时，正确的答案几乎总是找到一种方法来避免（或至少限制）重新散列，通过选择合适的大小来开始用。鉴于这是典型的情况，为一些不应该发生的事情保持相当实质性的副结构显然不是一场胜利，而且再次使我们整体变慢。
几乎所有关于散列表的优化工作都是如何更快地计算散列，或者如何更快地执行冲突解决。这些事情发生在比我们谈论的一致散列要小得多的时间尺度上，这通常用于我们谈论以微秒甚至毫秒测量的时间尺度，因为我们必须做/ O操作。
答案 3 :(得分：0)
原因是一致性哈希往往会导致读取端为范围扫描查询做更多的工作。
例如，如果您想搜索按特定列排序的条目，那么您需要将查询发送到每个节点，因为一致的散列会将甚至“相邻”的项目放在不同的节点中。
通常更喜欢使用与使用模式匹配的分区。最好在大量不同的分区/格式中复制相同的数据