Architecture Couchbase群集故障转移体系结构

我在文档的应用程序堆栈部分提到了Couchbase服务器，概述了Couchbase集群所需的体系结构

我注意到图中的5个Couchbase节点都有相应的web服务器。我还知道Couchbase SDK旨在建立到单个节点的连接，并为所有请求保留该连接，故障转移事件除外

首先，我想确认图中的5个web服务器中的每一个都将建立到5个Couchbase节点之一的单个连接。我假设会产生1:1的关系；每个web服务器将连接到相应的Couchbase节点，这样就不会有两个web服务器建立到同一Couchbase节点的连接

如果是这种情况，那么在Couchbase节点发生故障的情况下，假设节点不可恢复，我是否应该删除相应的web服务器？这似乎不直观，但据我所知，情况如下：

Couchbase节点#1

Web服务器1（连接到Couchbase节点1）建立到下一个可用节点Couchbase节点2的连接（大多数SDK处理此问题，FAIA）

Couchbase节点#2现在有2个已建立的连接；来自web服务器#2（其对应的服务器），现在也来自web服务器#1（其对应的Couchbase节点已关闭）

我担心的是，我注意到Couchbase Server在与单个节点建立1个以上连接时会出现短暂的端口耗尽问题：

Get:拨号tcp 0.0.0.0:8091:操作已计时 出去

---

同样，基于此，我是否应该在Couchbase节点死亡时删除相应的web服务器，以避免多个连接到同一Couchbase节点，以及可能的临时端口耗尽？

web服务器和Couchbase节点之间没有1:1的关系。每个web服务器都有到每个Couchbase节点的连接。在Couchbase中，集群的每个节点在整个数据集中都有一定百分比处于活动状态，而不是完整副本。Couchbase自动对数据进行分片，这些分片（vBuckets）均匀分布在整个集群中

因此，当web服务器或app server要读/写对象时，它将转到集群中拥有该对象所在的vBucket的相应节点。在Couchbase SDK中，有一个采用每个对象ID的一致散列，散列的输出是一个介于1和1024之间的数字。有1024个活动VBucket，每个副本还有1024个。因此，该一致has的输出是对象将居住的vBucket ID。有道理？然后SDK快速查找其集群映射副本（该副本在集群拓扑发生变化时随时更新），查找碎片所在集群的哪个节点，然后直接与该对象的特定节点进行交互

所以你的失败场景并不完全正确。如果Couchbase群集的某个节点出现故障，则只有该节点上的vBuckets不可用。所以只占整个数据集的一个百分比。如果已启用自动故障（默认情况下为关闭），则在集群中设置超时后，集群将自动使节点超时并将副本vBuckets升级为活动，从而使您返回到100%活动数据集。集群基本上牺牲了那些副本Vbucket。因为这是一个拓扑更改，所以会将一个新的集群映射发送到带有SDK的客户端应用程序，并继续直播。此外，您还需要对集群进行重新平衡，以重新生成那些现在丢失的副本VBucket并使您恢复正常

至于短暂的端口耗尽，您是如何管理到集群的连接的？您是重复使用连接还是每次都打开新连接，然后不关闭它们？您希望打开连接并重用它们，而不仅仅是一次又一次地打开新的连接。如果您每次都打开新的端口而不进行清理，那么您肯定会耗尽您的端口，从而耗尽文件描述符。就像我说的，重复使用它们