Redis集群从节点频繁掉线检查MTU与心跳包大小

揭示一个容易被忽视的问题：Redis集群中从节点频繁掉线，绝大多数情况并非配置错误，而是网络层默默出现丢包——尤其是MTU参数不匹配时，心跳包被迫分片甚至直接被截断。

先说核心判断：MTU不一致确实会导致Redis从节点掉线，这听起来有些反直觉，但却是真实的线上踩坑经验。心跳包（PING/PONG）走TCP协议，而Gossip消息中单个数据包可能超过1.5KB。当主从节点之间的网络设备（如VPC网关、安全组、物理交换机）MTU设置为1400，而节点系统仍采用默认1500时，就会触发IP分片。问题在于，许多云厂商或中间设备默认禁用IP分片，甚至直接丢弃分片包。最终结果是，主节点发出的PING石沉大海，PONG无法收回，一旦cluster-node-timeout超时，从节点就会被标记为PFAIL。

这类丢包非常隐蔽——用ping无法检测到（ICMP包太小），用mtr的ICMP探测也难以发现。必须分析真实的TCP数据流才能定位。

• 在主节点执行ss -i dst :6379，检查重传（retrans）、SACK丢失（loss）、窗口阻塞（wscale）等字段是否存在异常波动。
• 在主从节点同时进行抓包：tcpdump -i any 'port 6379 and (tcp[12:1] & 0xf0) > 0x50' -w cluster-heartbeat.pcap（仅抓取TCP头部大于等于80字节的数据包，过滤掉纯ACK包）。
• 在Wireshark中过滤tcp.len > 0 and tcp.flags.syn == 0，观察是否存在大量IPv4 fragment或TCP segment not captured in full的提示信息。

如何确认与修复MTU问题

不要直接修改系统MTU——Redis集群通信是双向的，主从角色随时可能互换，而且许多云平台不允许修改网卡MTU。更稳妥的做法是让Redis主动适配网络环境：

• 在所有节点的redis.conf中显式配置tcp-keepalive 60（启用TCP保活机制，防止NAT清空连接表）。
• 降低Gossip消息密度：将cluster-node-timeout增大至至少20000（20秒），为分片重传预留缓冲时间。
• 强制限制单次心跳包大小：Redis本身不提供此参数，但可通过内核级限速规避分片风险——使用tc qdisc add dev eth0 root tbf rate 10mbit burst 16kbit latency 100ms压制突发流量，减少大包集中发送。
• 终极验证：在主节点执行redis-cli -c -h CLUSTER NODES，检查返回节点列表中目标从节点状态是否稳定为connected，而非disconnected或fail?。

容易被忽视的两个关键点

首先，cluster-node-timeout不能仅看数值本身，它必须大于路径中最大RTT的3倍。如果mtr --tcp -P 6379 显示某跳RTT抖动σ超过150ms，那么即便将cluster-node-timeout设置为30000也不足以应对。

其次，所有节点的tcp-keepalive参数必须保持一致，否则保活周期错位会导致"主节点认为连接正常，但从节点认为已经断开"的单向失联问题。

真正棘手的，从来不是参数如何调整，而是首先要确认丢包发生的跳点——究竟是在云厂商的BGP边界，还是自家机房的ToR交换机buffer溢出。只有明确了这个前提，后续的修复才能有的放矢。