大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 显示 slave0:ip=..., state=online 突然变成 state=offline；从库日志里反复出现 Connection with master lost，紧接着 Resyncing from master —— 这说明复制链路被强制重连，而重连失败或频繁重试往往源于单次传输数据过大。
用redis-rdb-tools快速定位大key
redis-rdb-tools 是目前最轻量、最准的离线RDB分析工具，不依赖Redis运行时，直接解析RDB文件即可统计key大小（含value序列化后长度）。注意它统计的是「序列化后体积」，比 MEMORY USAGE 更贴近网络传输实际开销：
- 先用
redis-cli --rdb /tmp/dump.rdb从主库生成当前RDB（确保停写或使用SAVE同步阻塞方式） - 运行
rdb -c memory /tmp/dump.rdb > memory.csv，输出按内存占用降序排列的key列表 - 重点关注
type=list/type=hash/type=zset中 size > 1MB 的条目——这类结构体在网络传输阶段会被整体打包发送，无法流式分片
拆分大key必须避开的三个操作陷阱
很多人想当然地用 HSCAN + HDEL 或 LRANGE + LTRIM 拆分，结果反而加剧主从压力。真正安全的拆分必须满足：不产生长耗时命令、不阻塞主线程、不制造大量AOF写入：
- 避免在主库上直接
HGETALL大 hash —— 单次返回几十MB会打满客户端缓冲区，触发client-output-buffer-limit断连 - 禁止用
RENAME或MOVE操作大key —— 这些是原子命令但底层仍需完整拷贝内存，等效于一次大写入 - 不要依赖
SCAN配合DEL清理旧key —— 若拆分逻辑未同步到从库，会导致主从数据不一致，且DEL本身会写AOF并广播给从库
正确做法是：用 HSCAN 分批读，构造新key名（如 user:1001:profile:part1），用 HSET 写入，最后用 DEL 删除原key —— 且所有写操作必须走 pipeline 批量提交，减少网络往返和AOF刷盘频次。
从库同步阶段仍卡顿？检查 repl-backlog-size 和 client-output-buffer-limit
即使拆分了大key，若从库网络延迟高或重连频繁，仍可能因复制积压缓冲区（repl-backlog）不足导致全量重同步。这时 repl-backlog-size 设置过小（默认1MB）会让主库丢弃部分复制偏移，从库只能请求全量RDB —— 而RDB里若还残留未清理完的大key，就又回到原点。
- 通过
CONFIG GET repl-backlog-size查看当前值，建议设为最大预期增量数据的2倍（例如业务峰值每秒写入5MB，则设为10MB） - 检查从库的
client-output-buffer-limit slave，默认是256mb 64mb 60，即缓冲区达256MB或60秒内未消费满64MB就断连；大key传输期间极易触达该阈值，应临时调高（如1024mb 128mb 120） - 这两个配置修改后需
CONFIG REWRITE持久化，且必须主从分别设置 —— 从库的client-output-buffer-limit是独立生效的
拆分大key只是起点，真正的稳定取决于对复制缓冲机制的理解深度。很多团队花几天拆完了key，却卡在重连后瞬间断开，往往就是漏看了 repl-backlog 这个静默杀手。
