从节点内存异常偏高，首要排查主节点 client-output-buffer-limit 是否被突破，检查 CLIENT LIST 中 slave 连接的 obl 值是否超 64MB 或持续增长；其次确认 repl-backlog-size 是否过大或误用；再查从节点自身是否存在大 key、MONITOR 或客户端缓冲积压；最后验证复制状态是否假同步。
从节点内存比主节点高，先看 client-output-buffer-limit 是否被突破
从节点内存异常偏高，最常见原因是主节点对它的输出缓冲区（output buffer）持续堆积，而未被及时消费。主节点会为每个从节点单独维护一个 output buffer，一旦从节点处理慢、网络卡顿或 CPU 饱和，缓冲区就会不断膨胀——这部分内存不计入 used_memory 的常规统计，但真实占主节点内存。
检查方法：在主节点执行 CLIENT LIST，过滤出 flags 含 S（slave）的连接，重点关注 obl（output buffer length）字段：
-
obl > 67108864（64MB）：已触发client-output-buffer-limit slave硬限制，主节点可能已断连或即将断连 -
obl持续增长且age很大、idle却很小：说明从节点接收快但解析/写入慢，可能是 CPU 或磁盘 IO 瓶颈 -
qbuf > 1048576（1MB）且长期不降：输入缓冲区也积压，说明从节点网络收包后没及时读取，进一步佐证处理能力不足
确认 repl-backlog-size 是否过大且被误用
主节点的 repl-backlog-size 是全局共享的环形缓冲区，**它本身不直接导致从节点内存变大**，但配置不当会间接引发问题：比如设得过大（如 512MB），主节点启动时预分配整块内存，加上多个从节点各自独立的 output buffer，总内存压力陡增；更关键的是，若从节点因网络抖动反复断连重连，又始终无法完成增量同步，就会陷入“断连→重试 PSYNC→失败→全量同步→RDB 生成→子进程内存飙升→主节点卡顿→从节点更慢”的恶性循环。
查当前值：CONFIG GET repl-backlog-size；看是否启用：INFO replication | grep repl_backlog_active（为 0 表示未激活，可能是从未连过从节点或配置未生效）。
- 默认 1MB 完全不够用，高写入场景建议至少
67108864（64MB） - 不能无脑调大到 GB 级：需按公式估算——
repl-backlog-size ≥ 写入速率(B/s) × 最大预期断连时间(s) × 1.2 -
CONFIG SET repl-backlog-size生效但不持久，记得同步改redis.conf
检查从节点自身是否存在大 key 或客户端缓冲积压
别只盯着主节点，从节点内存高也可能源于自身问题：比如它上面挂了大量慢客户端（尤其是 MONITOR）、或缓存了超大 key（如百万级 LIST）、或开启了 AOF 且重写期间缓冲区堆积。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
排查步骤：
- 在从节点上跑
redis-cli --bigkeys，重点看memory usage <key>返回值 - 执行
CLIENT LIST | grep -v "omem=0"，找omem（output memory）异常高的普通客户端（非 S 标志） - 查
INFO clients中client_longest_output_list和client_biggest_input_buf，数值过大说明某客户端输出/输入缓冲失控 - 确认
MONITOR是否在运行：该命令会让 Redis 把所有命令实时推给客户端，极易撑爆输出缓冲
主从内存差异大时，优先排除复制状态假同步
有时 INFO replication 显示 master_link_status:up，但从节点实际已停止消费，只是 TCP 连接还挂着——表现为 slave_repl_offset 长期不增长，而 master_repl_offset 正常推进，差值越拉越大。此时从节点内存可能因本地堆积旧数据（比如未及时落盘的 RDB 加载中间态）或后台任务（如 AOF rewrite）而虚高。
验证方式：
- 对比主从节点的
INFO stats中instantaneous_ops_per_second：从节点应接近 0 - 查从节点日志是否有
MATER REPLICA sync: receiving streamed RDB（全量同步中）或SYNC with master complete（已完成） - 用
redis-cli -p <port> CLIENT KILL TYPE normal临时杀掉所有普通客户端，观察内存是否回落——若回落明显，说明是客户端缓冲而非复制逻辑问题
真正难搞的是那种“连接活着、offset 动得慢、缓冲区悄悄涨、监控看不出明显异常”的情况，这时候得盯紧 CLIENT LIST 的实时输出和 slowlog，而不是只看 INFO memory。
