SYNC命令在Redis 2.8之前强制触发全量同步，主节点需BGSAVE生成RDB、清空从节点数据并全量传输，期间阻塞写请求、fork开销大、无增量机制，易引发级联雪崩。
SYNC命令在Redis 2.8之前会触发全量同步
Redis主从复制中，SYNC 是旧版（2.8 以前）主从建立连接时的初始同步命令。它要求从节点清空本地数据，然后主节点生成 RDB 快照、传输整个文件，并在传输期间阻塞所有写请求。这个过程不是增量的，而是「全量重刷」——哪怕只差几百字节，也要重传几 GB 的 RDB。
在集群环境下，如果多个从节点同时发起 SYNC（比如主节点重启后大批从节点重连，或网络抖动导致连接批量断开重试），主节点会并发生成多个 RDB 文件，CPU 和磁盘 I/O 瞬间拉满；同时写请求被阻塞，客户端超时堆积，连接数暴涨，最终表现为集群整体响应延迟飙升、部分节点超时下线，形成级联性能雪崩。
从节点执行SYNC时主节点无法服务新请求
SYNC 不是后台异步操作。主节点执行 bgrewriteaof 或 save 类似，但更重：它必须 fork 出子进程生成 RDB，而 fork 在大内存实例上可能耗时数百毫秒（尤其当 Redis 占用 20GB+ 物理内存时）。fork 本身会阻塞主线程，且子进程会拷贝页表、竞争内存带宽，进一步拖慢主节点处理能力。
常见踩坑点包括：
- 未升级到 Redis 2.8+，仍在用原始
SYNC协议 - 主节点配置了
repl-backlog-size但太小（默认仅 1MB），导致从节点断连后无法走PSYNC增量同步，被迫降级为SYNC - 监控缺失，没发现从节点频繁断连重试（如因网络 MTU 不匹配、TCP keepalive 设置过短）
Redis 2.8+ 的 PSYNC 已替代 SYNC，但降级仍可能发生
新版使用 PSYNC 实现部分重同步，依赖复制偏移量和复制积压缓冲区（repl-backlog）。只要从节点断连时间短、积压缓冲区未被覆盖，就能跳过全量同步。
但以下情况仍会强制回退到 SYNC：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 从节点发送的
run_id与当前主节点不匹配（例如主节点重启过） - 从节点上报的偏移量超出
repl-backlog范围（缓冲区太小或断连太久） - 主节点启用了
replica-serve-stale-data no且从节点尝试同步时主节点尚未完成加载 RDB
此时日志里会出现 Partial resynchronization not accepted，紧接着就是 Starting BGSAVE for SYNC —— 雪崩信号已出现。
如何验证和规避SYNC引发的雪崩
最直接的方式是抓取主节点 INFO 输出：
redis-cli info replication | grep -E "(loading|sync_partial_err|sync_full)"
若看到 loading:1 持续较久，或 sync_full 计数突增，基本可确认问题。
实操建议：
- 强制升级到 Redis 5.0+（避免 2.8/3.x 中某些 PSYNC 边界 bug）
- 将
repl-backlog-size设为写流量 2 分钟的量级（例如每秒写入 1MB，则设为120000000） - 禁用
slave-read-only no这类危险配置，防止从节点误写导致 run_id 失效 - 在主节点启用
latency-monitor-threshold 100，配合redis-cli --latency定期探测 fork 延迟
真正难防的不是 SYNC 本身，而是它在高内存 + 高写入 + 弱网络组合下的连锁反应——一个参数调小、一次偶然断连、一条没看的日志，都可能成为雪崩起点。
