从库used_memory_rss突增远超used_memory，主因是复制缓冲区堆积而非缓存数据增多；需检查slave omem值、主从offset差及client-output-buffer-limit配置，优先优化从库执行速度而非盲目调大缓冲区限。
从库 used_memory_rss 突增远超 used_memory，基本就是复制缓冲区吃掉的内存
这不是从库自己缓存数据多了，而是它作为 Slave，一边接收 Master 发来的命令流，一边在本地执行——但执行速度跟不上接收速度时，未消费完的命令会堆积在从库的 client output buffer 里，这部分内存会计入 used_memory_rss，却不反映在 used_memory 中。典型现象是：mem_fragmentation_ratio 正常（比如 1.2），但 used_memory_rss 比 used_memory 高出几百 MB 甚至 GB。
验证方式很简单：
-
redis-cli info memory | grep -E "used_memory|used_memory_rss"—— 若差值 >300MB 且稳定不降，大概率是复制积压 -
redis-cli client list | grep "slave" | awk '{print $NF}' | sort -nr | head -1—— 查看最大omem值，超过 256MB 就危险 -
redis-cli info replication | grep -E "slave_repl_offset|master_repl_offset"—— 若差值持续扩大，说明从库消费滞后
CONFIG SET client-output-buffer-limit slave 不是万能解，调太大反而掩盖问题
临时调大限制（比如设为 "1024mb 512mb 60"）能防止断连，但治标不治本。真正的问题在于：从库 CPU/IO 跟不上 Master 的写入节奏，缓冲区只是“症状”，不是“病因”。盲目设成 "2048mb 1024mb 300" 可能导致从库 RSS 内存爆到 8GB+，触发系统 OOM Killer 杀进程。
更稳妥的做法是分层控制：
- 先用
CLIENT KILL TYPE slave主动断开明显滞后的从节点，避免拖累整体同步链路 - 对保留的从库，设合理硬限：
CONFIG SET client-output-buffer-limit slave "512mb 256mb 60"（软限 512MB、硬限 256MB、60 秒内超限即断） - 同时关掉该从库的 AOF：
CONFIG SET appendonly no，减少本地写盘阻塞，提升命令执行吞吐
长期稳定必须让从库“跟得上”，而不是让 Master “憋得住”
主库写入压力大时，光靠调大 repl-backlog-size 或启用 repl-diskless-sync 不足以解决从库内存溢出——因为 backlog 只影响增量同步起点，diskless sync 只优化全量传输阶段，都不解决从库执行慢这个核心瓶颈。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
根治要从三方面入手：
- 升级从库硬件：重点加 CPU 核数（Redis 单线程，主频和核心数直接影响命令执行速度），其次才是内存
- 拆分 bigkey：用
redis-cli --bigkeys找出 >1MB 的hash/zset，按 field 或 score 范围拆成多个小 key，避免单次命令阻塞过久 - 业务层限流：在写入侧加令牌桶（如 Guava RateLimiter），把突发写压摊平到 2–3 秒窗口，给从库留出消费余量
别忽略 Sentinel 对从库 OOM 的误判连锁反应
当从库因内存溢出进入只读或响应迟钝时，Sentinel 会持续发 INFO 探测失败，可能误判为主节点故障并触发无谓切换。尤其要注意：down-after-milliseconds 默认 30000ms（30秒），而从库卡顿可能刚好卡在 25–29 秒之间——既没彻底挂，又反复超时。
这时需同步检查：
- Sentinel 自身内存是否充足：
redis-cli -p 26379 info memory | grep used_memory - 主库是否因
maxmemory-policy noeviction开始报(error) OOM command not allowed...，导致 Sentinel 心跳命令失败 - 从库的
min-slaves-to-write和min-slaves-max-lag是否设得太激进，进一步加剧写入拒绝
真正棘手的从来不是配置数字调多大，而是从库执行命令的速度边界在哪——它取决于你的数据结构、key 大小、网络延迟和 Redis 版本的命令解析效率，这些没法靠一条 CONFIG 命令绕过去。
