Redis 大 Key 问题排查与治理：原因、危害、实战方案
1. 什么是大 Key？
大 Key 没有绝对统一标准，一般从两个维度判断：
-
**字符串类型**：value 体积过大（如 > 1MB）
-
**集合类型**：元素数量过多（如 > 1万 或 10万）
常见示例：
-
一个 String 里塞了超大 JSON
-
一个 Hash/List/Set/ZSet 挂了几十万条数据
2. 大 Key 的核心危害
-
**网络与延迟抖动**：单次读写数据包大，RT 飙升
-
**阻塞风险**：删除大 Key（尤其 DEL）可能阻塞线程
-
**复制与持久化压力**：主从同步、AOF 重写、RDB 变慢
-
**内存碎片与淘汰异常**：影响整体命中率和稳定性
3. 如何快速发现大 Key
3.1 线上快速扫描（推荐低峰期执行）
```bash
redis-cli --bigkeys
```
它会按类型统计并给出可能的大 Key。
3.2 精准看单个 Key 大小
```bash
MEMORY USAGE your:key
```
3.3 观察慢查询与延迟
-
`SLOWLOG GET`
-
监控 Redis 响应时间、网络流量、主从延迟
4. 治理方案（可直接落地）
4.1 拆分 Key（首选）
把单个超大对象拆成多个小 Key：
-
按时间分片：user:feed:2026-03-23
-
按业务分片：order:detail:{orderId}:part1/part2
4.2 结构优化
-
大 JSON 不要整包写入 String，改 Hash 分字段
-
长列表按分页/游标读写，避免一次全量拉取
4.3 删除策略
-
避免直接 `DEL` 超大 Key
-
优先 `UNLINK`（异步回收，降低阻塞）
4.4 生命周期治理
-
设置合理 TTL，防止冷数据长期堆积
-
对"可能膨胀"的 Key 做阈值告警
5. 面试高频问答（可背）
**Q：DEL 和 UNLINK 区别？**
A：DEL 同步删除，可能阻塞；UNLINK 异步回收，更适合大 Key。
**Q：为什么大 Key 会拖慢主从复制？**
A：大对象传输与重放成本高，网络和磁盘压力增大，导致复制延迟。
**Q：如何避免大 Key 产生？**
A：设计阶段做分片、字段化、分页化，并设置 TTL + 监控阈值。
6. 一句话总结
**大 Key 本质是"单次操作的数据粒度过大"。治理核心是：发现、拆分、异步删除、生命周期管理。**