Redis主从复制时，如何大Key以减轻同步带宽压力？

本文共计906个文字，预计阅读时间需要4分钟。

在Redis主从复制过程中，如果某个key是大Key（例如，数MB乃至数十MB的hash、zset或list），主节点会将整个key序列化后，通过REPLCONF协议一次性发送给从节点。这不仅会占用大量带宽，还可能阻塞其他命令的复制，导致从节点上的master_repl_offset严重滞后，甚至可能因timeout导致连接断开。

典型现象包括：INFO replication中slave_repl_offset长期停滞、net_output_bytes突增、从节点日志频繁出现Timeout waiting for bulk read。

• Redis 6.0+ 虽支持repl-diskless-sync yes减少磁盘IO，但不解决大Key单次传输问题
• client-output-buffer-limit slave默认值（256MB/64MB/60s）很容易被一个大Key打穿，直接断连
• 主节点redis-cli --bigkeys能发现大Key，但不会告诉你它正在拖垮复制

用HSCAN/SSCAN等渐进式命令拆分大hash/set

不能直接HDEL或DEL大Key——这会造成主节点瞬间高CPU和阻塞，且删除操作本身又会作为一条大命令同步到从节点，形成二次冲击。

正确做法是：在业务低峰期，用游标方式分批读取+写入新结构，再逐步清理旧Key。