为什么redis cluster至少需要三个主节点

redis cluster至少需要三个主节点的原因：1、性能和成本效益；2、滚动更新；3、存储；4、故障转移协商和脑裂。性能和成本效益是指，如果某个节点在三节点群集中发生故障，则只有三分之一的群集资源会消失。

1、性能和成本效益

考虑建立双节点群集所需的资源。你可以决定在群集的两个节点之间拆分工作负载（称为主动/主动群集），但由于其中一个节点都可能发生故障，因此另一个节点必须能够随时承担所有群集工作负载（VM 和数据）。这意味着每个节点都需要足够的资源来运行所有组合的工作负载，以及维持正常运行和允许额外增长的一些开销。这意味着运行所有内容所需的所有 CPU、RAM 和存储。

在双节点群集中，实际计算资源使用率始终需要小于群集中可用资源的 50%（实际上可能小于 45%，因此每个节点至少有 10% 的可用资源）。与三节点群集相比，在某些情况下，您可以使用多达 67% 或更多，并且仍然可以吸收全节点故障。如果某个节点在三节点群集中发生故障，则只有三分之一的群集资源会消失。当丢失节点中的工作负载故障转移到剩余的两个节点时，可以在剩余的两个节点之间拆分它们，并且剩余的两个节点可以比单个剩余节点更轻松地分担资源负担。

当一个节点在三节点群集中发生故障时，您只剩下两个节点，就像双节点群集一样，但是，在还原丢失的节点之前，另一个节点发生故障的可能性非常小，您不必在资源分配中考虑它。您只需要考虑一次发生故障的三个节点中的一个。将资源分散到三个节点而不是两个节点上意味着每个节点永远不会运行整个群集工作负载，并且服务器规格不需要那么高即可保持可接受或等效的性能，从而节省购买服务器的成本。

另一个需要考虑的性能因素是重建故障节点的性能成本，这在双节点群集中尤为严重。当两个节点中的一个发生故障时，另一个节点不仅必须承担所有群集工作负载，直到另一个节点恢复，而且还必须在恢复的节点重新联机时重建该节点，发送数据，直到该节点再次成为完全冗余的伙伴。这会给运行所有群集工作负载的群集的主动节点带来额外的性能负载，直到其他节点完全恢复。在三节点群集中，修复过程不太重要，因为即使第三个节点发生故障，其余两个节点仍继续充当群集。存储仍然可以保持冗余，当第三个节点恢复时，跨群集重新平衡数据和工作负载所需的重建强度要低得多。

2、滚动更新

群集还可以提供将更新应用于单个节点的功能，而无需通过先将这些工作负载移动到群集的另一个节点来使群集工作负载脱机。这称为滚动更新，因为工作负载在更新发生时从一个节点滚动到另一个节点。在双节点群集中，此过程始终仅限于在更新时将所有工作负载移动到单个节点。

在真正的故障/故障转移情况下（比更新更不常见），您更有可能忍受性能降级，因为强制单个节点运行每个工作负载可能会强调其资源限制。您是否也愿意在每次要使用新软件/固件更新群集时忍受性能下降？应该不会。因此，除了需要指定每个节点足够大以运行故障转移方案中的每个工作负载之外，还必须考虑每次需要应用更新时，规范需要多大才能轻松运行所有工作负载。规格越大，成本越高。

在三节点群集中，由于您有两个其他节点在故障转移或更新期间拆分工作负载，因此当节点脱机进行维护时，您可以以较低的规格和更低的成本提供合理的性能。

3、存储

据已经说明的成本效益，您可能会问：“如果我使用 SAN 或 NAS 等共享存储设备，该怎么办？嗯，曾经有一段时间，这是创建高可用性集群的少数方法，但时代已经改变。如果您使用共享存储设备，则只需将成本转移到单独的硬件上即可。您的存储设备是否也群集以实现高可用性，或者它现在是群集的单点故障？

存储也应群集以实现高可用性，现在您具有相同的双节点群集注意事项。例外情况是，对于存储，您始终希望复制因子至少为 2，这意味着无论您有多少节点，您的可用存储都将始终小于原始存储的 50%。与两个节点相比，使用三个节点不会获得更好的资源效率，但确实可以获得更好的高可用性。

用于群集的共享存储设备在软件定义存储的现代世界中是一个过时的想法。通过在群集节点上使用软件定义的存储和存储资源，将存储分布在群集中的三个或更多节点上比尝试单独群集多个存储设备要容易得多。它也更具成本效益。

4、故障转移协商和脑裂

在双节点群集中，群集逻辑更难确定在存在通信（网络）问题而不是节点故障时要执行的操作。如果群集节点彼此之间失去通信，节点如何知道是否从无法与之通信的节点故障转移工作负载？通常，这是通过某种群集见证来处理的。集群见证（或在某些情况下的多个见证人）是第三个接触点，理论上，它仍然可以通过一个或两个节点联系，并且可以仲裁集群状态。见证服务器必须位于群集外部，因此除了群集之外，它将成为网络中要管理的另一个对象。

如前所述，这在“理论上”有效，但实际上，它更复杂。与真正的第三个节点不同，群集见证服务器并不是群集的真正完全活动成员，并且其对群集状态的评估也可能受到通信问题的阻碍。糟糕的见证实施可能会使群集陷入可怕的裂脑场景，其中两个节点都开始运行所有工作负载，一旦发生这种情况，恢复将是一场噩梦。1 为了进一步阅读，本文探讨了基于强化企业级服务器与双节点备用服务器对/集群的架构与集成自主超融合系统（如 Scale Computing Platform）的架构的成本和运营优缺点。

至少具有三个节点可以确保群集始终具有节点仲裁，以维护正常运行的主动群集。对于两个节点，仲裁不存在。没有它，就不可能可靠地确定既能最大限度地提高可用性又能防止数据损坏的行动方案。当然，没有什么是绝对可靠的，即使是三节点群集也可能因网络问题和仲裁丢失而脱机。但是，如果发生这种情况，则可能会发生比群集脱机更大的问题，并且使用三节点群集进入裂脑方案的可能性几乎为零。

延伸阅读

Redis Cluster集群

Redis Cluster是Redis的分布式解决方案，在Redis 3.0版本正式推出的，有效解决了Redis分布式方面的需求。当遇到单机内存、并发、流量等瓶颈时，可以采用Cluster架构达到负载均衡的目的。分布式集群首要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整个数据的一个子集。Redis Cluster采用哈希分区规则中的虚拟槽分区。虚拟槽分区巧妙地使用了哈希空间，使用分散度良好的哈希函数把所有的数据映射到一个固定范围内的整数集合，整数定义为槽（slot）。Redis Cluster槽的范围是0 ～ 16383。槽是集群内数据管理和迁移的基本单位。采用大范围的槽的主要目的是为了方便数据的拆分和集群的扩展，每个节点负责一定数量的槽。Redis Cluster采用虚拟槽分区，所有的键根据哈希函数映射到0 ～ 16383，计算公式：slot = CRC16(key)&16383。每一个实节点负责维护一部分槽以及槽所映射的键值数据。