大 key/热 key 排查
生产事故两大元凶：大 key 拖垮单点，热 key 打爆实例。面试主线：危害、怎么查、怎么治。
大 key
定义：单个 key 的 value 很大（如一个 hash 有百万字段、string 几十 MB），或集合元素很多。
危害：
| 危害 | 机制 |
|---|---|
| 阻塞实例 | GET/DEL 大 key 是慢命令，单线程下卡住所有请求 |
| 网络拥塞 | 一次读返回大 payload，带宽被打满 |
| 内存不均 | Cluster 下单节点内存被一个大 key 占满 |
| 迁移困难 | 扩容时大 key 迁移慢、占带宽 |
排查手段：
redis-cli --bigkeys：scan 采样扫描，报告最大的各类 key（不阻塞，但只能发现采样内的）MEMORY USAGE key：精确内存占用DEBUG OBJECT key：看编码和元素数
治理方案：
- 拆分：大 hash 按业务维度分片（
user:{id}:1/2/3），大 list 拆成多 key - 压缩：大 string 换压缩格式（如 gzip 后存）
- 异步删除：DEL 换 UNLINK（4.0+），后台线程回收，不阻塞
- 避免大集合操作：SMEMBERS 换 SSCAN 分批取
热 key
定义：单个 key 被超高频率访问（如秒杀商品、热搜词），单节点 CPU 打满。
危害：单点 CPU 饱和、缓存失效瞬间打爆数据库（热点击穿）、Cluster 下单节点成为瓶颈。
排查手段：
redis-cli --hotkeys：需要开启 LFU 策略（maxmemory-policy allkeys-lfu）才能统计MONITOR：实时看命令流，生产慎用（本身有性能开销）- 客户端侧统计：RedisTemplate 等客户端的请求计数
INFO keyspace配合OBJECT FREQ看单个 key 的访问频率
治理方案：
| 方案 | 做法 | 取舍 |
|---|---|---|
| 本地缓存 | 热点 key 在应用内存缓存一层 | 有本地一致性成本 |
| 多副本 | 同一 key 复制多份（key#1..N），读随机选 |
写要写多份，一致性复杂 |
| 读写分离 | 读走从库分散 | 有复制延迟 |
| 打散后缀 | 热 key 加随机后缀分布到多节点 | 查询要广播，适用场景有限 |
治理优先级
- 先发现：监控系统告警（慢命令、CPU、带宽）+ 定期 bigkeys/hotkeys 扫描
- 再治理：大 key 拆分加 UNLINK，热 key 按场景选本地缓存或副本
- 再防复发：代码规范（限制 value 大小、禁止大集合命令）、压测验证
面试追问
- 大 key 为什么危险？ 单线程下 GET/DEL 是慢命令，阻塞整个实例；还占带宽、拖慢迁移
- 怎么查大 key？ redis-cli –bigkeys 扫描（不阻塞但有采样误差），MEMORY USAGE 精确确认
- 大 key 怎么治？ 拆分、压缩、UNLINK 异步删。集合操作改分批（SSCAN）
- 热 key 怎么发现？ 开 LFU 后用 –hotkeys，或客户端统计。MONITOR 有开销慎用
- 热 key 怎么治？ 本地缓存、多副本、读写分离。写多读少的场景副本方案要考虑一致性问题