0. 适用场景
线上 Redis 出现 RT 抖动、主从延迟升高、慢查询增加，怀疑存在大 Key。
本文给出一套可直接落地的排查与治理流程：**10 分钟止血 + 1 周治理**。
1. 什么是大 Key（可操作定义）
在工程上建议使用阈值定义，而不是"感觉很大"：
-
String：`MEMORY USAGE > 1MB` 视为大 Key
-
Hash/List/Set/ZSet：元素数 `> 10k` 视为高风险
-
单次读写超过 `256KB` 需重点关注
> 阈值可按业务调整，但要固定成团队规范。
2. 为什么大 Key 会拖垮系统
2.1 请求延迟上升
单次传输包体大，序列化/反序列化和网络耗时都会上升。
2.2 主从复制压力
大对象同步成本高，容易引发 replication lag。
2.3 持久化抖动
AOF 重写、RDB 快照期间会放大 IO 压力。
2.4 删除阻塞
对超大 Key 使用 `DEL`，可能阻塞主线程。
3. 线上排查（命令级）
3.1 快速扫描
```bash
redis-cli --bigkeys
```
用途：按类型给出疑似大 Key。
3.2 精确定位
```bash
MEMORY USAGE your:key
OBJECT ENCODING your:key
TYPE your:key
```
用途：看内存占用、编码方式、数据类型。
3.3 关联性能证据
```bash
SLOWLOG GET 128
INFO stats
INFO replication
```
重点看：慢查询、瞬时 ops、主从延迟。
4. 止血方案（当天可完成）
4.1 删除改为异步
```bash
UNLINK your:key
```
避免 `DEL` 直接阻塞。
4.2 热点读降级
-
对超大 value 增加本地缓存/只读副本
-
限制一次返回量（分页、游标）
4.3 临时限流
对触发大 Key 的接口做 QPS 限制，优先保核心链路。
5. 根治方案（结构级优化）
5.1 拆分策略
-
按时间分片：`user:feed:{uid}:{yyyyMMdd}`
-
按业务分片：`order:{id}:part:{n}`
5.2 数据结构改造
-
大 JSON String → Hash 分字段
-
超长 List → 分页拉取 + 截断策略
5.3 生命周期治理
-
强制 TTL
-
设置大 Key 告警（内存占用 + 元素数量）
-
每周离线巡检 `--bigkeys`
6. 风险与回滚
风险
-
拆分后代码兼容问题
-
双写期间数据不一致
回滚预案
-
保留旧 Key 读取兜底开关
-
双写一段观察期后再切流
-
出现异常可快速切回旧逻辑
7. 面试高频问答（可背）
**Q1：DEL 和 UNLINK 的区别？**
A：DEL 同步删除可能阻塞；UNLINK 异步回收更适合大 Key。
**Q2：为什么大 Key 会导致主从延迟？**
A：同步体积大 + 网络与重放成本高，导致从库追赶变慢。
**Q3：如何预防大 Key？**
A：分片设计 + 结构优化 + TTL + 监控告警 + 周期巡检。
8. 检查清单（发布后可直接执行）
-
\] \`--bigkeys\` 扫描已完成
-
\] 删除策略已切换为 UNLINK
-
\] 告警阈值已配置（大小/元素数/延迟）
如果你愿意，我下一篇可继续写：
**《Redis 热 Key 与大 Key 双维治理：监控指标、流量削峰与缓存拓扑》**。