Redis主从全量同步带宽只能通过tc在操作系统层限速，因RDB传输和repl_backlog数据流直走TCP，不受Redis心跳或缓冲区参数控制；需配合调大repl-timeout、启用无盘复制及放宽slave缓冲区。
Redis主从全量同步本身不提供带宽限速参数，必须在操作系统网络层用tc对主节点出向流量整形；仅调Redis配置如repl-ping-slave-period或repl-backlog-size无法实质性压低峰值带宽。
为什么改Redis参数压不住带宽
很多人试过调大repl-ping-slave-period、缩小repl-backlog-size，甚至关掉save，但redis-cli --stat看到主节点out流量还是飙高——因为真正吃带宽的是RDB文件直传和repl_backlog数据流，这两者都走TCP socket发送，不受心跳或缓冲区大小的“节流”控制。
常见误判点：
-
repl-ping-slave-period只影响PING包频率，而每秒一次的REPLCONF ACK（从库发给主库）才是固定小包主力，且不可关闭 -
repl-backlog-size设小了会导致增量同步失败、反复退化为全量，反而放大总流量 -
client-output-buffer-limit slave限制的是主节点内存缓冲区，不是网卡出口速率，超限只会断连，不降速
用tc在主节点做端口级限速
这是唯一能稳态压制全量同步带宽的方法。关键不是“能不能限”，而是“限得准不准、会不会断连”。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
实操要点：
- 确认主节点
redis-server监听的网卡（如eth0）和端口（默认6379），限速必须作用于**出向（egress）** 流量 - 先建HTB根队列：
tc qdisc add dev eth0 root handle 1: htb default 30 - 再加限速class（例如50Mbps硬上限）：
tc class add dev eth0 parent 1: classid 1:1 htb rate 50mbit ceil 50mbit - 最后用filter把6379端口出向流量导进去：
tc filter add dev eth0 protocol ip parent 1:0 u32 match ip dport 6379 0xffff flowid 1:1 - 限速后务必调大
repl-timeout（建议≥120），否则因传输变慢触发超时重试，反而增加总流量
配套Redis配置必须同步调整
单靠tc限速，不调Redis参数，容易引发缓冲区溢出、CPU飙升或从库断连。三个必须配对的动作：
- 开无盘复制：
CONFIG SET repl-diskless-sync yes，避免主节点先写RDB再读取的IO放大，让tc控的全是纯网络流 - 设延迟聚合：
CONFIG SET repl-diskless-sync-delay 5，防止多个从库同时重连触发多次bgsave，减少突发流量毛刺 - 放宽slave缓冲区：
CONFIG SET client-output-buffer-limit "slave 256mb 64mb 60"，给限速下的传输留足缓冲窗口，避免中途被kill
验证是否真生效
别只看tc -s class show dev eth0的平均速率——它可能掩盖突发。要交叉验证：
- 主节点执行
redis-cli INFO replication，观察master_sync_left_bytes下降速度是否稳定在限速值附近（如50Mbps ≈ 6.25MB/s） - 查日志：启用
slowlog并设阈值100ms，确认bgsave和replconf无频繁超时 - 从节点看
slave_repl_offset是否持续追近master_repl_offset，而非反复跳回wait_bgsave状态
最容易被忽略的是：限速后若没同步调大repl-timeout，从库会在RDB传到99%时断连重试，导致带宽看似“用了又白用”。
