Redis 6.0主从复制中出现数据延迟该如何优化？

能，但只对小包高频写入场景有效；默认 yes 启用 Nagle 算法导致最多 200ms 延迟，设为 no 可立即发送小包降低延迟，但需同步检查 repl-backlog-size、client-output-buffer-limit 和从节点性能瓶颈。

repl-disable-tcp-nodelay 设为 no 能否立即降低延迟？

能，但只对小包高频写入场景有效。默认 repl-disable-tcp-nodelay 是 yes，即启用 Nagle 算法 —— 主节点会攒够 40ms 或凑够 TCP MSS 才发包。在每秒几百次 SET 的业务里，这直接导致从节点看到的命令“一卡一卡”，延迟跳到 100–200ms 级别。

实操建议：

1. 先确认当前值：CONFIG GET repl-disable-tcp-nodelay，返回 ["repl-disable-tcp-nodelay","yes"] 就该改
2. 临时生效：CONFIG SET repl-disable-tcp-nodelay no
3. 持久化：在 redis.conf 中写入 repl-disable-tcp-nodelay no，再执行 CONFIG REWRITE 验证是否已写入
4. 注意：该参数只影响主→从复制流，不影响客户端连接或 AOF 重写

为什么改了 repl-disable-tcp-nodelay 还有延迟？检查 repl-backlog-size 是否溢出

禁用 Nagle 后，小包发得勤了，但如果主节点写入突增、从节点同步慢（比如磁盘 IO 差、网络抖动），而 repl-backlog-size 太小，就会触发全量同步（SYNC），日志里出现 Master does not have enough backlog，延迟瞬间飙升到秒级甚至分钟级。

判断与调优方法：

1. 查当前大小：CONFIG GET repl-backlog-size，默认仅 1048576（1MB），对中高流量实例远远不够
2. 估算公式：所需大小 = 平均每秒写入字节数 × 最大容忍断连时间（秒） × 安全系数（1.5–2）。例如每秒写 5MB、要扛住 30 秒断连，至少设为 5 * 1024 * 1024 * 30 * 1.5 ≈ 230MB
3. 动态调整：CONFIG SET repl-backlog-size 240000000，注意新大小在下次创建 backlog 时（如从节点重连）才生效
4. 监控关键指标：redis-cli info replication | grep -E "(repl_backlog_active|repl_backlog_histlen|repl_backlog_size)"，三者应基本匹配，repl_backlog_histlen 接近 repl_backlog_size 说明快满了

client-output-buffer-limit slave 配置不合理会导致什么？

这个参数控制从节点接收缓冲区上限，不是复制缓冲区（repl-backlog-size），而是主节点为每个从节点单独维护的输出缓冲。一旦从节点消费太慢，缓冲区超限，主节点会强制断开该从节点连接 —— 表现为反复重连、延迟归零又暴涨、INFO 中 slave_repl_offset 频繁重置。

常见错误配置是沿用默认值 slave 256mb 64mb 60，在高吞吐场景下极易触发断连。

实操建议：

1. 查看当前设置：CONFIG GET client-output-buffer-limit
2. 合理值参考：slave 4gb 2gb 60（软限制 4GB、硬限制 2GB、超时 60 秒）
3. 设置命令：CONFIG SET client-output-buffer-limit "slave 4gb 2gb 60"
4. 注意：该值需结合从节点实际同步能力设定，不能盲目堆大；同时要确保主节点内存充足，否则 OOM

从节点性能瓶颈容易被忽略的三个点

很多团队只盯着主节点调参，却没意识到从节点才是最终瓶颈。尤其 Redis 6.0 引入多线程 I/O 后，从节点仍为单线程执行命令，CPU 和磁盘 IO 成为隐形卡点。

排查方向：

1. redis-cli info stats | grep -E "(rejected_connections|expired_keys|evicted_keys)"：大量 evicted_keys 说明内存不足，触发 LRU 清理，拖慢命令执行
2. iostat -x 1 查看从节点磁盘 util% 和 await：若持续 >90% 或 await >20ms，说明磁盘写入跟不上，可能是 AOF 开启且 fsync 策略太激进（如 always）
3. 对比主从 redis-cli info cpu | grep used_cpu_sys：从节点 used_cpu_sys 显著高于主节点，大概率是内核协议栈处理小包压力过大（尤其禁用 Nagle 后），此时需配合系统级 TCP 调优（如 net.ipv4.tcp_slow_start_after_idle=0）