一、什么是大 Key
谈及大Key，首先需要明确其判定标准。实际上，评估维度非常清晰，主要从以下两个方面来看：
- 数据体积庞大：字符串类型的 value 超过 10KB；集合类（如 List、Hash、Set、ZSet）的元素总量超过 1 万个，或者总大小超过 100KB。
- 操作耗时显著：单次命令需要遍历大量元素，导致主线程被长时间阻塞，无法响应其他请求。
只要满足上述任意一种情况，即可认定为大Key。
常见的大 Key 类型
- String：包含超大文本、序列化后的完整对象、整表缓存数据。
- Hash：单个哈希结构中存储了上万条业务记录，例如将用户的所有标签信息集中存放。
- List：消息队列中积压了数十万条尚未消费的数据。
- ZSet：排行榜一次性存储了全部用户数据。
二、大 Key 带来的致命问题
Redis 采用单线程模型执行命令，所有操作均为串行排队。当大Key出现时，主线程会被卡住，进而引发一系列严重后果：
- 命令阻塞，引发服务雪崩。删除大型 Hash 或 List，或执行
hgetall、lrange 0 -1、zrange 0 -1等命令，会一次性遍历数万乃至数十万个元素，瞬间打满 CPU 资源，后续所有读写请求都需排队等待超时。 - 内存瞬间抖动，触发 OOM（内存溢出）。删除大Key时，Redis 需要一次性回收大量内存，内存分配器可能因此卡顿。若开启了持久化功能，RDB 或 AOF 重写时还需拷贝大Key，导致内存占用翻倍，容器或服务器直接因内存溢出而宕机。
- 集群槽位迁移卡死。Redis Cluster 在迁移 slot 时，会完整拷贝 key 数据。大Key迁移耗时可能长达数十秒，导致集群迁移超时失败，槽位状态变得不稳定。
- 网络流量突增。客户端一次性读取超大 value 时，会瞬间打满网卡带宽，其他正常请求因带宽被挤占而受到影响。
三、如何定位大 Key
定位大Key有多种常用方法，线上扫描与离线分析各有其适用场景与优劣。
1. 线上在线扫描（不阻塞，推荐使用）
Redis 4.0 及以上版本内置了 --bigkeys 命令，该命令采用分批次扫描方式，不会阻塞主线程：
# 扫描整个数据库，输出大key信息 redis-cli --bigkeys
输出结果会区分 String、List、Hash、ZSet 等类型，并给出每种类型中最大的 key、元素数量以及占用空间。
2. 精准扫描指定库或筛选 key 前缀
# 选择数据库db1，匹配以user开头的key，进行分段扫描 redis-cli -n 1 --bigkeys --pattern "user*"
3. 离线 RDB 分析（超大集群建议避免线上扫描）
使用 rdb-tools 工具解析 RDB 文件，可以导出所有 key 的大小报表，这是生产环境集群的首选方案。
4. 监控实时识别
重点关注以下几个指标：
- 慢查询日志（slowlog）：若出现大量耗时超过 100ms 的命令，大概率是在操作大Key。
- Redis 内存监控：内存出现毛刺式的上涨或下跌，表明存在大规模内存回收现象。
- 集群迁移 slot 耗时指标：迁移耗时突然飙升，背后往往是因为某个大Key拖慢了速度。
四、大 Key 优化方案（分场景讨论）
场景 1：String 大 key（超长字符串）
问题：缓存了全量对象、大文本或完整列表数据，导致 value 体积过大。
优化 1：分片拆分（推荐）
将单个大 key 拆分成多个小 key。例如，存储 id=1000 的用户详情：
# 原大key（应避免使用）
user_info:1000 = {id:1000,name:xx,addr:xx,tag:[...]}
# 拆分为多个小String
user_info:1000:name = 张三
user_info:1000:addr = 北京市xxx
# 列表标签单独使用Hash存储
user_tag:1000 hash
优化 2：压缩序列化
使用 Snappy 或 Gzip 对 value 进行压缩，能显著降低体积；同时应避免使用 Java 原生序列化（其体积较大），改用 Protostuff 或对 JSON 进行压缩。
优化 3：分页存储，避免缓存全量数据
列表数据不要一次性全部存入，应按照分页 key 进行存储，例如 goods_list:page1、goods_list:page2。
场景 2：Hash 大 key（最常见的业务陷阱）
问题：单个 Hash 中存储了上万条 field，执行 hgetall 命令会直接导致阻塞。
方案 1：Hash 分片
原 key product:info 存储了十万条商品信息，可以将其拆分成 N 个 hash：
product:info:0 product:info:1 # 分片规则：商品id % 10
每个 Hash 只包含几千条 field，执行 hgetall 命令时毫无压力。
方案 2：禁止使用 hgetall，改用 hscan 迭代遍历
业务代码中绝对不要全量读取 Hash，应使用游标分批拉取，以避免阻塞 Redis：
# 从游标0开始，每次取100条 hscan product:info 0 count 100
方案 3：冷热数据分离
将高频访问的字段单独拆分到小 Hash 中，低频访问的大字段则存入独立的 key。
场景 3：List 大 key（消息队列堆积）
问题：生产者速度远大于消费者，导致 List 中堆积数十万条数据，执行 lrange 0 -1 或批量删除操作都会造成阻塞。
优化 1：分片队列
将单个 List 拆分成多个 List，生产者轮询写入，多个消费者并行消费，从而分散数据量：
msg_queue:0 msg_queue:1 msg_queue:2
优化 2：限制队列长度，设置丢弃策略
在业务允许的前提下，当队列超过设定阈值时，丢弃旧数据，避免无限堆积。
优化 3：改用专业队列（Redis Stream）
Stream 支持消费组、ack 确认等机制，不会出现 List 堆积后大量删除导致阻塞的问题，是替代 List 作为消息队列的更优选择。
场景 4：ZSet/Set 大 key（排行榜、标签集合）
- 排行榜分片：按区间拆分成多个 ZSet（例如 0-1000、1000-2000）。
- 禁止使用
zrange 0 -1全量拉取数据，改用zrange start end进行分页查询。 - 对于超大标签集合，拆分成多个 Set，进行交集运算时由客户端合并结果。
五、大 Key 安全删除方案（至关重要）
直接使用 del big_key 会阻塞主线程，必须采用安全方式。分两种情况处理：
1. 集合类大 key（Hash/List/Set/ZSet）：分段删除
循环分批删除少量元素，每次操作耗时极短，不会造成阻塞：
# Hash分批删除field hscan big_hash 0 count 100 hdel big_hash field1 field2 ... # List从尾部批量弹出 lpop big_list 50
2. String 超大 key：异步非阻塞删除（Redis 6+）
使用 unlink 替代 del：
del：同步删除，立即释放内存，会阻塞主线程。unlink：异步删除，主线程仅标记 key 为已删除，由后台子线程回收内存，无阻塞问题。
unlink big_string_key六、线上预防规范（开发约束）
- 编码规范：
- 禁止单个 Hash 或 List 存储超过 1000 条元素。
- 禁止使用
hgetall/lrange 0 -1/zrange 0 -1进行全量读取。 - 对于列表、排行榜等数据，强制采用分页存储、分页查询的方式。
- 监控告警：
- 定时执行
--bigkeys脚本，当超过阈值时触发告警。 - 持续监控慢查询日志，捕获大 Key 导致的耗时命令。
- 定时执行
- 集群规范：在 Redis Cluster 环境下，应严格规避大 Key，因为迁移 slot 极易引发集群故障；分片才是集群场景下的最优解。
- 过期策略：大 Key 不宜设置统一的过期时间，应打散过期时间点，避免大批量同时过期导致内存雪崩。
七、补充：大 Key 与热 Key 的区别
很多人容易混淆这两个概念，实际上它们完全不同：
- 大 Key：指数据体积大，主要问题是阻塞、内存占用及迁移卡顿。
- 热 Key：指访问 QPS 极高（每秒数万次请求），主要问题是 CPU 负载、缓存击穿以及集群流量倾斜。
两者的优化方案也完全独立，需要分别进行处理。
