Redis不存在repl-socket-mtu配置项，官方文档及各稳定版本源码均无此参数，强行添加会导致启动失败或被CONFIG REWRITE自动剔除。
Redis 没有 repl-socket-mtu 这个配置项，它根本不存在。 你查到的这个参数是混淆或误传——官方文档、源码、所有稳定版本（包括 7.0/7.2/8.0）均无此配置。强行在 redis.conf 里写入会触发启动失败（Unknown configuration parameter），或被 CONFIG REWRITE 自动剔除。
为什么有人提到 repl-socket-mtu？
这是对底层网络行为的误解性“包装”：有人观察到 TCP 包大小影响复制吞吐，就臆造出一个“MTU 控制参数”。实际上，Redis 复制走的是普通 TCP socket，其分包行为由内核协议栈控制，和应用层无关。真正起作用的是：repl-disable-tcp-nodelay（控制 Nagle 算法）、TCP MSS、路径 MTU 发现（PMTUD）、网卡 txqueuelen 等系统级设置。
想提升复制吞吐，该调什么？
直接干预有效、可验证的点：
-
repl-disable-tcp-nodelay yes：仅当满足两个条件时才开——跨机房 RTT 稳定 0.1%（netstat -s | grep "segments retransmitted"）；否则默认no更安全 - 增大主节点
repl-backlog-size至 2gb+：避免小抖动就触发全量同步，间接提升增量同步连续性 - 确认主从使用万兆网卡且开启
ethtool -K eth0 tso on gso on：启用 TCP 分段卸载，减少 CPU 包处理开销 - 禁用从节点
slave-read-only no（如果误开）：写操作会阻塞复制命令执行流，造成 lag 突增
抓包验证时别被假象误导
用 tcpdump -i any port 6379 抓复制流后，Wireshark 里看到大量 repl-disable-tcp-nodelay no 下的正常行为（Nagle 关闭，每条命令立即发）。此时改系统 MTU 不仅无效，还可能因 IP 分片引发丢包。真正该看的是：tcp.len 分布是否集中在 1–2KB（健康），还是碎片化在 64–128B（说明写入稀疏或 client 频繁短连）。
Redis 复制性能瓶颈从来不在“MTU 设置”，而在写入节奏、网络稳定性、缓冲区容量与从节点执行能力的匹配。盯着不存在的参数调，不如先跑一遍 INFO replication 和 redis-cli --stat 看真实 offset 差和输出带宽。
