企业官网建设流程全解析

1. 主从复制到底解决了什么问题：单机 Redis 的天花板与破局点

先从一个朴素的问题说起：为什么 Redis 要搞主从复制？

如果你只在本地跑一个 Redis 实例做缓存，数据量不超过几个 GB，读写压力也没到瓶颈，那主从复制对你确实没什么存在感。但一旦进入生产环境，问题就接踵而至。单机 Redis 有三道绕不过去的坎——可用性、读性能、数据可靠性。主从复制就是冲着这三道坎去的。

可用性层面的逻辑很好理解：Redis 进程本身不是神，服务器宕机、内存故障、机房断电，任何一个意外都能让 redis-server 直接消失。如果只有一台实例，所有请求瞬间全部失败，上游缓存击穿，数据库被流量打满，事故等级直接拉满。主从复制准备了多份数据副本，主节点挂了从节点能顶上去，这是 Redis 高可用架构的地基。

读性能层面更直观。Redis 虽然是内存数据库，单线程处理命令的能力很强，但单实例的 QPS 终究有上限，尤其在大量读多写少的业务里，把所有读流量压在一个实例上并不划算。挂几个从节点，读请求均匀分摊出去，主节点专注处理写请求，整体吞吐量会有一个非常明显的提升。我见过不少团队在没有做主从分离的时候，主节点 CPU 已经冲到 70% 以上，加了两个从节点之后直接降到 30%，效果立竿见影。

数据可靠性这块容易被低估。很多人以为 Redis 有 RDB 和 AOF 两种持久化就够了，但持久化解决的是"进程退出后从磁盘恢复"的问题，解决不了"整台机器物理损坏"的问题。磁盘和机器一同报废的时候，本地持久化文件也没了。从节点只要有完整副本，你就能在另一台机器上快速拉起服务。另外从节点还承担了一个很实在的功能——可以在从节点上执行 BGSAVE 生成备份文件，完全不阻塞主节点。这个操作在官方文档里叫"replication backup"，生产环境做定期备份基本都推荐这么干。

一句话总结就是：主从复制是 Redis 从"单机缓存工具"进化为"分布式缓存系统"的第一个台阶。它不解决数据分片问题，不解决自动故障转移问题（那是哨兵的事），但它是这一切的地基。理解主从复制的底层机制，后面看哨兵、看集群都会顺畅很多。

2. 一次全量同步的完整旅程：RDB 快照、缓冲区与复制积压队列

全量同步是主从复制中最重量级、也最容易出问题的环节。我把它的完整流程拆开讲，每一步都有对应的源码逻辑做支撑。

先明确一件事：全量同步什么时候会发生？最常见的触发场景有三个——从节点第一次连接主节点、从节点与主节点的复制偏移量差距过大导致部分重同步失败、主节点重启导致 replid 变化。不管是哪种，本质都是从节点手上没有任何可用的增量同步基础，必须把主节点的全量数据搬过来。

一次标准全量同步的过程是这样的：

第一步，从节点启动后，在配置里指定了 replicaof 主节点的地址和端口，它会主动向主节点发送PSYNC命令。这个命令携带两个参数：replid和offset。第一次连接时从节点没有 replid，会传一个问号?，offset 传-1。主节点收到之后发现这是个完全陌生的复制请求，于是返回+FULLRESYNC <replid> <offset>，表示同意发起全量同步。

第二步，主节点执行BGSAVE生成 RDB 快照文件。注意，这里是后台子进程做持久化，主线程继续服务读写请求，所以主节点的服务不会中断。BGSAVE 期间写入的新数据不会进 RDB 文件，但这部分数据也不会丢——它们会同时写入复制积压缓冲区（repl_backlog），这个缓冲区在后面的增量同步里还会发挥关键作用。

第三步，RDB 文件生成完毕，主节点通过网络把文件发送给从节点。从节点收到后先把文件存到磁盘（默认是 dump.rdb），再加载到内存。这一步很好理解，相当于把主节点某个时间点的全量内存快照完整还原到从节点。

第四步，也是很容易被忽略的一步——RDB 加载完成之后，从节点会把复制积压缓冲区里积攒的写命令补发过来。为什么需要这一步？因为从节点加载 RDB 期间，主节点并没有停下来，新的写命令一直在产生。这些命令里有一部分已经进了 RDB 文件（BGSAVE 开始前的数据），有一部分没有（BGSAVE 期间和之后的新命令）。如果不补发，从节点的数据会停留在老时间点，和主节点不一致。

