根本原因是主节点输出缓冲区过小或复制积压缓冲区不足，导致RDB传输中断或offset丢失，被迫反复全量同步；需调大client-output-buffer-limit和repl-backlog-size，并优化从节点加载性能。
这个问题本质不是“带宽不对称”导致的死锁，而是主节点发送能力与从节点接收/处理能力不匹配，叠加缓冲区配置失当，引发反复全量同步失败的恶性循环。物理带宽本身是双向对称的，所谓“不对称”其实是传输方向上的瓶颈错位：主节点发RDB快，但网络或从节点跟不上；或从节点ACK慢，主节点误判超时断连。
先确认是不是真卡在网络传输环节
别一上来就调带宽参数。先定位卡点：
- 在从节点执行
INFO replication，看master_sync_in_progress:1持续时间是否远超预期；再紧盯master_sync_left_bytes—— 如果这个值下降极慢（比如每秒只减几KB），且主节点CPU、内存、磁盘IO都正常，才说明传输确实被卡住 - 用
redis-cli --stat在主节点观察repl_transfer_rate和repl_transfer_size，如果传输速率长期低于链路理论带宽的30%，再查网络设备QoS策略、中间防火墙限速、MTU不一致等 - 检查主节点
client-output-buffer-limit slave配置：若设置过紧（如默认256mb 64mb 60），RDB还没传完缓冲区就溢出，主节点会直接断开从节点连接，触发下一轮全量重试
调大主节点输出缓冲区，避免未传完就被强断
这是最常被忽略的关键动作。主节点为每个从节点单独分配输出缓冲区，RDB文件正是通过它发送的。一旦超出硬限制，连接立刻中断。
- 立即生效命令：
CONFIG SET client-output-buffer-limit "slave 1024mb 512mb 120" - 对应配置文件项：
client-output-buffer-limit slave 1024mb 512mb 120 - 注意：soft limit（512MB）必须小于 hard limit（1024MB），且 soft seconds（120秒）要足够覆盖大RDB传输耗时。实测RDB大小 × 1.2 ÷ 当前传输速率 ≈ 所需最小时间
扩大复制积压缓冲区，减少增量同步失败概率
即使传输没断，网络抖动或从节点短暂卡顿也会导致其复制偏移量（offset）掉出主节点的 repl-backlog 范围，被迫退化为全量同步。
- 推荐起步值：
CONFIG SET repl-backlog-size 536870912（512MB） - 验证是否生效：
INFO replication中查看repl_backlog_histlen是否稳定在repl_backlog_size的 40%–70% 区间。长期接近100%，说明还得再加 - 该配置不会自动写入 redis.conf，务必同步修改配置文件并执行
CONFIG REWRITE或手动重启
优化从节点加载阶段，防止“传得快却吞不下”
从节点接收到RDB后需要解压、解析、重建数据结构，这个过程如果被其他操作干扰（如AOF重写、内存碎片整理），就会拖慢整体同步节奏，间接拉长主节点缓冲区占用时间。
- 从节点启动时禁用RDB自动保存：
CONFIG SET save ""，避免SAVE或BGSAVE与同步加载争抢CPU和磁盘IO - 确保从节点使用SSD，且关闭AOF重写竞争：
CONFIG SET auto-aof-rewrite-percentage 0，等同步完成后再恢复 - 检查从节点是否启用了THP（透明大页）：
cat /sys/kernel/mm/transparent_hugepage/enabled，若显示[always]，必须改为never，否则加载RDB时内存拷贝延迟飙升
不复杂但容易忽略：真正卡住的往往不是带宽本身，而是缓冲区、加载能力和配置协同。把这三块理顺，频繁全量重试基本就止住了。
