我理解经典的一致缓存算法，在添加/删除节点时，一些键必须重新映射到不同的节点。如果我放松一些要求，是否有一种算法完全不支持重新映射？
在我的应用程序中，我想递增地将密钥分配给节点：
-
一旦一个关键点被指定给一个节点，它就会永远留在那里。
-
已添加但未删除节点。节点在添加后永远不会停机——假设有一个复制/备份机制在工作。
-
密钥不需要在节点之间均匀分布。尽最大努力是可以的：当添加新节点时，会为其分配比旧节点更多的新密钥。
这种情况有算法吗？
我可以想象两种类似的解决方案，它们可以满足您的要求，但都有可能不可接受的条件：
- 如果缓存客户端知道第一次请求的序列密钥是什么，即如果缓存密钥包括某种单调增加的id或版本号，那么您可以跟踪集群大小增加的序列号，并根据当时存在的节点数量计算哈希
- 如果你不介意两阶段查找，你可以保留一个密钥→numnodes查找表，记录在缓存密钥时有多少节点，然后使用它来计算哈希代码。或者只保留一把钥匙→cachenode查找表
（如果两阶段查找是可以的，但查找表的大小是一个问题，则是#2的变体：保留散列（键）→cachenode查找表，并使该散列尽可能小以保持查找表的小。如果两个键碰巧有相同的散列，它们最终会在同一个节点上——但如果平衡不严格，那就不必担心了。）
这两种技术都不依赖于一致性哈希——只是简单的哈希代码——但两者都有很大的局限性。
在一般情况下，如果没有将密钥与该密钥首次缓存时的缓存状态信息联系起来的东西，那么不，我认为您所要求的是不可能的。