第五步，从节点补发完这些命令之后，正式进入增量同步模式，变成主节点的忠实副本。它一边处理自己的读请求，一边接收主节点的写命令流并应用到自己的内存里。

这里要特别解释一下复制积压缓冲区（repl_backlog）。它是一个环形缓冲区，默认大小 1MB，由参数repl-backlog-size控制。主节点会把每个写命令都往这个缓冲区里塞一份，从节点消费命令时也会回报自己的复制偏移量。缓冲区存在的意义就是：当从节点断线重连时，如果它断线期间主节点产生的写命令还没有撑爆这个缓冲区，那么通过PSYNC带上旧的 replid 和 offset，就能触发部分重同步，直接把断线期间的命令补发过去，不用做一次全量同步。

你可能会问：1MB 够吗？说实话默认值在写流量大的场景不太够。我习惯把它调到 64MB 到 128MB，尤其是主从节点之间网络不太稳定、断线概率较高的场景。调整方式是在 redis.conf 里改repl-backlog-size，这个参数不是动态生效的，改完需要重启主节点。至于这个缓冲区会被写命令填满的速度，有个简单估算公式：缓冲区填满时间 = repl-backlog-size ÷ 每秒写命令字节数。如果每秒写入量平均是 10KB，64MB 可以撑大约 100 分钟，绝大多数临时断线都能覆盖到。

全量同步期间的性能影响也必须说清楚。主节点执行 BGSAVE 时，fork 子进程会触发操作系统的 copy-on-write 机制，如果期间有大量写命令产生，内存页会被复制，内存占用可能短暂飙升到平时的 1.5 倍以上，CPU 也会因为 fork 和 RDB 序列化产生明显波动。所以在高负载的生产环境做全量同步，最好挑业务低峰期，或者提前评估主节点所在机器的内存余量。

# 查看主从复制状态的命令，全量同步完成后重点关注这几个字段 redis-cli> INFO replication # Replication role:master connected_slaves:1 slave0:ip=192.168.1.101,port=6379,state=online,offset=2048,lag=0 master_replid:3f7a9c2b1d8e4f5a6b7c8d9e0f1a2b3c4d5e6f7a master_repl_offset:2048

从上图能直观看到主节点的角色、从节点列表、节点状态和复制偏移量。从节点视角看过去，字段会变成 role:slave，多了 master_host、master_port、master_link_status 这些字段，其中master_link_status:up表示主从连接正常。

3. 增量同步的底层词典：replid、复制偏移量与积压缓冲区的协同机制

理解了全量同步之后，增量同步的原理就相对清晰了，但这里面的几个核心概念绕不开，尤其是 replid 和 offset，很多做 Redis 运维的同学一度被这两个概念搞晕。我用一个尽量通俗的比喻来解释整条链路。

先看三个关键角色。

replid（复制 ID）：可以理解为"数据集的一个身份标识"。每个 Redis 实例启动时都会生成一个 40 位的十六进制字符串作为自己的 replid。主从复制建立之后，从节点会把自己的 replid 改成和主节点一致。这意味着：如果两个节点拥有相同的 replid，它们在复制上属于同一血缘；如果主节点重启导致 replid 变化，所有从节点都会被迫做全量同步。这也是 Redis 5.0 之前的一个痛点，后面细说。

复制偏移量（offset）：主节点每处理一个写命令，复制偏移量加 1，从节点每接收并应用一个写命令，自己的复制偏移量也加 1。这个偏移量是一个单调递增的数字，主从双方各自维护，但理想状态下应该是相等的——因为从节点追上了主节点的所有命令。判断主从数据是否同步，最直接的指标就是对比双方的 offset。

复制积压缓冲区（repl_backlog）：上面说过了，它是主节点内存里的一个环形队列，写命令在这里面留存一段时间，用于支持断线重连后的部分重同步。从节点发送的 PSYNC 命令里携带的 offset，就是用来在这个缓冲区里定位从节点断线时的位置。

增量同步的完整流程可以这样理解：

主节点 A 和从节点 B 建立复制关系后，A 每次处理写命令，都做两件事——执行命令并更新内存数据，然后把命令追加进 repl_backlog 缓冲区。B 作为一个客户端，持续从 A 那里拉取新命令并应用到自己的内存里。这个过程是"推拉结合"的，本质上是一条持续不断的命令流。

