在群集中的同一Couchbase节点上存储某些密钥

是否可以确保某些密钥存储在集群中的同一Couchbase节点上？假设有用户及其偏好（不是一个真实的例子，只是为了简单起见…），大多数时候我会把它们放在一起显示在页面上。我认为将它们放在同一个节点上是很自然的，这样客户端就不会从不同的节点检索它们

---

我应该如何命名键以确保它们位于同一节点上？有可能吗？这是我应该关心的事情吗？

虽然在技术上是可行的，而且在某些情况下，如您的示例中，这样做似乎是合乎逻辑的，但没有什么好处，特别是与确保密钥确实到达预定节点的潜在缺点相比

为了证明“小利益”评论的正确性，对于健康状况良好的典型系统，节点之间在访问任何特定文档所需的时间（无论是节点检索文档所需的时间还是通过网络发送该文档所需的时间）方面的差异应该最小，因此，由于在节点上对密钥进行分组而产生的任何性能增益都是微乎其微的

另一个令人感兴趣的主要领域是可用性。这里的好处可能更大，因为如果一个节点因任何原因而宕机，则该节点可能不是包含所有链接键的节点，因此剩余节点中的一个将足以维持（系统的特定部分）。但是，也存在这样的风险，即包含所有优先级密钥的一个节点将出现故障，系统没有活动密钥，并且需要（自动）故障切换或恢复。但是，即使这些密钥分布在一个节点上，相同的（自动）故障切换和副本读取机制也将提供相同的可用性，只留下最小的（如果有的话）好处

---

然而，缺点要大得多，因为确保密钥被发送到特定节点的方法需要修改用于分割密钥的哈希算法，这需要在可靠地部署到开发集群之前进行彻底的测试和设计。

这个问题很老了，但我对Counchbase也有同样的问题，所以我添加了一些评论

Redis cluster具有您所问的确切功能，即使用{}包装的部分密钥将用于计算哈希，而不是整个密钥

下面是一个可能有用的案例

---

假设Couchbase或Redis节点集群用于为20多个web服务器保存会话数据。如果一个web服务器的数据总是发送到同一个节点，那么即使集群的一部分出现故障也无法恢复，只有该节点服务的web服务器会受到影响。否则，所有web服务器都将关闭。

为什么您要从CB中删除分片和可用性管理，并将其放在应用程序端—自己管理HA？这是使用Couchbase的一个好处——开箱即用。您是否有一些特定的性能问题？我认为Couchbase的vBucket概念是一个强大的生产解决方案。你可以在vBucket上读到：这篇文章实际上提出了我的问题。我认为这两个条目可能位于不同的vBucket中，因此客户端需要从vBucket-A获取第一个条目，从vBucketB获取另一个条目。。。我想我会以某种方式命名这两把钥匙，以确保它们生活在同一个vBucket中。。。假设它们都以“user:”前缀或其他什么开头。不过，我并没有特别的性能问题，只是环顾四周并掌握CB概念。但即使您以某种方式使用“完整”密钥切分算法将逻辑组中的所有密钥放在一个vBucket中……我发现出现了几个问题：1。vBucket大小对于您计划保留在一个vBucket中的键/值组来说可能太小。2.无论如何都必须启用CB复制，因为您希望在服务器实例发生故障时进行故障转移…然后影子实例应该接管。。第2点实际上意味着您必须使用CB的HA机制。另一种选择是，您可以只有一个“主”密钥，并将所有其他子密钥及其值存储为主密钥下的值文档……您将不再存在此问题