从节点slave_repl_offset滞后主节点时读请求会卡在同步队列里：因复制缓冲区积压、aof落盘拖慢、全量同步风暴及流量未剔除高lag节点，导致响应延迟激增或拒绝服务。
从节点 slave_repl_offset 滞后主节点时，读请求会卡在同步队列里
Redis 从节点不是“被动接收+立即执行”，而是把主节点发来的命令先写入本地复制缓冲区（repl-backlog），再逐条解析、执行。当 slave_repl_offset 明显落后于 master_repl_offset（比如差值 > 10MB），说明从节点正被积压命令“堵住”。此时如果业务发起读请求，它不会直接返回旧数据，而是可能触发以下连锁反应：
- 从节点仍在忙于执行 backlog 中的 SET/HSET 等写命令，CPU 占用飙升，响应
GET的延迟从 0.2ms 拉长到 5–20ms - 若开启
replica-serve-stale-data no，从节点会直接拒绝读请求，返回READONLY You can't write against a read only replica.（注意：这是错误提示，但实际是因同步阻塞导致的只读拒绝） - 客户端重试逻辑若未设超时或退避，可能堆积大量等待连接，耗尽连接池
网络抖动期间，从节点反复断连重连会清空本地缓冲区
当主从间出现短暂丢包或延迟突增（如跨机房链路抖动），从节点会触发 repl-timeout 超时，默认 60 秒。一旦超时，从节点主动断开连接，并在重连后判断是否能做部分同步（PSYNC）——这取决于 repl-backlog-size 是否够大、repl_backlog_histlen 是否仍覆盖断连时段。
- 若积压缓冲区已滚动覆盖（
repl_backlog_histlen == repl-backlog-size），从节点只能发起全量同步（FULLRESYNC），触发 bgsave + RDB 传输，期间无法提供任何读服务 - 全量同步期间，从节点内存占用陡增（RDB 解析阶段）、磁盘 IO 暴涨（若未启用
repl-diskless-sync yes），进一步拖慢自身响应能力 - 多个从节点同时进入全量同步，主节点 CPU 和带宽会被打满，加剧其他从节点同步延迟，形成雪崩
从节点开启 appendonly yes 且 appendfsync always 时，写命令执行变慢三倍以上
很多团队为“保险起见”在从节点也开启 AOF 持久化，但没意识到这对同步性能是硬伤。从节点每收到一条主节点发来的命令，不仅要执行，还要落盘——而 appendfsync always 是每次写都 fsync()，在普通 SATA 盘上单次耗时约 1–3ms，远高于内存操作的微秒级。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 主节点每秒写入 5000 条命令 → 从节点需执行 5000 次
fsync→ 实际吞吐可能跌到 300–500 QPS - 此时
slave_repl_offset增速远低于master_repl_offset，滞后持续扩大，监控中lag字段会稳定在 10s+ 甚至更高 - 更隐蔽的问题是：AOF rewrite 过程中，从节点会 fork 子进程，造成内存翻倍和短时卡顿，进一步恶化 lag
业务层未感知从节点滞后，仍持续向高 lag 从节点转发读流量
常见反模式是客户端或代理（如 Twemproxy、Codis）只做简单轮询或哈希路由，完全不检查从节点健康状态。只要 TCP 连接通，就认为“可用”，结果大量读请求落到 lag = 15s 的从节点上。
- 真实业务中，一个订单创建后立刻查订单详情，若路由到 lag=12s 的从节点，用户看到的就是“刚下单却查不到”
- 监控上表现为：该从节点
instantaneous_ops_per_sec极低，但connected_clients高、rejected_connections上升，说明连接堆积 - 正确做法是定期调用
INFO replication，计算master_repl_offset - slave_repl_offset，超过阈值（如 5MB 或 2s）则临时摘除该节点流量
真正卡住读性能的，往往不是“数据旧”，而是“从节点忙着追数据，根本没空理你”。别只盯着一致性，先确保从节点有余力响应请求。
