能，但只对小包高频写入场景有效；默认 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 级别。
实操建议：
- 先确认当前值：
CONFIG GET repl-disable-tcp-nodelay，返回["repl-disable-tcp-nodelay","yes"]就该改 - 临时生效：
CONFIG SET repl-disable-tcp-nodelay no - 持久化：在
redis.conf中写入repl-disable-tcp-nodelay no，再执行CONFIG REWRITE验证是否已写入 - 注意：该参数只影响主→从复制流，不影响客户端连接或 AOF 重写
为什么改了 repl-disable-tcp-nodelay 还有延迟？检查 repl-backlog-size 是否溢出
禁用 Nagle 后，小包发得勤了，但如果主节点写入突增、从节点同步慢（比如磁盘 IO 差、网络抖动），而 repl-backlog-size 太小，就会触发全量同步（SYNC），日志里出现 Master does not have enough backlog，延迟瞬间飙升到秒级甚至分钟级。
判断与调优方法：
- 查当前大小：
CONFIG GET repl-backlog-size，默认仅1048576（1MB），对中高流量实例远远不够 - 估算公式：所需大小 = 平均每秒写入字节数 × 最大容忍断连时间（秒） × 安全系数（1.5–2）。例如每秒写 5MB、要扛住 30 秒断连，至少设为
5 * 1024 * 1024 * 30 * 1.5 ≈ 230MB - 动态调整：
CONFIG SET repl-backlog-size 240000000，注意新大小在下次创建 backlog 时（如从节点重连）才生效 - 监控关键指标：
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 频繁重置。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
常见错误配置是沿用默认值 slave 256mb 64mb 60，在高吞吐场景下极易触发断连。
实操建议：
- 查看当前设置：
CONFIG GET client-output-buffer-limit - 合理值参考：
slave 4gb 2gb 60（软限制 4GB、硬限制 2GB、超时 60 秒） - 设置命令：
CONFIG SET client-output-buffer-limit "slave 4gb 2gb 60" - 注意：该值需结合从节点实际同步能力设定，不能盲目堆大；同时要确保主节点内存充足，否则 OOM
从节点性能瓶颈容易被忽略的三个点
很多团队只盯着主节点调参，却没意识到从节点才是最终瓶颈。尤其 Redis 6.0 引入多线程 I/O 后，从节点仍为单线程执行命令，CPU 和磁盘 IO 成为隐形卡点。
排查方向：
-
redis-cli info stats | grep -E "(rejected_connections|expired_keys|evicted_keys)"：大量evicted_keys说明内存不足，触发 LRU 清理，拖慢命令执行 -
iostat -x 1查看从节点磁盘 util% 和 await：若持续 >90% 或 await >20ms，说明磁盘写入跟不上，可能是 AOF 开启且 fsync 策略太激进（如always） - 对比主从
redis-cli info cpu | grep used_cpu_sys：从节点used_cpu_sys显著高于主节点，大概率是内核协议栈处理小包压力过大（尤其禁用 Nagle 后），此时需配合系统级 TCP 调优（如net.ipv4.tcp_slow_start_after_idle=0）
