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