热点Key与大Key治理
热点 key 和大 key 是 Redis 线上故障高发来源。热点 key 会打爆单分片或单实例，大 key 会造成网络、内存、删除、迁移和持久化压力。
# 1. 学习定位
| 维度 | 内容 |
|---|---|
| 难度层级 | 稳定性治理 |
| 核心目标 | 先会用，再理解机制，最后能做工程取舍和故障分析 |
| 学习方法 | 带着业务场景看命令、SQL、数据结构、日志和运行时指标 |
# 2. 核心地图
热点Key与大Key治理
├─ 热点 key
├─ 大 key
├─ 命令耗时
├─ 网络出口
├─ 分片倾斜
├─ 拆分
├─ 本地缓存
└─ 异步删除
# 3. 小章节深度讲解
下面把核心地图中的每个点拆开讲。每个小节都同时面向开发和运维：开发侧关注怎么设计、怎么写代码、怎么避免错误；运维侧关注怎么监控、怎么定位、怎么恢复。
# 3.1. 热点 key
# 是什么
热点 key 属于缓存稳定性问题。缓存不是简单加速层，它决定数据库回源压力、数据新鲜度、热点保护和故障降级。
# 开发人员怎么用
开发人员要为不同数据定义 TTL、随机抖动、空值缓存、热点重建和一致性策略。写库删缓存、延迟双删、binlog 订阅都要配合失败补偿。
# 运维人员怎么看
运维人员要监控命中率、过期速率、淘汰数量、热点 key、大 key、回源量和数据库压力。Redis 故障时要看数据库是否被缓存失效放大。
# 常见风险
常见风险是大量 key 同时过期或热点 key 硬过期，瞬间把所有请求打回数据库。缓存系统必须有保护数据库的设计。
# 3.2. 大 key
# 是什么
大 key 属于缓存稳定性问题。缓存不是简单加速层，它决定数据库回源压力、数据新鲜度、热点保护和故障降级。
# 开发人员怎么用
开发人员要为不同数据定义 TTL、随机抖动、空值缓存、热点重建和一致性策略。写库删缓存、延迟双删、binlog 订阅都要配合失败补偿。
# 运维人员怎么看
运维人员要监控命中率、过期速率、淘汰数量、热点 key、大 key、回源量和数据库压力。Redis 故障时要看数据库是否被缓存失效放大。
# 常见风险
常见风险是大量 key 同时过期或热点 key 硬过期，瞬间把所有请求打回数据库。缓存系统必须有保护数据库的设计。
# 3.3. 命令耗时
# 是什么
命令耗时 属于 Redis 命令执行与可编程能力。Redis 命令通常在主执行路径中串行完成，单个慢命令会影响后续所有请求。
# 开发人员怎么用
开发人员要控制命令复杂度、返回大小和批量规模。Lua 与 Functions 只适合短小原子逻辑，不适合承载复杂业务流程。
# 运维人员怎么看
运维人员要看 SLOWLOG、commandstats、latency monitor 和客户端缓冲区。危险命令要通过 ACL、代理或规范禁止进入主链路。
# 常见风险
常见风险是为了减少网络往返，把过多操作塞进一次 Pipeline 或脚本，结果主线程长时间不可服务。
# 3.4. 网络出口
# 是什么
网络出口 属于 Redis 事件循环和网络模型。Redis 能处理大量连接，是因为 IO 多路复用和短命令串行执行共同作用。
# 开发人员怎么用
开发人员要避免大响应、慢脚本、全量集合运算和无限阻塞读取。客户端超时、连接池和重试策略要与 Redis 延迟目标匹配。
# 运维人员怎么看
运维人员要关注 P99/P999 延迟、blocked_clients、客户端输入输出缓冲、网络吞吐和单核 CPU。平均延迟无法说明尖刺风险。
# 常见风险
常见风险是慢客户端消费响应太慢，输出缓冲不断增长，最终影响内存和事件循环。
# 3.5. 分片倾斜
# 是什么
分片倾斜 属于热点 key 与大 key 治理。它决定单实例、单分片、单槽或单 key 是否会成为整体系统瓶颈。
# 开发人员怎么用
开发人员要从模型上限制集合大小，必要时按时间、用户、业务维度拆分 key；超热点只读数据可加本地缓存或请求合并。
# 运维人员怎么看
运维人员要定期扫描 big key、hot key，观察单分片 QPS、网络出口、慢命令和删除耗时。删除大 key 应使用 UNLINK 或分批任务。
# 常见风险
常见风险是总 QPS 不高但某个 key 极热，Cluster 扩容后仍然落在一个槽，一个分片被持续打满。
# 3.6. 拆分
# 是什么
拆分 属于热点 key 与大 key 治理。它决定单实例、单分片、单槽或单 key 是否会成为整体系统瓶颈。
# 开发人员怎么用
开发人员要从模型上限制集合大小，必要时按时间、用户、业务维度拆分 key；超热点只读数据可加本地缓存或请求合并。
# 运维人员怎么看
运维人员要定期扫描 big key、hot key，观察单分片 QPS、网络出口、慢命令和删除耗时。删除大 key 应使用 UNLINK 或分批任务。
# 常见风险
常见风险是总 QPS 不高但某个 key 极热，Cluster 扩容后仍然落在一个槽，一个分片被持续打满。
# 3.7. 本地缓存
# 是什么
本地缓存 属于缓存稳定性问题。缓存不是简单加速层，它决定数据库回源压力、数据新鲜度、热点保护和故障降级。
# 开发人员怎么用
开发人员要为不同数据定义 TTL、随机抖动、空值缓存、热点重建和一致性策略。写库删缓存、延迟双删、binlog 订阅都要配合失败补偿。
# 运维人员怎么看
运维人员要监控命中率、过期速率、淘汰数量、热点 key、大 key、回源量和数据库压力。Redis 故障时要看数据库是否被缓存失效放大。
# 常见风险
常见风险是大量 key 同时过期或热点 key 硬过期，瞬间把所有请求打回数据库。缓存系统必须有保护数据库的设计。
# 3.8. 异步删除
# 是什么
异步删除 属于热点 key 与大 key 治理。它决定单实例、单分片、单槽或单 key 是否会成为整体系统瓶颈。
# 开发人员怎么用
开发人员要从模型上限制集合大小，必要时按时间、用户、业务维度拆分 key；超热点只读数据可加本地缓存或请求合并。
# 运维人员怎么看
运维人员要定期扫描 big key、hot key，观察单分片 QPS、网络出口、慢命令和删除耗时。删除大 key 应使用 UNLINK 或分批任务。
# 常见风险
常见风险是总 QPS 不高但某个 key 极热，Cluster 扩容后仍然落在一个槽，一个分片被持续打满。
# 3.9. 本篇学习实验
建议准备一个独立 Redis 实例，构造小 key、大 key、热点 key、过期 key 和慢命令，观察 INFO、SLOWLOG、LATENCY、内存变化和客户端超时。每个实验都要记录命令复杂度和返回数据量。
开发侧实验重点是理解数据结构和命令边界，运维侧实验重点是理解延迟、内存和复制如何变化。真正掌握本篇内容，应该能从延迟尖刺反推大 key、慢命令、持久化或网络问题。
# 4. 核心机制
- 热点 key 是访问集中在少数 key 上，Cluster 下即使总 QPS 不高，也可能打爆单槽或单分片。
- 大 key 是单个 key 内部元素过多或 value 过大，会放大命令复杂度和响应体积。
- 大 key 删除可能阻塞主线程，迁移和持久化时也会形成尖峰。
- 热点治理常用本地缓存、副本读、key 分片和请求合并。
# 5. 工程实践
- 建立定期 big key 扫描和热点 key 监控。
- 集合类 key 按业务维度分桶，例如按用户、日期、页码拆分。
- 超热点只读数据可加本地缓存或多级缓存。
- 删除大 key 使用
UNLINK、分批删除或后台任务。
# 6. 常见坑
- 一个排行榜 ZSet 无限增长，最终每次查询和备份都变慢。
- 热点 key 落在单个 Cluster 槽，扩容也无法自动分散。
- 直接 DEL 超大集合，Redis 延迟瞬间升高。
- 只看实例平均 QPS，不看 key 级别倾斜。
# 7. 专家视角
- 热点和大 key 的根源通常是业务模型，而不是 Redis 配置。
- 专家会在需求评审阶段就要求给集合容量和热点访问做上限设计。
- 治理大 key 要兼顾在线访问、删除、迁移、持久化和恢复全过程。
# 8. Tips 快问快答
Q：多大的 key 算大 key？
A：没有绝对值，要看 value 大小、元素数量、命令复杂度和业务延迟目标。
Q：Cluster 扩容能解决热点 key 吗？
A：不能解决单 key 热点，单 key 仍落在一个槽。
Q：大 key 怎么删？
A：优先异步删除或分批删除，避免主线程长时间阻塞。
# 9. 阶段小结
热点Key与大Key治理 的学习重点不是记住零散概念，而是把它放回真实系统：数据如何进入、如何存储、如何被查询、如何在并发下保持正确、如何在故障后恢复。掌握这些连接关系，才能从“会用”走向“能设计、能优化、能排障”。