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