为什么Redis 6.0主从复制会出现内存突增现象-Redis-PHP中文网

主节点输出缓冲区堆积是内存突增的首要原因：90%以上场景非key增多所致，而是从节点或monitor连接的omem失控增长，导致used_memory_rss远超used_memory，典型表现为client_longest_output_list异常高、client list中出现omem超2gb且flags含s或o。

为什么redis 6.0主从复制会出现内存突增现象

主节点输出缓冲区堆积是内存突增的首要原因

Redis 6.0 主节点内存陡增，90%以上场景不是因为 key 数据变多，而是某个或多个从节点的 omem（output memory）持续增长，导致主节点为该连接单独分配的输出缓冲区内存失控。这个缓冲区不计入 used_memory，但真实占用 RSS 内存，used_memory_rss 会远高于 used_memory。

典型表现：client_longest_output_list 值异常高（比如 >200000），CLIENT LIST 中出现 omem=2129300608 这类超 2GB 的记录，且 flags 含 S（slave）或 O（monitor）。

执行 redis-cli info clients | grep -E "client_longest_output_list|connected_clients" 快速初筛
用 redis-cli client list | awk '$NF ~ /omem=[1-9][0-9]+/ {print}' 精准抓出非零 omem 连接
重点看 addr、cmd、oll（output list length）字段——oll > 65536 就已属危险值

MONITOR 命令在从节点上运行会直接拖垮主节点

MONITOR 不是复制协议的一部分，但它会劫持主节点所有命令的输出流。一旦有从节点（尤其是通过 redis-cli -h slave_ip monitor 临时调试时）执行了它，主节点就会把每一条写命令都塞进该连接的输出缓冲区。QPS 越高，omem 增长越快，且完全不触发淘汰机制。

Redis 8.2.3

Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。

下载

MONITOR 连接的 omem 几乎从不归零，idle 通常为 0，age 持续增加
它和普通从节点一样占用 client-output-buffer-limit slave 配额，但行为完全不同：不是“慢消费”，而是“全量截留”
即使只开一个 MONITOR，在 5k+ QPS 场景下，1 分钟内就可能吃掉 1.5GB 主节点内存

从节点执行速度跟不上导致复制缓冲区持续积压

当从节点 CPU 或磁盘 IO 成瓶颈（比如开启 AOF 且正在重写、或处理大 key）、或网络延迟抖动时，它接收命令快、执行慢，主节点的复制缓冲区（repl-backlog-buffer）本身不会暴涨，但每个 slave 连接的 obl（output buffer length）会不断堆积——这部分内存由主节点承担，且不被 maxmemory 管控。

检查主节点是否触发硬限：redis-cli config get client-output-buffer-limit 中 slave 行第三项（秒数）若被突破，主节点会主动断连，但断连前缓冲区已膨胀
对比 master_repl_offset 和 slave_repl_offset 差值：持续扩大 + omem 上涨 = 从节点执行滞后
临时缓解可用 CONFIG SET client-output-buffer-limit slave "512mb 256mb 60"，但必须同步关 AOF（CONFIG SET appendonly no）并排查从节点负载

repl-backlog-size 配置过大反而加剧内存压力

repl-backlog-size 是主节点全局环形缓冲区，它本身不直接导致从节点内存高，但在高写入+频繁断连场景下，过大的配置会放大问题：主节点启动即预分配整块内存（如设为 2gb，实际 RSS 多占 2GB），且从节点重连后若无法快速追上，会反复尝试部分同步失败，最终触发全量复制——bgsave fork 子进程又进一步挤占内存。