为什么在集群中需要三个节点？

2 年 ago

清, 宇

1 minute

为了提高系统的可用性，经常会使用聚类技术。有很多软件推荐在聚类中使用3个或更多的节点，但对于这个理由并没有详细的说明。现在，假设使用像 The Raft 一致性算法这样的算法，其中聚类成员在构建聚类时相互确认彼此的状态，我想总结一下为什么要使用“3”，以及在构建聚类时需要注意的要点。这个写作的契机是看到 Google Cloud Platform 东京区域从一开始就发布了3个区域。我推测他们之所以从一开始就考虑到聚类配置可能，提前准备好3个区域。

举个例子，需求为3的东西

我将列出一些推荐使用至少三个节点的软件。请仅阅读直译内容作参考。

Redis (a data structure server)

请注意，最小的工作正常的集群需要至少包含三个主节点。建议您在进行首次测试时启动一个包含三个主节点和三个从节点共计六个节点的集群。

MariaDB Galera集群

最小集群大小
为了避免出现脑裂状态，建议集群中的最小节点数为3个。阻塞状态传输是需要至少3个节点以保证在其中一个节点失败并需要重新启动时，服务仍然可用的另一个原因。当有2个成员进行状态传输时，剩余的成员仍然能够继续为客户端请求提供服务。

etcd（etcd是一种分布式键值存储系统）

最佳集群大小
根据容错需求，推荐的etcd集群大小为3、5或7。在大多数情况下，7个成员的集群可以提供足够的容错性。虽然较大的集群提供更好的容错性，但由于数据需要复制到更多的机器，写入性能会降低。

领事

我们建议每个数据中心使用3或5台服务器。在故障情况下，单一服务器部署是高度不推荐的，因为数据丢失是不可避免的。

Influxdb 数据库

InfluxDB集群模型
InfluxDB支持任意大小的集群，以及从1到集群中节点数量的任意复制因子。
InfluxDB集群中有三种类型的节点：共识节点、数据节点和混合节点。一个集群必须有一个奇数个运行共识服务的节点才能形成一个Raft共识组并保持健康状态。

在中文中，可以这样改写：
等等。
确实还有一些提到要推荐使用3个节点的描述。还提到了一些词，如容错性和分裂大脑。此外，在InfluxDB中，没有明确指定要使用3个节点，但要求节点数必须为奇数。

在选择集群时要考虑什么？

在分散系统中存在一定理论，称为 CAP 定理，它由以下三个字母所代表。

Partition Tolerance (分割耐性)

「Consistency（一致性）」是决定数据的“正确”是哪一个的东西（稍后会解释）。
关于“Availability（可用性）”，是指持续运行服务而不中断。之前提到的容错性定义了可以容忍或考虑的节点故障数。
最后，“Partition Tolerance（分区容忍性）”是关于由多个节点组成的集群在网络等方面被分隔的情况下的容忍性。拆分脑指的是发生了这种分隔状态（理解为大脑分裂成两个或以上的状态会比较好）。在这里重要的是想要继续提供服务，所以必须要判断在分隔状态下选择哪一个。在做出判断时通常会使用多数决定（多数派），因此需要有3个以上的节点才能成立。这就是为什么需要3个的重要原因。

接下来，我想用图示来解释当集群分裂时会发生什么动作。

分割成图解

如果有一个包含3个节点的集群。

※ 赤点线＝被断开的部分
从节点1和节点2的角度来看，节点3已经消失了，但是由于仍有过半数的节点仍在运行，所以系统可以继续运行。然而，从节点3的角度来看，由于已经下降到少于过半数，它将停止自己的运行。停止运行的原因将在后文中解释。

如果有四个节点的集群

※ 红色虚线 = 断开的部分
在这种情况下，会发生完全断开。
当节点聚集成4个时，大多数为3，所以维持这种情况可以继续运行。在上图的情况下，无论哪种情况，大多数都会被打破，所有节点都将不得不停止运行。

如果存在这种可能性的话，这个由4个节点构成的设置将被认为是设计上的错误，因为我们应该想要在发生故障时继续处理。如果处理性能没有问题，则需要考虑将其更改为3个节点集群；如果处理性能不足，则需考虑将其更改为5个节点（然而，需要注意的是，增加节点数量会导致数据复制等开销变大，不一定会提高性能）。

节点数量与多数派、容错性之间的相关性

在考虑集群节点数量时，可以根据以下表格进行考虑。这是一个在许多地方广泛使用的表格。

ノード数マジョリティフォルトトレランス数110220321431532642

这可以用以下来表示，不是吗？

フォルトトレランス数 ＝ ノード数 - マジョリティ

我之前解释过，”majority”指的是超过一半的数量，”fault tolerance”是指可以容忍故障的节点数量。
仅仅增加节点的数量，并不会提高容错性（即故障容忍数）。举个例子，在4个节点的集群图中，如果发生了分割，有可能比3个节点的集群更容易受到故障的影响，所以需要注意。
我建议将节点数量设置为奇数。

为什么一旦过半数割成就会停止？

为了保持一致性（一貫性），当集群分裂时，有可能会将客户端发送的写请求发送到被分裂的两个节点。如果继续处理，将很难确定哪个写入的数据是正确的。因此，我们选择关闭较少的节点来保持数据的一致性。毕竟，数据比可用性更重要。

我会考虑位置

在设计处理群集的开源软件等节点配置时，还必须考虑位置。例如，在云（IaaS）上将3个节点的群集部署在两个区域中，将导致一个区域有两个节点。不幸的是，如果拥有两个节点的整个区域出现故障，该群集将无法正常工作。因此，需要考虑到可能发生的基础设施故障，并设计出最安全的配置。我认为，Google Cloud Platform东京区域在一开始提供了三个区域，是为了严格实现这一设计要求。

額外說明

有些集群在考虑超过半数的情况下并不存在。
例如，作为键值存储系统的Apache Cassandra、Basho Riak和AeroSpike。这些系统是基于Amazon于2007年推出的Dynamo开发的，通过使用向量时钟(Vector Clock)和一致性哈希(Consistent Hashing)等技术，实现了具有数据一致性和高容错性的集群化。
我曾经在Riak上实际进行了网络分断的情况下进行数据写入的实验，即使在分断期间，系统仍然可以继续处理。而且，在分断恢复后，系统会自动重新分配和修复数据，并恢复到正常状态，这让我感到非常震撼。

总结

ロケーションも意識することでより強固に

请注意，并不是所有集群数据技术都适用。祝您度过愉快的集群生活。