Redis主从复制本身非阻塞，但fork子进程（如BGSAVE）在大内存高负载下耗时可达数十毫秒，导致主线程系统调用延迟、P99响应上扬；需监控latest_fork_usec、调优vm.overcommit_memory、增大repl-backlog-size并避免高峰期频繁触发持久化。
不会阻塞主库写操作，但某些间接因素可能拖慢主库响应。 Redis 主从复制本身是完全非阻塞的，主库在同步期间照常处理所有客户端命令——这点必须先明确，否则后续排查容易走偏。
主库 fork 子进程时的短暂抖动
主库收到 PSYNC 或 SYNC 请求后，会立即 fork 一个子进程执行 bgsave。这个 fork 操作本身不是阻塞命令，但它在内核层面需要拷贝页表、分配内存结构，当主库内存大（比如 >20GB）且写负载高时，fork 耗时可能达几十毫秒。这期间主线程虽然仍在运行，但系统调用可能被延迟，表现为少量请求 P99 延迟上扬。
- 监控
INFO stats中的latest_fork_usec，若持续超过 50ms，说明fork成本过高 - 避免在高峰期手动触发
BGSAVE或配置过小的save规则（如save 60 10000），防止频繁fork - 启用
vm.overcommit_memory = 1（Linux 内核参数），降低fork失败或变慢概率
RDB 文件传输对网络和 CPU 的压力
主库把 RDB 发给从库，走的是主线程的事件循环，不阻塞命令处理，但会占用发送带宽和 CPU 时间片。尤其当启用 repl-diskless-sync yes 时，RDB 不落盘、直接通过 pipe 流式发送，CPU 和网卡发送队列压力更明显。
- 观察
INFO replication中的master_repl_offset是否稳定增长；若停滞，可能是网卡打满或从库接收慢 - 检查
netstat -s | grep -i "retransmit"，重传增多说明网络链路不稳定，可能触发全量重同步 - 多从库场景下，优先采用树状复制（
slave → slave），减少主库直连从库数量
复制积压缓冲区溢出引发的连锁反应
主库维护的 repl-backlog 是固定大小的环形缓冲区，默认仅 1MB。高并发写入下，如果从库断连时间稍长，缓冲区很快被覆盖，导致从库重连后无法增量同步，只能再次全量同步——这时主库又要 fork + bgsave + 传输，形成恶性循环。
- 根据写入 QPS 和平均断连恢复时间，估算所需 backlog：比如每秒写入 5MB，断连容忍 30 秒 → 至少设为
repl-backlog-size 150mb - 不要依赖默认值；生产环境建议设为 100–500MB，并配合
repl-backlog-ttl控制空闲释放 - 注意：增大 backlog 会常驻占用主库内存，不是无代价的
真正要盯住的不是“复制是否阻塞”，而是 fork 开销、网络吞吐、backlog 容量这三个实际可测的瓶颈点。它们不写在协议里，却决定着高并发下主库是否“看起来像卡住了”。
