Redis主从节点搭配很关键，数量多了少了都不行，得找个平衡点才稳

（引用来源：主要基于普遍的分布式系统运维经验和Redis社区的最佳实践讨论）

Redis主从节点搭配这件事,说白了就像家里请人帮忙干活，你不能什么事都自己扛，那会累死，这就是只有一个主节点，万一它宕机了，整个服务就全停了，非常危险，但你也不能呼啦啦请来几十号人，都挤在一个小房间里，你指挥他们还得靠喊，结果光协调沟通就花了大部分时间，真正干活的效率反而低了，甚至可能因为指令传错、人员碰撞引出更多乱子，这个“平衡点”确实非常关键，多了少了都麻烦。

我们先说“少了不行”的情况，最极端的就是只有一个光杆司令的主节点，没有任何从节点，这种情况下，系统是非常脆弱的，主节点一旦因为硬件故障、网络问题或者单纯的负载过高而宕机，整个依赖Redis的服务就会瞬间不可用，虽然Redis有持久化机制（RDB快照和AOF日志），但重启主节点并从磁盘加载数据需要时间，这段时间服务依然是中断的，对于要求高可用的线上业务来说，这是无法接受的，至少配置一个从节点是底线，这个从节点就像主节点的备份，平时默默地同步主节点的数据，一旦主节点挂了，可以手动（甚至通过哨兵机制自动）把这个从节点提升为新的主节点，让服务尽快恢复，这就实现了基本的故障转移。

那是不是从节点越多就越好呢？绝对不是，这就是“多了也不行”的问题，从节点数量的增加会带来几个明显的负担：

是对主节点的性能压力,每一个从节点建立连接后，主节点都需要为其单独fork出一个子进程来生成RDB快照文件（如果是全量同步的话），并且要持续地将自己的写命令转发（复制）给每一个从节点，这个复制过程是异步的，但毕竟需要消耗主节点的CPU、内存和网络带宽，当从节点数量增加到一定程度，主节点可能就需要耗费相当一部分资源来“伺候”这些从节点，这就会影响它处理正常客户端请求的性能，就像一个厨师，如果只顾着不停地向十个帮厨讲解每道菜的做法，他自己炒菜的速度自然就慢下来了。

是网络带宽的压力,特别是在需要做全量同步的时候（比如新加入一个从节点，或者从节点落后太多数据时），主节点需要将整个数据集通过网络传输给从节点，如果数据量很大（比如几十个GB），而网络带宽有限，这个同步过程会非常漫长，期间会占用大量带宽，可能影响其他服务的网络通信，如果同时有多个从节点需要全量同步，那网络很可能就直接堵死了。

是数据一致性的风险,Redis的复制是异步的，这意味着主节点收到写命令后，会先回复客户端成功，然后再异步地将命令发送给从节点，如果主节点在命令还没发送给某个从节点的时候就宕机了，那么这部分数据就丢失了，即使这个从节点被提升为新主，数据也是不完整的，从节点越多，在极端情况下，每个从节点同步的进度可能都会有细微差别，数据不一致的风险理论上会有所增加（尽管概率很小），管理和监控大量从节点的同步状态，本身也变得更复杂。

这个“平衡点”到底在哪里呢？这并没有一个放之四海而皆准的数字，完全取决于你的具体业务需求，你需要考虑几个因素：

1. 读压力有多大？ 这是决定从节点数量的首要因素，如果你的应用主要是写操作，读请求不多，那一主一从或一主二从可能就足够了，重点在于容灾备份，但如果你的读请求非常密集，单个节点扛不住，那就需要增加从节点来分担读流量（通过将读请求引导到从节点上），这就是读写分离，这时候，你需要评估读QPS（每秒查询率），估算出大概需要几个节点才能撑住。

2. 可用的资源有多少？ 包括主节点的硬件资源（CPU、内存）和网络带宽，你需要确保增加从节点后，不会把主节点拖垮，也不会挤占关键业务的带宽，在资源紧张的环境下，就需要精打细算。

3. 对故障恢复速度的要求有多高？ 虽然一主一从就能实现故障转移，但如果这个唯一的从节点也坏了呢？为了更高的可靠性，有些人会采用“一主二从”的架构，这样即使一个从节点故障，仍然有另一个备用节点，提供了冗余中的冗余，在一些极端重要的场景，可能还会部署更多从节点，甚至跨机房部署。

4. 数据的价值和对不一致的容忍度。 如果数据极其重要，不能容忍任何丢失，那么你可能需要研究更高级的同步机制（如半同步复制，但Redis官方版本不支持），或者接受更多从节点带来的性能损耗，以换取更低的丢失风险。

Redis主从架构的搭建,是一个典型的权衡艺术，它不是在追求一个理论上的完美数字，而是在你的业务需求（读性能、高可用性）、资源约束（硬件、网络）和运维复杂度之间，找到一个最适合当前阶段的平衡状态，这个状态可能随着业务量的增长而动态变化，一开始一主一从够用，后来可能就需要扩容到一主三从，核心在于，你要清楚地知道增加或减少一个从节点，所带来的好处和代价分别是什么，然后做出明智的选择。