Redis从库内存高于主库的主因是hashtable未同步收缩：主库rehash后缩容，从库因删除依赖主库通知而used下降慢，不满足used/ht_size
从库内存高于主库不是配置错误，而是 Redis 主从复制机制在特定条件下暴露的内存管理差异。最常见、最容易被忽略的根因是 hashtable 未同步收缩 —— 主库 rehash 后缩容了内部哈希表，而从库没跟上。
查 debug htstats 0 看哈希表大小是否失配
主从数据量一致但内存差 2GB？先怀疑哈希表膨胀。Redis 的字典（dict）在 rehash 时会申请两倍空间，等迁移完再释放旧表。主库可能已完成收缩，但从库卡在迁移中间态或根本没触发收缩条件。
-
debug htstats 0在主从节点分别执行（注意：该命令可能阻塞，仅限低峰期临时排查） - 重点比对输出中的
ht_size字段：若从库是主库的 2 倍，基本坐实问题 - 收缩触发条件是
used / ht_size （即负载因子低于 10%），而从库因删除依赖主库通知，used下降慢，导致长期不满足收缩条件 - 别指望手动触发：Redis 没提供强制收缩接口，
CONFIG SET hz调高反而可能加剧主从差异（主库高频回收，从库滞后）
检查主节点 client-output-buffer-limit slave 是否突破
这部分内存不计入 used_memory，但真实占用主库物理内存，且会间接拖垮从库 —— 主库因缓冲区积压卡顿，从库收不到新命令，复制延迟拉大，进一步恶化自身内存状态。
- 在主节点执行
CLIENT LIST，过滤flags=S的连接，看obl（output buffer length）是否 ≥ 67108864（64MB） -
obl持续增长 +age大 +idle小 → 说明从库解析/写入慢（CPU 或磁盘瓶颈） - 调大限制只是延缓断连，不能治本；优先排查从库负载（
INFO cpu、top、磁盘 IO）
确认 repl-backlog-size 是否被误设过大
这个参数本身不增加从库内存，但配置不当会引发恶性循环：主库预分配大缓冲区 → fork 压力大 → RDB 生成慢 → 从库全量同步耗时久 → 加载期间内存峰值飙升 → OOM Killer 杀进程 → 重启后重试 → core 文件堆积。
- 用
CONFIG GET repl-backlog-size查当前值；默认 1MB 完全不够，高写入场景建议按写入速率 × 断连容忍时间 × 1.2计算 - 设成 512MB 甚至 1GB 是危险操作：主库启动就 malloc 这么大一块，加上多个从节点的 output buffer，总开销可能翻倍
-
CONFIG SET生效但不持久，必须同步改redis.conf，否则重启丢失
真正难处理的是哈希表失配这类“静默膨胀”——它不报错、不告警、监控曲线平滑，但内存差值会稳定维持数周甚至更久。你看到的“从库多出 2GB”，大概率就是某次 rehash 后主库缩了、从库卡住了，然后一直没机会再触发下一轮收缩。
