S12-A02 · 热 Key 与大 Key 治理

适用读者：遇到"单分片被打爆"或"删一个大 key 卡住"的人。
前置：S12-A01、S12-B01。
覆盖旧文：881(111) 880(97) 2377(833) = 1,041 点。
覆盖扩展：E-S12-016（热 key 探测）。
上一篇：S12-A01 · 集群：主从、哨兵、Cluster 与脑裂
下一篇：S12-A03 · Key 设计与容量估算。

1. 一句话结论

大 key 伤"内存与阻塞"（删/读一次卡全局），热 key 伤"单分片"（流量集中）。两者都要探测，但治理手段完全不同。

问题	本质	后果	治理
大 key	单个 key 太大	删除/读取阻塞（单线程！）	拆分、`UNLINK`、异步删
热 key	单个 key 访问太集中	单分片 CPU/带宽打满	本地缓存、key 打散、读写分离

2. 大 key 的判定与治理

类型	阈值（经验）
string	> 10 KB
hash/list/set/zset	元素 > 5000 或总大小 > 1 MB

治理手段：

手段	说明
拆分	按业务维度拆成多个 key（注意别变成热 key）
`UNLINK` 替代 `DEL`	后台线程释放内存，不阻塞
`HSCAN`/`SSCAN` 分批	避免一次性拉全量
压缩/换结构	用更紧凑的编码（B02）

"DEL 大 key 为什么会卡"：单线程逐元素释放——实测的 Lua 阻塞 1441 ms 就是同类问题（B01）。

3. 热 key 的探测（E-S12-016）

手段	说明
`redis-cli --hotkeys`	需 `maxmemory-policy` 为 LFU
`MONITOR`	生产禁用（严重降性能）
客户端埋点	统计 key 访问频次（推荐）
代理层统计	如 Twemproxy/自研代理

判据："有没有 key 的 QPS 远高于平均？" 有 → 热 key。

4. 热 key 的治理

方案	说明	代价
本地缓存	进程内挡一层（Caffeine）	一致性（B05）
key 打散	`hotkey:1..N` 复制 N 份随机读	写要更新 N 份
读写分离	从库分担读	主从延迟
限流	保护性拒绝	影响业务

"打散 N 份"的注意点：读随机、写全量——否则读到的副本是旧值。

5. 大 key 与热 key 的交集

一个 key 既大又热是最糟的情况：拆分后会变成"N 个热 key"——必须同时做本地缓存。

6. 五个误区

误区	真相
"`DEL` 和 `UNLINK` 一样"	前者阻塞，后者异步
"热 key 只影响一个 key"	影响整个分片
"`MONITOR` 可以用来找热 key"	生产禁用
"拆分大 key 就完事"	可能造出热 key
"热 key 打散后写也随机"	写必须全量，否则脏

7. 自检（架构师版）

大 key 与热 key 的本质差异？
大 key 的四种治理手段？
热 key 的三种探测方式？
"key 打散"为什么写要全量？
为什么"又大又热"最糟？

8. 下一篇

S12-A03 · Key 设计与容量估算

治理讲完，最后一篇：key 怎么命名、内存怎么算、容量怎么规划。

本篇属于系列《S12 · Redis 与缓存》。旧文来源：A-881/880/2377；扩展点 E-S12-016。