Redis集群内网带宽消耗主因是Gossip协议心跳、拓扑同步和故障探测，走16379集群总线端口，不体现于客户端网络指标；需通过INFO replication的repl_offset差值和INFO stats的instantaneous_input/output_kbps间接估算，异常时用redis-cli --cluster check和tcpdump抓包分析。
直接看 INFO replication 和 INFO stats 里的关键字段
Redis 集群节点间带宽消耗，核心不在“集群命令”本身，而在于 Gossip 协议心跳、拓扑同步和故障探测产生的持续内网通信。它不走客户端端口（如 6379），而是走集群总线端口（默认 redis-server 启动时自动 +10000，即 16379），但这些流量**不会体现在客户端网络指标里**——你查 total_net_input_bytes 或云监控的“实例入/出流量”，只反映客户端读写，不包含节点间通信。
真正能间接估算集群内网开销的，是这两个地方：
-
INFO replication中的master_repl_offset（主节点）和slave_repl_offset（从节点）：偏移量差值越大、追赶越慢，说明复制积压多，持续拉取 RDB/AOF 数据会抬高瞬时带宽； -
INFO stats中的instantaneous_input_kbps/instantaneous_output_kbps：这是**所有 TCP 连接**（含集群总线连接）的实时吞吐估算，只要节点间有活跃通信，这里就会跳动——但它无法区分是客户端还是集群总线流量。
用 redis-cli --cluster check + 抓包定位异常 Gossip 流量
当发现某几个节点间内网带宽持续偏高（比如阿里云/腾讯云控制台显示节点间 ENI 流量突增），先排除是否因配置或状态异常导致 Gossip 频繁重传：
- 运行
redis-cli --cluster check <any-node-ip>:6379</any-node-ip>，检查是否有FAIL状态节点未被及时摘除，或NOADDR节点残留——这类异常会让其他节点每秒多次尝试重连并重发 gossip 消息； - 在怀疑节点上执行
tcpdump -i any port 16379 -w cluster-gossip.pcap抓包 30 秒，用 Wireshark 打开后过滤redis协议，观察 packet size 是否普遍 >1KB（正常 gossip ping/ping-ack 很小，MEET 或UPDATE消息携带了冗余的 slots 映射表，说明集群规模大但cluster-node-timeout设置过小（如 - 确认
cluster-node-timeout值：过小（5000）→ 故障发现慢，但单次 gossip 包更紧凑。建议 2000–3000ms 之间，且所有节点保持一致。
避免用 INFO server 的 redis_version 判断兼容性引发额外握手
集群节点启动或新节点加入时，会通过 CLUSTER MEET 发送自身版本号；如果集群中混用 Redis 6.x 与 7.0+，且启用了 ACL 或 TLS，部分版本组合会在每次 gossip 交互中附带额外的 ACL LOG 或证书协商字段，使单个 gossip 包体积翻倍——这不是 bug，而是协议协商的副作用。
- 检查所有节点
redis_version是否统一：不同大版本（如 6.2.6 vs 7.2.4）混部，尤其开启tls-cluster yes时，gossip 流量可能增加 30%–50%； - 不要仅靠
INFO server查版本就认为安全——还得看CONFIG GET tls-cluster和CONFIG GET aclfile是否全集群一致； - 升级前务必在测试环境用
redis-benchmark -c 100 -n 10000 -t set,get --cluster对比升级前后集群总线流量基线，而非只测客户端 QPS。
云环境必须关掉“集群模式下无意义”的客户端监控指标
很多团队习惯用 redis-cli INFO stats 的 total_net_input_bytes 除以时间来算“平均带宽”，再和云厂商提供的“网络带宽使用率”对比——这在集群场景下完全失真。云监控里的“带宽使用率”只统计绑定 ENI 的 6379 端口流量，而集群总线（16379）走的是同一块网卡但不同端口，Linux 内核层面属于独立 socket 流量，云平台通常不采集也不告警。
- 别把
total_net_input_bytes当作集群内网开销依据——它包含客户端请求、AOF rewrite 输出、RDB save 临时文件写入等，干扰项太多； - 云厂商控制台看到的“带宽超限告警”，只对客户端流量有效；集群总线打满导致节点失联，云监控往往只报“节点不可达”或“CPU 突增”，不会提示“16379 端口被打满”；
- 真要监控集群总线带宽，得在节点上跑
iftop -P 16379或ss -i sport = 16379，看每个连接的rcv-ssthresh/snd-cwnd是否持续为 10，那是丢包重传的明确信号。
集群节点数超过 20 后，Gossip 协议本身的 O(N²) 消息扩散效应会开始明显，这时候光看单个节点的 instantaneous_output_kbps 没用——你得画出节点间通信矩阵，否则永远不知道是哪个 pair 在疯狂互发 UPDATE。
