主从同步不计入maxmemory但消耗RSS内存，因replication buffer独立分配且used_memory不统计它，当omem飙升导致used_memory_rss超物理内存时触发OOM；可通过client list查omem、info memory比对rss与used_memory确认。
主从同步本身不直接触发内存溢出，但会显著放大 maxmemory 配置不当带来的风险——尤其当从节点输出缓冲区（client_longest_output_list、omem）持续堆积时，这部分内存不计入 used_memory，却真实消耗 RSS，极易突破物理内存上限。
为什么主从同步会让 maxmemory 失效
Redis 的 maxmemory 仅限制键值数据 + 内部结构的内存（即 used_memory），但主从同步产生的输出缓冲区（replication buffer）是独立分配的：
- 主节点为每个从节点维护一个输出队列，写命令在发送前先存入该缓冲区
- 缓冲区大小取决于从节点消费速度：网络延迟高、从节点卡顿、全量同步未完成时，
omem可能飙升到 GB 级 -
INFO memory中的used_memory完全不体现这部分，used_memory_rss才包含它 - 一旦
used_memory_rss超过物理内存，系统 OOM Killer 就可能杀掉redis-server
怎么确认是主从同步导致的内存压力
执行以下命令交叉验证：
-
redis-cli info clients | grep -E "(connected_clients|client_longest_output_list|blocked_clients)"—— 若client_longest_output_list> 100MB 或多个从节点持续 > 50MB，高度可疑 -
redis-cli client list | grep -v "omem=0" | awk '{print $NF}' | sort -nr | head -5—— 查看 top 5omem值，单位字节；超过 500MB 就需干预 -
redis-cli info memory | grep -E "(used_memory_rss|used_memory|mem_fragmentation_ratio)"—— 若used_memory_rss比used_memory高出 2 倍以上，且mem_fragmentation_ratioomem 占大头
maxmemory 应该设多少才安全（主从场景）
不能只看键值数据量，必须为三类开销留余量：
- COW 开销：RDB/AOF 重写时 fork 子进程，瞬时内存可能翻倍 → 建议预留 30%~40%
-
主从同步缓冲区：按最差情况预估，例如单从节点
omem峰值曾达 800MB，则至少预留 1GB - 系统与 Redis 自身开销：线程栈、连接缓冲、临时对象等，保守起见再加 0.5~1GB
公式： maxmemory ≤ 总内存 × 0.6 − max(历史最高 omem) − 1GB。例如 32GB 机器，若 omem 峰值为 900MB，则 maxmemory 不应超过 19.2GB − 0.9GB − 1GB = 17.3GB。
临时缓解与长期规避
紧急时可快速释放输出缓冲区：
- 对慢从节点执行
CLIENT KILL TYPE slave强制断连重试（慎用，会触发全量同步） - 调大
repl-backlog-size（如设为 1024mb）减少全量同步频次 - 禁用
repl-diskless-sync yes改用 diskless 同步可降低主节点磁盘 I/O 压力，但会增加内存拷贝开销 - 长期方案：拆分大实例为多个小实例，避免单主承载过多从节点；或改用 Redis Cluster 分摊同步压力
真正容易被忽略的是：omem 不受 maxmemory 约束，也不会触发淘汰策略——它涨到多高，就吃掉多少物理内存，直到系统崩溃。
