Redis主从同步性能瓶颈排查：当全量同步“卡”住时，你在看哪里？
主库 bgsa ve 卡住，其实是磁盘 IO 被拖垮了
遇到全量同步慢，第一反应往往是“网络不行”。但真相是，当问题卡在主库的 bgsa ve 阶段时，十有八九不是CPU算力不足，而是磁盘的写入速度彻底跟不上了。尤其是在使用机械硬盘、云盘IOPS被限速，或者RDB文件过大（比如超过2GB）的场景下，bgsa ve 子进程会长时间阻塞，导致主线程的复制缓冲区持续积压，最终触发从库重试，形成一个恶性循环。
- 用
redis-cli --stat实时观察：如果看到bgsa ve_in_progress:1状态持续超过30秒，同时used_memory_human突然增长、latest_fork_usec大于500000（即500毫秒），基本可以断定是fork和写盘遇到了双重瓶颈。 - 查磁盘真实压力：运行
iostat -x 1 3，关注%util是否长期高于90%，以及await是否大于50ms。在云环境下，要特别留意EBS或云盘的IOPS配额是否已经用尽。 - 解决思路：临时方案是停掉自动RDB保存（执行
CONFIG SET sa ve ""），改用AOF并设置appendfsync everysec。长期根治则需要迁移到SSD硬盘、升级云盘配置，或者考虑拆分大实例。
从库加载 RDB 慢，别只盯 CPU，先看网络吞吐是否被限死
从节点上执行 INFO replication，如果显示 master_sync_in_progress:1 状态持续很久，但 master_sync_left_bytes 下降得极其缓慢（比如每秒只减少几MB），那就说明RDB文件压根没“流”进来——问题不在于从库解析数据的能力，而在于主库发不出来，或者中间的传输链路被卡住了。
- 确认主库是否真在发数据：在主节点上使用
ss -i或tcpdump -i any port 6379抓包，观察是否有持续的大块TCP数据包（大于1MB）发出。如果没有，问题就出在主库的发送环节。 - 检查
client-output-buffer-limit sla ve配置：如果这个值设成了256mb 64mb 60，而RDB文件有4GB，传输需要200秒，那么在60秒内累计超过64MB，主节点就会强制断开连接，导致从库反复重试全量同步。 - 生产环境建议：直接将其设置为
1024mb 512mb 60。同时，确保从库的网卡和交换机端口没有被限速，尤其是在跨机房场景下，TCP窗口缩放、MTU不匹配等问题都可能导致网络吞吐量骤降。
repl-backlog-size 设小了，表面是同步慢，实际是被迫反复全量
从节点断线重连后，没有走增量同步（PSYNC），而是直接回退到全量同步（SYNC）。这往往不是因为网络断开太久，而是因为主节点的复制积压缓冲区太小，旧的复制偏移量（offset）对应的数据早就被新数据覆盖了。这会让一个本该毫秒级恢复的同步，变成耗时数分钟的RDB重传。
- 估算公式必须带余量：
repl-backlog-size = QPS × a vg_cmd_size × max_reconnect_time × 1.5。举个例子，如果写入QPS是3000，平均命令大小是180B，要求能容忍180秒的断连，那么至少需要145MB的缓冲区。但在生产环境中，建议直接从512MB起步，甚至设为1024mb。 - 理解缓冲区特性：
repl-backlog-size是一个环形缓冲区，设置得大一些并不会占用常驻内存，只在有写流量时动态分配。相反，如果设小了，会引发雪球效应：一次全量同步失败，会导致更多从库排队等待RDB，进而给主库带来更大压力，使得从库更容易断连。 - 验证配置是否生效：通过
CONFIG GET repl-backlog-size和INFO replication命令，检查repl_backlog_active（应为1）和repl_backlog_size（应与配置值一致）。
diskless sync 开启后反而更慢？那是没关 THP
启用 repl-diskless-sync yes 的本意是跳过主库落盘，直接通过socket发送RDB数据。但如果操作系统开启了透明大页（THP），在fork子进程时，会将整个Redis内存按2MB的大页单位进行拷贝，导致 latest_fork_usec 暴涨到数秒，反而比落盘到磁盘还要慢。
- 立刻检查并关闭THP：运行
cat /sys/kernel/mm/transparent_hugepage/enabled，如果输出包含[always]，必须关闭它：echo never > /sys/kernel/mm/transparent_hugepage/enabled。 - diskless sync 的真正受益场景是：主库磁盘性能极差，但网络条件非常好（比如万兆同机架）。否则，保持
repl-diskless-sync no，让bgsa ve异步写盘，往往更可控。 - 开启diskless后的必要配合：务必设置
repl-diskless-sync-delay（建议5~10秒），为子进程的fork操作留出时间，避免因并发连接激增导致fork失败。
最后，还有一个最容易被忽略的底层因素：以上所有调优，都必须建立在一个基础上——主从节点之间的系统时间必须同步。记得用 ntpq -p 检查一下时间偏移量。
