大key导致主从复制卡顿，因单次同步包过大阻塞复制流；切片前需确认是否真需切、是否单key引发、业务是否允许语义变化；推荐字段数切片+字节兜底，命名带版本号和分片标识，写操作须统一封装。

大Key导致主从复制卡顿的典型现象

Redis集群里，一个 hash 或 zset 超过几MB，主节点写入后同步到从节点时，会明显拖慢 repl-backlog 消费速度；从节点日志里频繁出现 Timeout waiting for bulk response，甚至触发 REPL_TIMEOUT 断连。这不是网络问题，是单次同步包太大、阻塞了复制流。

• 主节点执行 BGSAVE 或 PSYNC 时，大Key序列化成 RDB 片段需大量 CPU 和内存，从节点解码也吃资源
• Redis 复制协议本身不支持分片传输，整个 value 必须一次发完，TCP 包可能被拆分，重传概率上升
• 集群模式下，如果大Key所在 slot 的主节点负载高，还可能影响其他 slot 的命令响应（尤其在单线程模型下）

应用层切片前必须确认的三个前提

不能一上来就切，先看是不是真需要切——很多所谓“大Key”其实是误判。

• 确认是否真的由单个 key 引发：用 redis-cli --bigkeys 扫描，重点关注 hash、list、zset 类型，别只盯着 string
• 检查客户端是否在循环 HSET 却没控制 hset 字段数，比如把用户所有订单塞进一个 user:123:orders hash，字段数上万
• 确认业务是否允许切片后读写语义变化：比如原逻辑依赖 HGETALL 原子性获取全部字段，切片后就得 MGET 多个 key，丢失原子性

切片策略选型：按字段数还是按字节大小？

按字段数切（如每 500 字段一个子 key）更可控，但前提是字段值大小均匀；按总字节切（如每个子 key ≤ 512KB）更稳妥，适合字段值差异大的场景。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 推荐用字段数切 + 字节兜底：比如 hash 每 400 字段切一分片，同时监控单个分片序列化后是否超 600KB（用 DEBUG OBJECT 查 serializedlength）
• 切片 key 命名要带版本号和分片标识，例如 user:123:orders:v2:shard_001，避免升级时新老逻辑混用
• 写操作必须走统一封装函数，比如 hash_sharded_set($key, $field, $value)，内部自动路由到对应分片，别让业务代码自己算 shard_id

上线后必须盯住的两个监控项

切片不是一劳永逸，后续增长仍可能让某个分片变大。

• 监控每个分片 key 的 hlen 和 DEBUG OBJECT <key></key> 返回的 serializedlength，设置告警阈值（如 hlen > 600 或 serializedlength > 700000）
• 主从复制延迟指标不能只看 slave_repl_offset 差值，要结合 redis-cli -r 1 -i 1 info replication | grep lag 实时采样，滞后突增往往发生在某个大分片首次同步时

切片逻辑一旦嵌入业务，后续再想改结构成本很高；最麻烦的不是怎么切，而是旧数据迁移时如何保证读写不乱序——尤其是边写边迁的场景，得靠写双份+读降级兜底，这部分容易被跳过。