下面用一段伪代码逻辑示意 PSYNC 命令在从节点发起时的判断过程：

def handle_psync(replid, offset): if replid == 主节点当前replid and offset == 主节点当前offset: # 已经追上，等待新命令 return OK elif replid == 主节点当前replid and offset 在 repl_backlog 范围内: # 部分重同步，补发offset之后的所有命令 send_continue(offset) else: # 全量同步 send_fullresync()

这个判断逻辑是 Redis 复制机制的精华。从节点发起 PSYNC 时带上自己的 replid 和 offset，主节点根据这两个参数决定响应方式。只要从节点的 offset 在 repl_backlog 范围内，就能走增量通道；一旦 offset 太旧、已经滑出缓冲区，或者 replid 对不上，就只能掉回全量同步。

再补充一个容易混淆的点：offset 的单位。很多人以为 offset 是"字节数"或者"命令条数"，其实它在 Redis 内部是一个累加的整数。每次主节点传播一个命令，offset 就会增加，增加的量视命令内容的长度而有所不同。所以在不同的节点上，offset 的绝对值本身不是关键，关键是主从两者 offset 的差值——差值越大说明从节点落后越多，也就是复制延迟越大。

INFO replication输出里有个lag字段，它表示从节点最后一次向主节点发送 ACK 之后过去了多少秒。lag 越大说明从节点心跳越慢，通常意味着网络条件不好或者从节点负载过高。我个人对 lag 的关注度比对 offset 差值更高，因为 offset 差值只能说明"总量差距"，而 lag 直接告诉你"当前这条链路还活着没有"。

4. 从 PSYNC 到 PSYNC2.0：主从复制经历了哪些关键版本变更

Redis 主从复制不是一开始就这么完善的，理解它的演进历史能帮你少踩很多坑。我挑几个关键的版本节点说。

Redis 2.8 之前：SYNC 的时代。最早的复制命令叫 SYNC。它没有任何增量同步的概念，每次从节点断线重连，主节点都必须做一次全量 RDB 传输。如果主从之间的网络抖动频繁，主节点会被反复触发 BGSAVE，CPU 和磁盘 I/O 被持续消耗，整个集群的性能被拖垮。这是早期 Redis 复制最让人头疼的问题。

Redis 2.8：PSYNC 诞生。PSYNC 命令首次引入了"部分重同步"的机制，核心就是上面的 replid 和 offset 配合 repl_backlog。从节点断线重连后，只要 offset 还在积压缓冲区内，就能只补发缺漏的命令，避免全量同步。这个版本标志着 Redis 主从复制从"暴力全量"进入"尽可能增量"的阶段。

Redis 4.0：PSYNC2.0 的重大改进。PSYNC2.0 解决了一个很经典的痛点——主节点切换后的全量同步问题。场景是这样的：主节点 A 挂了，从节点 B 通过哨兵晋升为新的主节点。此时旧主节点 A 恢复后重新加入集群，它会发现自己和 B 的复制关系断了。在 PSYNC2.0 之前，A 只能向 B 请求全量同步，因为 A 的 replid 和 B 的 replid 不同。但 PSYNC2.0 引入了 replid 历史机制：

新主节点 B 在晋升后并不会丢弃旧的 replid，而是保存两个复制 ID——一个是自己的新 replid，一个是"旧主节点的 replid"（称为 secondary replid）。当旧主节点 A 恢复并尝试与新主 B 建立复制时，B 发现 A 携带的 replid 和自己的 secondary replid 匹配，同时 A 的 offset 也在积压缓冲区内，于是直接允许 A 走增量同步，避免了全量同步。这个改进在故障切换场景下帮助巨大，尤其是从节点数量多的集群，省掉的是好几台机器的全量数据搬移。

Redis 5.0 之后的细节优化。比如从节点在故障转移后能够更快地清理旧数据，复制流程中增加了一些异常处理机制。到了 Redis 7.0 之后，复制模块基本稳定，主要优化围绕在降低全量同步期间的资源开销上。

搞清这些版本变更的意义在哪里？主要在两点。第一，如果你的 Redis 版本还停留在 4.0 以下，遇到主从切换后大规模全量同步引发的性能问题，先考虑升级版本，不要在配置层面做无谓的折腾。第二，理解 PSYNC2.0 之后，你才能更准确地判断一个问题——某个从节点断开后重连，到底是会走增量还是全量。判断依据就是我上面贴的那段逻辑：replid 是否匹配，offset 是否还在缓冲区范围内。

