为什么Redis从节点执行Slaveof命令后主库会卡顿-Redis-PHP中文网

全量同步导致主节点变慢，是因为bgsave触发fork阻塞主线程、rdb传输抢占io与带宽、repl_backlog缓存压力三重资源争抢；可通过info replication中loading、master_repl_offset等指标确认。

为什么redis从节点执行slaveof命令后主库会卡顿

主节点卡顿不是 Slaveof 命令本身导致的，而是从节点发起全量同步时，主节点执行 BGSAVE + RDB 传输引发的资源争抢

为什么全量同步会让主节点变慢

从节点执行 SLAVEOF 或 REPLICAOF 后，若触发全量同步（而非部分同步），主节点必须立即做两件事：生成当前内存快照（BGSAVE），再把 RDB 文件通过网络发给从节点。这两个动作都会显著消耗主节点资源：

BGSAVE 是 fork 子进程操作，会复制主进程页表——在大内存实例（如 20GB+）上，fork 耗时可能达数百毫秒，期间主线程阻塞，新请求排队
RDB 文件传输占用大量磁盘 IO 和带宽，尤其当从节点网络较慢或并发多个从节点同时拉取时，主节点磁盘队列堆积、CPU sys 时间上升
主节点还需把 BGSAVE 过程中产生的写命令缓存进 repl_backlog，若 repl-backlog-size 配得太小，缓冲区满后会丢弃旧命令，迫使后续重连又得全量同步，形成恶性循环

如何判断是不是全量同步引起的卡顿

登录主节点，运行 INFO replication，重点关注这几项：

Redis 8.2.3

Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。

下载

loading:1 表示主节点正在生成 RDB（此时已卡顿）
master_repl_offset 增长明显变慢甚至停滞，说明写入被阻塞
connected_slaves 突然增加，且新从节点的 slave_repl_offset 长时间为 0，基本可确认它刚走完全量流程
用 redis-cli --stat 观察 instantaneous_ops_per_sec 是否断崖式下跌

避免卡顿的关键配置与操作

不是所有全量同步都不可避免，但可以大幅降低发生概率和影响程度：

主节点开启 rdb-save-incremental-fsync yes（Redis 6.0+），让 RDB 写入分批刷盘，缓解磁盘压力
调大 repl-backlog-size（例如 256mb），配合合理设置 repl-backlog-ttl，延长部分同步窗口
禁止在业务高峰执行 SLAVEOF；如需切换，优先选低峰期，并确保目标从节点之前已连接过该主节点（复用 RunID）
若主节点内存超 16GB，考虑启用 copy-on-write 友好型持久化：关闭 AOF 或改用 aof-use-rdb-preamble yes，减少 fork 开销

最常被忽略的细节：从节点加载 RDB 期间也会反向拖慢主节点

从节点收到 RDB 后要解压、解析、逐条插入——这个过程如果很慢（比如从节点内存不足、磁盘慢、启用了 slave-load-disabled no），它就会迟迟不发 PSYNC 完成确认，主节点会一直维持 RDB 传输连接和 backlog 缓存，无法释放资源。所以卡顿未必只发生在主端，也可能是从端处理能力不足造成的“假性主卡”。