链式复制需在中间从节点执行replicaof命令并配置replica-announce-ip/port、replica-serve-stale-data yes，否则会导致拓扑识别失败、复制中断或故障扩散；每增加一级延迟上升8–15ms，且宕机时引发多节点同时全量同步。

如何用 REPLICAOF 命令让从节点再挂从节点

链式复制不是靠主节点配置，而是让「已经连上主库的从节点」再执行一次 REPLICAOF，把自己变成中间层主节点。比如已有 master:6379 → replica1:6380，现在要加 replica2:6381 指向 replica1，就在 replica2 上执行：

127.0.0.1:6381> REPLICAOF 127.0.0.1 6380

注意：Redis 5.0+ 必须用 REPLICAOF（旧版用 SLAVEOF），命令是运行时生效，无需重启。执行后立刻触发同步，INFO replication 中 role 变为 slave，master_host 显示的是 replica1 的地址。

中间层节点必须显式配置 replica-announce-ip 和 replica-announce-port

如果不配，上层主节点（比如最初的 6379）在 INFO replication 里看到的中间层节点地址可能是 127.0.0.1 或内网不可达地址，导致拓扑识别失败、复制中断甚至选主混乱。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 在 replica1 的 redis.conf 中加两行：
• replica-announce-ip 10.0.1.22（填它对外可被 replica2 访问的真实 IP）
• replica-announce-port 6380（填它监听的端口，非默认 6379 时必须显式写）
• 改完 reload 配置或重启，再检查 INFO replication 的 slaveX 字段是否显示正确地址

中间层节点要允许提供读服务，否则孙节点连上来也拿不到数据

默认情况下，从节点只读（replica-read-only yes），但这不影响它作为主节点转发命令——真正卡住的是 replica-serve-stale-data。如果这个值是 no，中间层节点一旦与上游断开，就会拒绝所有客户端请求（包括孙节点的复制请求）。

• 必须设为 replica-serve-stale-data yes（旧版叫 slave-serve-stale-data）
• 该配置允许中间层节点在网络抖动、短暂失联时继续响应复制请求和客户端读请求
• 不改这个，replica2 会反复报 MASTERDOWN Link with MASTER is down 并重试全量同步

链式结构下最容易被忽略的延迟和故障扩散风险

每加一级，复制延迟就多一层网络 RTT + 命令解析开销。实测两层级联（master → replica1 → replica2）比直连多出 8–15ms 端到端延迟；三级后可能超 30ms。更危险的是故障传播：

• 如果 replica1 宕机，所有连它的孙节点会同时断开，并几乎在同一秒发起对原始 master 的全量同步请求
• 这会导致主节点瞬间 fork 多个子进程生成 RDB，CPU 和内存直接拉满
• 中间层节点务必禁用 swap、限制 maxmemory、部署在独立高可用宿主机上
• 跨机房级联（如北京 → 上海 → 深圳）基本不可控，一次丢包就可能引发整条链重同步

链式复制不是配置完就一劳永逸的事——它把主节点的资源压力，悄悄转移成了链路稳定性与中间层运维深度的问题。你得盯着每一层的 master_link_status、lag、repl_backlog_active，而不是只看最终孙节点能不能读到数据。