我在生产环境见过一个特别典型的案例：某团队的主从节点之间网络经常抖动，每次抖动恢复后，所有从节点都触发全量同步，主节点 CPU 直接飙到 90% 以上。排查了很长时间，最后发现他们的 Redis 版本是 3.2，根本没有 PSYNC2.0，每次抖动后旧的从节点重连时，如果恰好赶上主从角色发生过切换，就必然全量。升级到 6.2 并调大了 repl-backlog-size 之后，网络抖动恢复时基本都能走增量同步，主节点负载再也没出现异常尖峰。这就是理解版本差异带来的实际收益。

5. 从零搭建一套主从复制：配置、验证与常见踩坑点

说了这么多原理，如果你还没亲手搭过一套主从复制，那我强烈建议现在就操作一遍。纸上得来终觉浅，下面给一份可以直接照做的实操路径。

最简单的搭建方式是使用replicaof命令。我以一台主节点和一台从节点为例，假设主节点 IP 是 192.168.1.100，端口 6379，从节点 IP 是 192.168.1.101，端口 6379。

在从节点的 redis.conf 里加入一行：

replicaof 192.168.1.100 6379

如果不想改配置文件，也可以运行时直接执行命令，效果相同，但重启后失效：

redis-cli> REPLICAOF 192.168.1.100 6379

注意一个兼容性细节：旧版语法用的是SLAVEOF，从 Redis 5.0 开始官方统一改成REPLICAOF，因为 "slave" 这个词带有贬义色彩，社区做了术语调整。如果你在 Redis 6.x 上执行 SLAVEOF，它仍然能用，但会提示这是一个废弃命令。这个细节对老运维比较友好，新手直接用 REPLICAOF 就行。

配置完之后，在从节点执行：

redis-cli> INFO replication # Replication role:slave master_host:192.168.1.100 master_port:6379 master_link_status:up master_last_io_seconds_ago:0 master_sync_in_progress:0 slave_read_repl_offset:4096 slave_repl_offset:4096

看到master_link_status:up且master_sync_in_progress:0，就说明主从复制已经建立完成，从节点正在持续接收主节点的命令流。

为了确认数据同步是否真的在跑，可以做一个简单测试：在主节点写入一个 key，然后在从节点查询。

# 主节点 redis-cli> SET name "redis-master" OK # 从节点 redis-cli> GET name "redis-master"

能查到说明数据流是通的。但这里有一个很关键的坑需要提——从节点默认是只读的。你直接往从节点写数据，会收到一个READONLY错误。这是 Redis 的安全设计，防止主从数据不一致。如果确实需要在从节点写入数据（比如特殊的一些场景），可以动态修改：

# 或者在运行时执行 replica-read-only no

但我要强烈建议你不要这么做。从节点写数据会破坏主从一致性，而且一旦遭遇全量同步，从节点上写的所有数据都会丢失，没有任何恢复手段。我见过有人为了临时解决某个问题开了从节点写权限，后来出了数据不一致的线上事故，教训非常深刻。

刚才提到密码的问题。如果主节点设置了requirepass，从节点同步时需要用密码认证自己。在从节点的配置里加一行：

masterauth yourpassword

这个配置特别容易漏。漏掉之后的表现是：从节点的master_link_status会一直显示down，日志里报NOAUTH Authentication required之类的错误。排查主从同步问题时，第一件事就应该检查认证配置。

还有一个爬坑点：主从复制不复制INFO命令的结果、不复制CONFIG SET这类管理命令、也不复制带有NOMULTI标记的特定命令。主从复制只是复制写命令流，不是复制整个实例的状态。所以从节点的maxmemory配置、maxmemory-policy配置都和主节点可以不同，这在某些场景下是有意的设计——比如从节点配置更大的内存上限，用来做读写分离场景下的读缓存。

6. 级联结构：一主多从的性能问题与树形复制拓扑

当业务量上来之后，一主两从甚至一主三从的模型会遇到一个尴尬的问题：主节点的出口带宽成了瓶颈。每次全量同步，主节点都得把完整的 RDB 文件通过网卡发给每一个从节点；平时的增量同步，每条写命令也得复制 N 份分发给所有从节点。如果从节点数量多、分布在不同机房，主节点的网络 I/O 压力会非常明显。

