应调大repl-backlog-size至峰值写入速率×断连容忍时间×1.5，并执行slaveof no one再slaveof重建连接，同时检查从库cpu/io瓶颈。
repl-backlog-size太小导致从库频繁全量同步怎么办
直接后果是：从节点重连时收到 Partial resynchronization not possible (no cached master)，接着触发 BGSAVE，CPU和磁盘瞬间拉满，主库响应延迟飙升。
这不是网络抖动本身的问题，而是积压缓冲区撑不住峰值写入量。默认 1mb 的 repl-backlog-size 在真实业务中基本等于没设。
- 用
redis-cli info replication查看repl_backlog_histlen（当前已用字节数），如果长期接近或等于repl_backlog_size，说明缓冲区一直在打满边缘 - 按公式算安全值：
repl-backlog-size ≥ 峰值写入速率(B/s) × 最大断连时间(s) × 1.5。例如监控到instantaneous_ops_per_second峰值 12000，平均命令大小 300 字节，历史最长断连 85 秒 → 至少需要12000 × 300 × 1.5 × 85 ≈ 459MB，建议设为512mb（即536870912） -
CONFIG SET repl-backlog-size 536870912生效后，必须让从节点断开重连（SLAVEOF NO ONE再SLAVEOF），否则旧连接仍用老缓冲区
从库 used_memory_rss 突增几百 MB 是复制缓冲区吃掉的内存
现象是：used_memory_rss 比 used_memory 高出 500MB+，但 mem_fragmentation_ratio 正常（比如 1.1~1.3），INFO memory 里没看到大 key 占用。
本质是：从库接收命令快、执行慢，未消费的命令堆积在 client output buffer 中，这部分内存计入 used_memory_rss，但不计入 used_memory。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 查最大从库缓冲区占用：
redis-cli client list | grep "slave" | awk '{print $NF}' | sort -nr | head -1，输出类似omem=328765432，超过256mb就危险 - 查主从 offset 差：
redis-cli info replication | grep -E "slave_repl_offset|master_repl_offset"，若差值持续扩大，说明从库执行滞后 - 临时缓解可调
client-output-buffer-limit slave，但硬限别超512mb；更关键的是关掉该从库的 AOF：CONFIG SET appendonly no，减少本地写盘阻塞
盲目调大 client-output-buffer-limit 反而引发 OOM
有人把 client-output-buffer-limit slave "2048mb 1024mb 300" 当成万能解，结果从库 used_memory_rss 冲到 8GB+，被系统 OOM Killer 杀掉进程。
缓冲区限制只是“断连开关”，不是“执行加速器”。调大只是延缓断连，掩盖了从库 CPU 或磁盘 IO 跟不上的真实瓶颈。
- 优先
CLIENT KILL TYPE slave主动干掉明显滞后的从节点，避免拖垮整个复制链路 - 保留的从库，设合理硬限：
CONFIG SET client-output-buffer-limit slave "512mb 256mb 60"（软限 512MB、硬限 256MB、60 秒内超限即断） - 检查从库是否跑在高负载机器上：
top看%wa（IO wait）是否持续 >30%，iostat -x 1看%util是否长期 100%
为什么改了配置却没效果？复制连接没重建
CONFIG SET 修改 repl-backlog-size 或 client-output-buffer-limit 后，已建立的主从连接不会自动切换到新配置。旧连接继续用旧缓冲区，repl_backlog_histlen 不变，omem 该涨还涨。
必须让从库主动重建复制连接，才能加载新参数。
- 在从库执行：
SLAVEOF NO ONE→SLAVEOF <master_ip><master_port></master_port></master_ip> - 观察
INFO replication中master_link_status:up和slave_repl_offset是否开始追平 - 确认
repl_backlog_active变为1，且repl_backlog_histlen能随写入增长（说明新缓冲区已启用）
