Hash 一致性哈希作为一种扩展写入的方法

我正在努力弄清楚我是否走上了正确的道路。我正在构建一个（实时）统计/分析服务，我使用redis存储一些集合和散列

现在让我们假设我取得了一些成功，我需要扩大规模。哈希环技术看起来不错，但我觉得它只适合缓存场景

如果节点发生故障怎么办？理论上，它的密钥现在由其他节点拥有。实际上，他们没有这些数据。它丢了，对吗？与添加/删除节点相同

---

我错过了一些基本的东西吗？这是穷人的集群吗？

在集群中使用多个节点有两个原因：

• 分片以限制每个节点上存储的数据量
• 复制以减少读取负载，并允许在不丢失数据的情况下删除节点

这两者有着本质上的不同，但是您可以实现两者——使用一致的散列来指向具有标准主/从设置的一组节点，而不是单个节点

如果集群是您的主数据存储而不是缓存，那么您将需要一种不同的重新分发策略，包括复制数据

我的实现基于让客户机为散列选择64k个存储桶中的一个，并拥有一个将该存储桶映射到节点的表。最初，所有映射到节点#1

---

当节点#1变得太大时，其从节点变为主节点#2，并且更新表以将节点#1键的一半映射到节点#2。此时，所有读写操作都将与新映射一起工作，您只需清理现在位于错误节点上的密钥。根据性能要求，您可以一次检查所有钥匙，也可以像到期系统一样随机选择钥匙

这太聪明了！感谢您的洞察力：-）差不多10年后，这仍然是相关的。每当任何数据存储提到一致散列时，它们都应该简单地解释在节点下降/增加的情况下数据是如何移动的。