解决办法就是级联复制，也叫树形复制。拓扑大致是：主节点 A 下面挂一个从节点 B，然后再让 C 节点把 B 当作自己的主节点。C 的数据来源是 B，而不是直接来自 A。这样 A 只需要向 B 同步一份数据，B 再转发给 C，主节点的网络压力就小很多。命令配置很简单，在 C 节点上执行：

redis-cli> REPLICAOF 192.168.1.102 6379

这里 192.168.1.102 是 B 节点的 IP。C 节点会成为 B 的从节点，而不是 A 的"从节点的从节点"——Redis 本身没有"从节点的从节点"这个概念，C 的视角里 B 就是主节点。

级联复制的核心收益是降低主节点的数据分发压力，副作用是增加了一级数据链路延迟。B 要先收到命令再转发给 C，C 的复制延迟相对 A 直接挂从节点要高一些。好在 Redis 的复制延迟单位通常是毫秒级，对于绝大多数业务完全无感。

选型时我的建议是：从节点数量不超过 3 个的时候，不要用级联，直接一主多从就行，简单可靠；从节点超过 3 个且分布在不同机房，或者单次全量同步的数据量特别大（比如几十 GB 以上）时，再考虑级联，把从节点按机房位置挂到对应的转发节点下面。

这里有个细节值得多说一句：级联场景下，如果 B 节点宕机了，C 节点会失去数据源，它不会自动转向 A 节点。它会持续尝试重连 B，直到 B 恢复。所以在设计级联拓扑时，B 节点的稳定性至关重要，最好为 B 也配置一个备用节点。还有，C 节点在复制链路上是 B 的从节点，它对 A 的链路的感知是间接的，排查复制问题时链路层级越多越难定位，日志分析时要逐级检查。

7. 真实排障手记：主从复制延迟、断线重连和数据不一致的定位链路

光会搭还不够，生产环境里主从复制的问题更多体现在排障上。我挑三个高频问题，分别讲述完整的排查链路。

7.1 复制延迟长期偏高

现象：INFO replication里lag字段持续增大，从节点的 offset 和主节点的 offset 差距保持在几千甚至几万以上。

第一步先看网络。主从节点之间的 RTT 如果很高，延迟一定下不来。可以用 ping 测一下两个节点之间的往返延迟，如果在同一机房内网，RTT 应该在 1ms 以内；跨机房的话，10ms~50ms 也算正常，但超过 100ms 就要认真评估了。

第二步看从节点的负载。从节点如果同时在服务大量读请求，CPU 跑到 80% 以上，命令应用速度会明显下降。解决办法要么给从节点扩容，要么调整读写分离策略，把部分读流量切走。

第三步看主节点是否有大量的慢命令。Redis 是单线程模型，主节点如果处理一个KEYS *或者大规模的SINTER操作，会阻塞整个命令循环，所有写命令都排在后面，自然复制延迟也跟着涨。解决方式是排查慢日志：

redis-cli> SLOWLOG GET 10

看到耗时长、类型为大键操作或模糊匹配的命令，就要考虑是否从业务代码里移除，或者改用 SCAN 这类非阻塞命令。

第四步看是否有大 key 在频繁更新。一个大 key 的更新命令需要从主节点完整传播到从节点，序列化和网络传输的成本都特别高。这是 Redis 复制延迟里最常见的隐性杀手。解决方法是拆分大 key，或者至少在业务上缩短大 key 的更新频率。

7.2 从节点反复全量同步

现象：从节点的日志里频繁出现全量同步的标记，主节点的 CPU 周期性飙高。

首选判断依据是 PSYNC 的返回值。在主节点日志里查看是否出现SLAVE sync: Full resync requested，然后在主节点执行INFO sync，观察sync_full和sync_partial_ok两个计数器的增长情况。如果sync_full频繁增长，基本可以断定每次断线重连都走了全量。

进一步定位原因，通常是两个方向：

一是 repl_backlog 太小。断线期间主节点产生的写命令把缓冲区撑爆，从节点的 offset 已经滑出了有效范围，主节点无法做部分重同步。这就回到了前面说的，调大repl-backlog-size。

二是主节点频繁重启导致 replid 变化。每次主节点重启都会生成新的 replid，所有从节点此前持有的 replid 全部失效，必然触发全量同步。如果主节点因为内存碎片、OOM 等原因经常重启，先从根源上解决主节点稳定性问题，再谈复制参数调优。

7.3 主从数据不一致

