Redis主从复制默认为异步机制，主节点执行写命令后立即返回客户端，不等待从节点确认；但全量同步时RDB发送受从节点接收能力影响，且bgsave阻塞、repl-backlog过小或大量从节点连接等场景会间接拖慢主节点性能。
不会直接影响主节点性能，但某些配置不当或异常场景下，会间接拖慢主节点的 RDB 发送或命令分发。
主节点不等从节点确认，异步复制是默认行为
Redis 主从复制本质是异步的：replicaof 建立连接后，主节点收到写命令立即返回客户端，不等待从节点执行完成。这意味着：从节点卡住、加载慢、甚至断连，都不会阻塞主节点的写入吞吐。
但注意两个例外：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 主节点在全量同步阶段发送 RDB 文件时，是通过 TCP socket 持续写入的；如果从节点接收极慢（比如缓冲区满、网络卡顿），主节点的 socket write 可能被阻塞或触发重试逻辑
- 若
client-output-buffer-limit slave配置过严（如256mb 60 60），从节点响应延迟会导致主节点输出缓冲区超限，主节点会主动断开该从节点连接——这本身不拖慢主节点，但频繁断连重连会增加主节点 CPU 和连接管理开销
真正影响主节点的，是那些“看起来像从节点问题”的底层瓶颈
从节点同步慢，常被误认为纯从端问题，但根源可能在主节点身上：
-
bgsave_in_progress为 1 且持续时间长 → 主节点生成 RDB 时 CPU 或磁盘 IO 饱和，RDB 文件还没产出，从节点自然无数据可收 - 主节点
repl-backlog-size太小 + 写入突增 → 增量命令被挤出环形缓冲区，从节点断连后无法部分重同步，被迫发起新一轮全量同步，反复触发bgsave - 主节点同时服务大量从节点（比如 >5），又没调大
tcp-keepalive或repl-timeout，个别从节点网络抖动就会引发批量重连，加重主节点事件循环压力
如何快速判断是不是主节点被拖累
别只盯着从节点的 master_sync_left_bytes，先看主节点状态：
- 执行
INFO persistence，检查rdb_bgsave_in_progress和rdb_last_bgsave_time_sec：如果上次 RDB 耗时 >30s，或长时间处于 in_progress 状态，说明 RDB 生成已成瓶颈 - 执行
INFO clients，看connected_clients和client_longest_output_list：后者值过大（比如 >10000）说明某个从节点的输出缓冲区堆积严重，主节点正在“等它清空” - 用
redis-cli --latency -h [master-ip] -p 6379测主节点自身响应延迟；再对比redis-cli --latency -h [slave-ip] -p 6379—— 若主节点延迟也明显升高，问题就不在从节点同步路径上
最容易被忽略的是：主节点磁盘 IO 被其他进程占用，导致 bgsave 写 RDB 极慢，进而让整个同步流程卡在第一阶段。这时候改从节点配置毫无意义，得先查 iostat -x 1 和 iotop。
