大Key问题与解决#

发现： redis-cli --bigkeys / MEMORY USAGE key

解决：

1. 拆分：Hash 分片 / List 分段
2. 压缩：序列化压缩
3. 删除：UNLINK（异步删除，不阻塞）

预防： 设计时控制 Value 大小和集合元素数量

大 Key 是指单个 Key 的 Value 过大，通常 String 超过 10KB 或集合类型超过 5000 个元素就算大 Key。大 Key 的危害主要有两方面：一是操作耗时长会阻塞 Redis 单线程，导致其他请求排队超时；二是在 Cluster 架构下造成数据倾斜，某个节点内存和流量远高于其他节点。发现大 Key 可以用 redis-cli —bigkeys 扫描或者对单个 Key 执行 MEMORY USAGE 查看实际内存占用。解决方案有三种：拆分是最根本的，比如大 Hash 按字段分片成多个小 Hash，大 List 按范围分段；压缩是在序列化时用 snappy 或 gzip 减小体积；删除大 Key 一定要用 UNLINK 而不是 DEL，UNLINK 是异步删除不阻塞主线程，DEL 同步删除大 Key 可能导致几秒的阻塞。预防上从设计阶段就要控制 Value 大小和集合元素数量。

追问方向：

• “大 Key 对 Cluster 影响？”→ 大 Key 固定在一个 slot 上，导致该节点内存和流量远高于其他节点（数据倾斜）；操作大 Key 阻塞主线程影响该节点上所有 slot 的请求，迁移 slot 时大 Key 也会拖慢迁移速度
• “UNLINK 和 DEL 区别？”→ DEL 同步删除，大 Key（如百万元素的 Hash）删除时阻塞主线程可能长达数秒；UNLINK 是 Redis 4.0+ 的异步删除命令，主线程仅解除 key 引用，实际内存回收由后台线程完成不阻塞
• “怎么预防大 Key？”→ 设计阶段限制 value 大小（String 控制在 10KB 以内）和集合元素数量（不超过 5000）；业务上大集合按 Hash 分片存储；上线前 CR 检查 Redis 操作，定期用 —bigkeys 扫描巡检

易错点：

• ❌ 用 DEL 删大 Key——会阻塞，应用 UNLINK
• ❌ scan 出大 Key 就删——需评估影响