根本原因是复制积压缓冲区（repl-backlog）持续增长：失联从节点未被及时清理时，主节点仍向共享的环形缓冲区追加命令，导致内存只增不减；repl-diskless-sync 仅影响全量同步传输方式，不控制增量缓存，真正关键的是 repl-timeout 与 client-output-buffer-limit slave 协同配置以主动断连并释放内存。
从节点失联后主库内存持续上涨，根本原因是复制积压缓冲区（repl-backlog）撑大
Redis 主从复制中，主节点会维护一个固定大小的环形缓冲区 repl-backlog，用于保存最近写入的命令，供断连的从节点重同步时使用。一旦从节点断开但未被及时清理（比如网络抖动、从节点卡住、或配置了过大的 repl-backlog-size），主节点仍会持续往 backlog 里追加数据——它不知道这个从节点是否还会回来。结果就是内存只增不减，尤其在写入量大的场景下，几天就能吃掉数 GB 内存。
repl-diskless-sync=true 并不能解决失联从节点占内存的问题
这是个常见误解。repl-diskless-sync 控制的是「全量同步阶段」是否绕过 RDB 文件落地，直接通过 socket 把 RDB 流发给从节点。它只影响同步启动那一刻的数据传输方式，跟断连后的增量命令缓存完全无关。即使设成 yes，只要从节点还保留在主节点的 client list 里（状态为 slave 且 flags 含 S），主节点就会继续为它保留 backlog 空间。
-
repl-diskless-sync yes→ 全量同步走网络，省磁盘 IO，但不省内存 -
repl-diskless-sync no→ 全量同步先写 RDB 文件再发，磁盘压力大，同样不省内存 - 真正决定内存占用的是
repl-backlog-size和失联从节点是否被主动剔除
必须配合 repl-timeout + client-output-buffer-limit slave 控制失联节点生命周期
光调 repl-diskless-sync 没用，得让主节点“果断放手”。关键靠两个配置协同生效：
-
repl-timeout 60：主节点 ping 从节点超时时间，超时后主动断开连接（注意：不是立刻删 client，而是标记为待清理） -
client-output-buffer-limit slave 256mb 64mb 60：限制从节点输出缓冲区（含 backlog + 待发指令）最大内存和增长速率；超过硬限（256mb）会立即断连，60 秒内累计超软限（64mb）也会断连
这两个参数要一起调。否则可能出现：从节点已断网，但主节点还在傻等它响应 REPLCONF ACK，缓冲区不断膨胀却得不到清理。
失联从节点没被自动清理？检查 client list 和 replica-announce-ip/port 配置
执行 redis-cli -p 6379 CLIENT LIST，找 flags=S 且 age 很大的从节点。如果它们长期存在，说明上述 timeout 或 buffer limit 没生效，或者从节点配置了错误的 replica-announce-ip，导致主节点无法正确识别其连接状态。更隐蔽的情况是：从节点进程僵死但 TCP 连接未关闭（如被 SIGSTOP），此时主节点仍认为它在线，但实际不再回复 ACK —— 这种情况只能靠 client-output-buffer-limit 的硬限触发强制断连。
复杂点在于：backlog 是全局共享的，所有从节点共用同一块内存；哪怕只有一个顽固失联节点，整个 backlog 就不敢回收。所以排查必须落到具体 client，不能只看内存指标。
