Redis 中的 Big Key 问题是什么？如何解决？

Redis BigKey大Key问题（面试结构化）

什么是BigKey

大Key指key对应的value体积过大或者元素数量过多。

• String类型：value字符串很大，几十MB以上；
• 集合类型 list/hash/set/zset：元素数量几十万、上百万。

注意：不是key的名字长，是存的数据大。

BigKey带来的危害

如何发现BigKey

解决方案

1. 拆分大key（最核心方案）

• String大字符串：拆成多个小key，user:info:1000 → user:info:1000:0、user:info:1000:1，业务侧拼接。
• Hash：把大hash拆分为多个小hash；
• List/zset/set：分片拆分，把元素分散到多个集合key。

集群环境下拆分同时还能解决热点key，流量分散到不同节点。

2. 渐进式删除，不要直接del

直接del一个几十万元素的大集合，会阻塞主线程。

• 使用unlink：非阻塞删除，把内存回收放到后台线程执行（Redis4.0+支持，优先用unlink代替del）。
• 集合类型：使用hscan、sscan、zscan分批迭代，循环批量删除元素，逐步清理，避免一次性操作。

3. 业务层面改造，避免存大value

• 不要把完整大对象、大json全部塞到Redis；把大的数据放数据库，Redis只存索引、高频字段。
• 避免存储超大list，list适合队列，不要累积几十万条数据不清理。

4. 控制集合上限

业务代码限制集合最大元素数量，超过阈值就做归档，把旧数据落库，不在Redis一直堆。

5. 优化网络

大key不要一次性全量读取，使用hscan、zrange分批读取，不要一次性把全部数据拉到应用。

面试区分：BigKey vs HotKey

• BigKey：数据体积大，操作耗时、网络压力大；访问量不一定高。
• HotKey：访问QPS极高，数据不一定大；流量集中在某个key。

两者可以同时出现：既是大key又是热点key，故障会被放大。

总结