repl-disable-tcp-nodelay 是 tcp 层级发送策略开关，设为 yes 时启用 nagle 算法，导致主从间真实、可观测的 20–50ms 传输延迟；设为 no 则禁用该算法，降低延迟但增加带宽消耗。
repl-disable-tcp-nodelay 不是“伪异步”，而是 TCP 层级的发送策略开关；它导致的延迟是真实、可观测、可复现的网络行为，不是 Redis 协议层的异步伪装。
为什么说“伪异步同步”这个说法容易误导
Redis 主从复制本身是同步协议（PSYNC/SYNC 命令触发，主节点阻塞等待 RDB 传输完成才进入增量阶段），但 repl-disable-tcp-nodelay 控制的是底层 TCP 数据包是否立即发出。很多人看到“主节点写完就返回客户端，但从节点几毫秒后才收到”，误以为 Redis 在“假装同步”，其实只是 Linux 内核把小包攒着发了——这不是 Redis 的逻辑异步，是 TCP 的传输延迟。
关键点：
- Redis 复制命令（如
SET）在主节点执行完、写入 AOF/RDB 后，确实会立即推送到 socket 缓冲区 - 但若
repl-disable-tcp-nodelay为yes，内核不立刻发包，而是等 40ms 或凑够 MSS 大小 - 从节点
read()调用永远收不到“未发出”的数据，所以延迟是真实的端到端传输延迟，不是协议层缓冲
如何快速确认是不是 repl-disable-tcp-nodelay 导致的延迟
直接查当前配置和延迟特征比抓包更高效：
X-Node企业快速建站1.0.6.0801
下载
特色介绍： 1、ASP+XML+XSLT开发，代码、界面、样式全分离，可快速开发 2、支持语言包，支持多模板，ASP文件中无任何HTML or 中文 3、无限级分类，无限级菜单，自由排序 4、自定义版头（用于不规则页面） 5、自动查找无用的上传文件与空目录，并有回收站，可删除、还原、永久删除 6、增强的Cache管理，可单独管理单个Cache 7、以内存和XML做为Cache，兼顾性能与消耗 8、
- 执行
CONFIG GET repl-disable-tcp-nodelay，返回["repl-disable-tcp-nodelay","yes"]就是嫌疑对象 - 观察
INFO replication中的master_repl_offset和从节点的slave_repl_offset差值是否稳定在几百～几千字节（而非 MB 级），且延迟集中在 20–50ms 区间 —— 这是 Nagle 算法的典型指纹 - 对比改配置前后的
redis-cli --latency -h slave_ip -p port输出，若平均延迟下降明显，基本坐实
repl-disable-tcp-nodelay=no 之后为什么还有延迟
禁用 Nagle 只解决“小包攒发”问题，不解决其他瓶颈。常见残留原因：
-
repl-backlog-size不足：主节点写入突增时 backlog 溢出，触发全量重同步，日志出现Master does not have enough backlog - 从节点磁盘慢：AOF fsync 或 RDB 加载卡住，
INFO persistence中aof_delayed_fsync或rdb_bgsave_in_progress长时间为 1 - 网络丢包或高 RTT：用
ping和mtr测主从间链路，RTT > 5ms 或丢包率 > 0.1% 就需排查 - 从节点 CPU 过载：
INFO cpu中used_cpu_sys_children持续升高，说明子进程（如 RDB 加载）占满 CPU
生产环境修改 repl-disable-tcp-nodelay 的注意事项
这个参数改起来快，但副作用必须提前对齐：
- 带宽用量会上升：高频小写场景（如每秒 1k+
INCR）下，TCP 包数量可能翻倍，需确认主从间链路带宽余量 ≥ 30% - 只影响主→从复制流：不影响客户端连接、AOF rewrite、cluster bus 等其他 TCP 连接，不用全局调优
- 动态生效但不重置 backlog：执行
CONFIG SET repl-disable-tcp-nodelay no后，新产生的复制流立即低延迟，但已有 backlog 缓冲区仍按旧策略发送（直到被消费完） - 跨机房慎用：如果主从在不同地域，
no可能放大网络抖动影响，此时应优先优化网络，而非硬切参数
真正棘手的延迟往往藏在 repl-backlog-size 和从节点 I/O 能力里，repl-disable-tcp-nodelay 是第一张该翻的牌，但不是最后一张。
