我指的是this文档的应用程序堆栈部分中的Couchbase服务器，概述了Couchbase集群的所需体系结构 .
我注意到图中的5个Couchbase节点中的每个节点都有一个相应的Web服务器 . 我也知道Couchbase SDK旨在 Build 与单个节点的连接，并为所有请求保留该连接，但故障转移事件除外 .
首先，我想确认图中的5个Web服务器中的每个服务器都将 Build 与5个Couchbase节点之一的单个连接 . 我假设会产生1：1的关系;每个Web服务器将连接到相应的Couchbase节点，这样任何2个Web服务器都不会 Build 到同一Couchbase节点的连接 .
如果是这种情况，那么在Couchbase节点失败的情况下，假设节点不可恢复，我应该删除相应的Web服务器吗？这可能看起来不直观，但我理解的情况如下：
-
Couchbase节点＃1死亡
-
Web服务器＃1（连接到Couchbase节点＃1） Build 与下一个可用节点的连接，Couchbase节点＃2（大多数SDK处理此问题，FAIA）
-
Couchbase节点＃2现在有2个已 Build 的连接;来自Web服务器＃2（其相应的服务器），现在也来自Web服务器＃1（其相应的Couchbase节点已死）
我担心的是，当与单个节点 Build 多个连接时，我注意到Couchbase Server的短暂端口耗尽问题 . This generally results in client timeouts：
获取http://0.0.0.0:8091/pools：拨打tcp 0.0.0.0:8091：操作超时
同样，基于此，我是否还应该在Couchbase节点死亡时删除相应的Web服务器，以避免与同一Couchbase节点的多个连接以及潜在的短暂端口耗尽？
1 回答
Web服务器和Couchbase节点之间没有1：1的关系 . 每个Web服务器都与每个Couchbase节点 Build 连接 . 在Couchbase中，群集的每个节点都有一个活动的整个数据集的百分比，而不是完整副本 . Couchbase自动对数据进行分片，这些分片（vBuckets）在整个群集中均匀分布 .
因此，当Web服务器或应用服务器要读/写对象时，它将转到拥有该对象所在的vBucket的集群中的相应节点 . 在Couchbase SDK中，有一个一致的散列，它接受每个对象的ID，并且散列的输出是1到1024之间的数字 . 有1024个活动的vBuckets，每个副本有另外1024个 . 所以该一致的输出是vBucket对象将存在的ID . 有意义吗？然后，SDK会快速查找其群集映射的副本（在群集拓扑发生更改时会更新），该群集的哪个节点会生成分片，然后直接与该对象的特定节点进行交互 .
所以你的失败场景不太正确 . 如果Couchbase群集的节点发生故障，则只有该节点上的vBuckets不可用 . 所以只占整个数据集的一定百分比 . 如果您打开了自动故障（默认情况下已关闭），则在群集中设置超时后，群集将自动将节点超时失败并将副本vBuckets提升为活动状态，从而使您返回到100％活动数据集 . 群集基本上牺牲了那些副本vBuckets . 由于这是拓扑更改，因此使用SDK将新的群集映射发送到您的客户端应用程序并进行实时移动 . 此外，您需要对群集进行重新 balancer ，以重新生成那些现在丢失的副本vBuckets并使您恢复正常 .
至于您的短暂端口耗尽，您如何管理与群集的连接？您是否每次重用连接或打开新连接然后不关闭它们？你想要打开连接并重用它们，而不是一遍又一遍地打开新的连接 . 如果你每次都打开新的并且不清理，你肯定会耗尽你的端口，因此文件描述符 . 就像我说的，重用它们 .