现象：从节点上查到的数据和主节点不一致，或者业务在读写分离场景下读到了旧数据。

这类问题必须区分两种原因。

一种是同步滞后导致的不一致，属于正常现象。从节点应用写命令需要时间，读写分离架构下读请求刚好落到尚未应用的从节点上，就会读到旧数据。解决思路：对一致性要求高的读请求强制走主节点，或者通过WAIT命令让写操作在多个从节点上确认完成后才返回。WAIT命令的用法如下：

redis-cli> SET key value redis-cli> WAIT 1 1000

WAIT的第一个参数是等待多少个从节点确认，第二个参数是超时毫秒数。如果返回 1，说明至少有一个从节点已经应用了这条命令；返回 0 则说明超时了。这个命令对"写后读一致"的场景很有效，但要注意它只保证命令已经到达从节点的复制流里，不代表从节点一定把命令持久化了。

另一种是人为写入导致的不一致。前面强调过从节点默认只读，但如果有人关闭了replica-read-only或者在从节点上执行了管理命令，就可能在从节点写入与主节点冲突的数据。这种数据在以后的全量同步中会被清掉，但短暂的一致性问题依然存在。排查方式是对比主从节点的 key 值：

# 主节点上获取 key 的 CRC 校验值 redis-cli> DEBUG DIGEST-VALUE keyname # 从节点上执行同样的命令

DEBUG DIGEST-VALUE能对指定 key 做 CRC 校验，如果两边结果不一致，说明数据确实有偏差。还有一种更彻底的对比方案是使用redis-fullcheck这类工具，对主从节点的全量数据做一致性比对。当你怀疑某些 key 不一致时，用单个 key 的校验命令快速验证，比全量比对效率高得多。

8. 主从复制与哨兵、集群的边界：什么该做，什么不该让复制来做

最后想把这些机制串起来讲清楚一个边界问题。很多人对主从复制、哨兵、集群三者的职责划分不够清晰，经常把复制的功能范围理解得过大或过小。

主从复制只负责一件事——把主节点的数据同步到从节点。它不负责故障转移，不负责负载均衡，不负责读写路由。主节点挂了以后，从节点依然只能被动等待，不会自动顶上。自动故障转移是哨兵（Sentinel）的职责。

哨兵系统做的事情是：监测所有 Redis 节点的健康状态，当主节点异常时发起投票，从候选从节点中选出一个提升为新主，然后通知所有客户端更新主节点地址。哨兵自身的失败判定需要多个哨兵节点共同确认，以避免误判。哨兵能自动化地完成主从切换，但切换之后新主节点需要从节点们重新建立复制关系——这是哨兵通过发送REPLICAOF命令来促使节点完成的，本质还是在利用主从复制的基础机制。

Redis Cluster 集群则是更复杂的分布式方案，它解决的问题是数据分片——把 key 按照哈希槽分散到多个主节点上，每个主节点又可以有从节点作为备份。集群模式下，节点间的复制依然是主从复制机制，但多了槽位管理、节点通信、重定向等额外逻辑。

所以一个朴素的心智模型是：主从复制是"数据通道"，哨兵是"故障转移决策器"，Cluster 是"数据分片管理器"。三者配合，才能构建出完整的 Redis 高可用分布式架构。

在实际架构选型时，我见过不少团队在主从复制和哨兵之间纠结。我的观点很明确：如果只是临时要做读扩展，或者给备份系统提供数据源，裸的主从复制就够了，不需要哨兵介入；一旦 Redis 承载的是核心业务数据，任何主节点故障都可能导致服务中断，那就必须上哨兵。服务挂了再人工切换，哪怕只花几分钟，对线上用户来说也是不可接受的。

另外还要提醒一点：主从复制不是无限扩展读性能的手段。从节点越多，主节点分发写命令的网络开销越大，主从之间的数据一致性保障也越复杂。业界比较通用的做法是控制在 2~3 个从节点，需要更多读能力时，靠增加独立的 Redis 副本集群或引入缓存层架构来解决，而不是一味地堆从节点。

我对主从复制最深的体会是：它看起来简单，一条命令就能搭好，但底层涉及 BGSAVE、命令传播、积压缓冲区、复制偏移量这些环环相扣的机制。真正遇到线上问题的时候，如果停留在"重启一下"的层面，永远只能被问题推着走。把这条链路从命令入口到内存数据处理完完整整地在脑子里过一遍，很多故障在还没发生之前就能被配置层面的调整化解掉。