Redis集群搭建最少节点数到底得几个才能稳定运行呢？

要回答Redis集群最少节点数这个问题，不能简单地只给一个数字，因为“稳定运行”这个标准包含了不同的层面，我们从最基本的情况开始说，然后一步步分析怎样才算真正的“稳”。

最最基础的搭建：3个主节点

根据Redis官方文档（来源：Redis官方文档关于集群的说明）的明确规定，一个能正常工作的Redis集群，最少需要3个主节点，为什么是这个数？这主要是由集群的核心机制——数据分片和故障转移——决定的。

Redis集群会把所有的数据分成16384个槽位（slots），这些槽位需要均匀地分配给集群里的主节点，如果只有2个主节点，虽然也能分槽（比如一人一半），但会带来一个致命问题：脑裂。

想象一下，如果两个主节点之间的网络突然断开了，每个节点都认为对方下线了，这时，它们都可能尝试把自己变成唯一的主节点来接管整个集群的服务，但数据是分开的，客户端可能一部分连到节点A，一部分连到节点B，得到的数据不一致，整个集群就乱套了，而3个节点形成了一个“奇数”的投票团体，当网络分区发生时，拥有至少2个节点的那个分区（也就是多数派）可以继续提供服务，而只有1个节点的少数派会被隔离，这样就避免了脑裂，保证了数据的最终一致性,3个主节点是保证集群逻辑正确性的最低门槛。

能工作就算稳定吗？显然不够

上面说的3个主节点集群，确实“能跑起来”，但它非常脆弱，根本谈不上“稳定运行”，因为它没有任何的高可用 能力，高可用指的是，即使某个节点出故障了，整个集群还能继续提供服务,数据也不会丢失。

在这个只有3个主节点的集群里，任何一个主节点如果宕机了，会发生什么？这个节点负责的所有槽位就“失效”了，因为没人能处理这些槽位上的读写请求，客户端在访问这些槽位的数据时，会收到错误，整个集群就部分不可用了，虽然另外两个主节点还活着，但整个集群已经残废了，这显然不符合我们对“稳定”的期望。

迈向稳定：3主3从的标配

要实现高可用，就必须为每个主节点配备至少一个“备胎”，也就是从节点，这样，当任何一个主节点宕机时，它的从节点会立即被投票选举为新的主节点，接管原来主节点的工作，集群几乎可以在秒级内自动完成故障转移，业务层面可能只感受到瞬间的卡顿,但不会出现长时间的服务中断。

业界公认的、能够稳定运行的Redis集群最低配置是：3个主节点 + 3个从节点，一共6个节点。

在这种配置下：

1. 数据安全有保障：每个主节点的数据都在其从节点上有完整的备份。
2. 高可用：允许最多一个主节点同时宕机（不能是同一个主从对的两个节点都宕机）,集群依然能正常服务。
3. 避免脑裂：3个主节点的奇数投票机制依然有效。

特殊情况下的考量

那有没有可能用少于6个节点呢？技术上存在一些“凑合”的方案,但都不推荐用于生产环境。

有人会问能不能用3个节点，每个节点同时运行主进程和从进程？也就是所谓的“伪集群”，让一个物理服务器运行两个Redis实例，一个当主，一个当从,这样3台机器也能凑出3主3从。

这种做法非常不推荐，因为一旦这台物理服务器本身宕机或者网络出现严重问题，它上面运行的主进程和从进程会同时挂掉，这意味着你一下子损失了一个主节点和它的唯一备份，故障转移无法触发，这个主节点负责的槽位数据就完全不可用了，这违背了主从节点应该跨物理机/虚拟机部署的基本原则,无法真正实现高可用。

直接回答你的问题：

• 能让集群程序跑起来的最少节点数是：3个（全是主节点）。 但这非常脆弱,一碰就碎。
• 能称得上“稳定运行”（具备高可用能力）的最少节点数是：6个（3主3从）。 这是经过实践检验的、用于生产环境的起步配置。

如果你只是在自己电脑上做测试、学习集群的基本操作，用3个节点没问题，但只要你打算用到正式环境，追求服务的稳定性，就应该毫不犹豫地选择6个节点作为起点，在分布式系统的领域里，在节点数量上“抠门”,很可能会在后续的运维和故障处理中付出更大的代价。