主从全量同步时主库内存暴涨甚至OOM，根本原因是client-output-buffer-limit slave配置不合理；该配置控制从库连接输出缓冲区上限，若硬限过低或软限窗口不足，会导致从库接收慢时缓冲区积压、断连重试、循环雪崩，而repl-backlog-size对此无影响。
主从全量同步时，主库内存可能瞬间暴涨甚至 OOM 崩溃，根本原因不是数据量大，而是 client-output-buffer-limit slave 配置不合理 —— 默认值（256mb 64mb 60）在高吞吐场景下极易触发断连+重试循环，形成雪崩。
为什么全量同步会压爆主库内存
全量同步期间，主库需将整个 RDB 文件通过网络发给从库。这个过程不是流式分块发送，而是先在主库的输出缓冲区里攒够一个完整 RDB 的内容（尤其当 RDB 达几百 MB 时），再批量推送。如果从库接收慢（比如网络带宽低、磁盘 IO 差、或刚启动还在加载 RDB），主库的输出缓冲区就会持续堆积，直到触发 client-output-buffer-limit 的硬限制而断连。断连后从库立即重试，又触发新一轮全量同步 —— 内存反复冲高，最终耗尽。
- 典型现象：
CLIENT LIST中看到大量flags=S（slave）连接的omem值飙升到几百 MB，且oll（output list length）不为 0 - 关键指标不是 RDB 大小本身，而是主库能否在
soft seconds内把缓冲区清空；否则软限制也会触发断连 - 注意：
repl-backlog-size只影响增量复制，对全量同步无作用
如何设置 client-output-buffer-limit slave 才安全
不能只看 RDB 最大体积，得结合从库实际接收能力（带宽、IO）、RDB 生成耗时、以及主库剩余内存余量来设。硬限制必须大于单次全量同步可能产生的最大缓冲区占用，软限制则要留出足够“喘息时间”。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 硬限制（
hardlimit）建议设为 RDB 预估最大体积的 1.5～2 倍，但绝不能超过主库maxmemory的 30%（避免挤占正常请求内存） - 软限制（
softlimit）建议设为硬限制的 50%～70%，soft seconds设为 120～300 秒（给慢速从库足够缓冲窗口） - 示例配置（适用于 RDB ≤ 800MB 场景）：
client-output-buffer-limit slave 1200mb 800mb 240 - 切勿设为
0或极大值（如0 0 0），这等于关闭保护，一旦从库卡住，主库内存会直冲上限崩溃
配置生效前必须确认的三件事
改完配置不等于万事大吉，Redis 不会自动清理已有连接的缓冲区状态，旧从库仍按老规则运行。
- 执行
CONFIG REWRITE持久化配置，避免重启丢失 - 用
CONFIG GET client-output-buffer-limit确认新值已加载 - 对已存在的从库连接，必须手动执行
CLIENT KILL TYPE slave强制重连，让新缓冲区策略生效；否则它们继续用旧限制跑
比调参更关键的预防动作
缓冲区调大只是兜底，真正减少全量同步发生频率，才能根治问题。
- 确保所有从库使用相同
runid和连续offset，避免因网络抖动误判为首次同步 —— 检查INFO replication中的master_repl_offset和从库上报 offset 是否接近 - 增大
repl-backlog-size（例如调至128mb），扩大增量复制窗口，降低断连后降级为全量的概率 - 监控
sync_full和sync_partial_ok计数器变化，发现全量同步频次异常升高时，优先排查网络或从库负载，而非只调缓冲区
缓冲区不是越大越好，它本质是主库给从库的“信用额度”。额度设太高，主库可能被拖垮；设太低，从库反复断连重试。真正的平衡点，藏在你的 RDB 体积、网络带宽、和从库处理延迟的交叉线上 —— 这些数字，必须实测，不能拍脑袋。
