大key在Redis主从同步中会触发复制断连，表现为从库state由online突变为offline、日志反复出现Connection with master lost和Resyncing from master，根源是RDB/AOF传输超时或内存溢出。
大key在Redis主从同步中会触发什么错误
当主从复制链路意外断开时，如果看到的错误信息不是常见的 READONLY You can't write against a read only replica，那基本可以排除权限问题。真正的“元凶”，往往是数据同步过程中，从库在接收庞大的RDB文件或AOF流时，发生了传输超时或内存溢出。
典型的场景是什么样的呢？在主库执行 INFO replication 命令，你会发现原本显示为 sla ve0:ip=..., state=online 的从库，状态突然变成了 state=offline。与此同时，从库的日志里会反复刷出两条信息：先是 Connection with master lost，紧接着就是 Resyncing from master。这一连串的信号，清晰地表明复制链路被强制中断并尝试重连。而重连失败或者频繁重试的背后，十有八九是某一次需要传输的数据体量过大，直接把通道给“撑”断了。
用redis-rdb-tools快速定位大key
要精准定位问题源头，redis-rdb-tools 是目前最受推崇的离线分析工具。它的优势在于轻量且准确，不依赖Redis服务运行，直接解析RDB文件就能统计出每个key的大小——这里统计的是value序列化后的字节长度。这一点很关键：它反映的尺寸更贴近网络传输时的实际开销，比Redis内置的 MEMORY USAGE 命令更具参考价值。
具体操作分几步走：
- 首先，从主库生成当前的RDB文件。可以使用
redis-cli --rdb /tmp/dump.rdb命令，为了确保数据一致性，最好在业务低峰期或使用SA VE命令（会阻塞）来完成。 - 接着，运行
rdb -c memory /tmp/dump.rdb > memory.csv，工具会生成一个CSV文件，里面的key已经按照内存占用从高到低排好了队。 - 最后，分析这个列表时需要特别警惕
type为 list、hash 或 zset，且 size 超过 1MB 的条目。为什么是它们？因为这些复杂数据结构在网络传输时会被整体打包发送，无法像流媒体那样分片传输，极易成为同步过程中的“瓶颈”。
拆分大key必须避开的三个操作陷阱
意识到大key的危害后，下一步就是拆分。但这里坑不少，很多想当然的操作反而会雪上加霜。比如，有人直接用 HSCAN 加 HDEL，或者用 LRANGE 配合 LTRIM 来拆分，结果往往适得其反，给主从库带来更大压力。一次安全的拆分，必须满足几个硬性条件：不能产生长耗时命令、不能阻塞主线程、也不能制造海量的AOF写入。
具体要避开哪些陷阱呢？
- 切忌在主库上直接对一个大Hash执行
HGETALL。这个命令会一次性返回几十甚至上百MB的数据，很容易打满客户端输出缓冲区，直接触发client-output-buffer-limit限制导致连接断开。 - 禁止使用
RENAME或MOVE这类命令去操作大key。虽然它们是原子操作，但底层实现需要完整拷贝key的内存数据，其开销等同于一次大型写入操作，对同步链路极不友好。 - 不要简单地依赖
SCAN加DEL的方式来清理旧key。如果拆分逻辑没有完美同步到从库，极易导致主从数据不一致。而且，每一个DEL命令都会写入AOF并广播给从库，产生大量额外开销。
那么，正确的姿势是什么？通常的做法是：使用 HSCAN 分批读取大key的数据，同时构造新的、更细粒度的key名（例如 user:1001:profile:part1），接着用 HSET 将数据写入新key。在所有数据迁移完成后，再用一个 DEL 删除原始大key。这里还有个关键细节：所有相关的写操作，务必通过 pipeline 批量提交。这能显著减少网络往返次数，同时大幅降低AOF刷盘的频率，对主从同步更加友好。
从库同步阶段仍卡顿？检查 repl-backlog-size 和 client-output-buffer-limit
是不是拆分了所有大key，主从同步就能高枕无忧了？未必。如果从库网络延迟较高，或者因为其他原因频繁重连，仍然可能出问题。根源可能在于复制积压缓冲区（repl-backlog）大小不足。一旦积压的数据超过了缓冲区容量，主库就会丢弃部分复制偏移量，导致从库无法进行增量同步，只能再次请求全量RDB传输——如果RDB里还残留着未清理干净的大key，整个问题就又回到了原点。
因此，以下两个配置项的调优至关重要：
- 通过
CONFIG GET repl-backlog-size查看当前值。默认的1MB在大多数生产环境中都偏小。一个合理的建议是，将其设置为业务峰值期间预期增量数据量的2倍。例如，如果业务高峰每秒写入约5MB数据，那么将其设置为10MB会是一个更安全的选择。 - 检查并调整从库的
client-output-buffer-limit sla ve配置。默认值256mb 64mb 60意味着：当缓冲区达到256MB，或者60秒内平均每秒超过64MB时，连接就会断开。在大key传输期间，这个阈值很容易被触及。可以考虑在同步期间临时调高，例如设置为1024mb 128mb 120，为数据传输留出更多余量。
需要注意的是，这两个配置修改后，务必执行 CONFIG REWRITE 使其持久化。而且，client-output-buffer-limit 需要在主从实例上分别进行设置，因为它是各自独立生效的。
说到底，拆分大key只是解决问题的起点。要确保主从同步长期稳定，更深层的功夫在于对复制缓冲机制的理解。不少团队花了大力气拆分完key，却卡在从库重连后瞬间再次断开的问题上，往往就是因为忽略了 repl-backlog 这个“静默杀手”。
