先说结论

热 Key 是请求集中在少数 Key，容易打满单分片 CPU 或网络；大 Key 是单个值包含过多元素或字节，可能造成慢命令、网络阻塞、迁移和删除抖动。两者可能重合，但诊断指标和治理方式不同。

发现要结合请求采样、分片负载、慢日志、内存分析和业务埋点，避免直接在生产全量扫描造成额外压力。

热 Key 治理

可使用本地缓存和请求合并降低 Redis 访问，按后缀复制多个只读副本分散请求，或在业务入口限流。写热点不能简单复制，要重新设计聚合方式或异步批量更新。

发现路径与安全工具

热 Key 需要从请求频率、单分片 CPU、网络带宽、慢命令和业务日志交叉判断。短时 MONITOR 会产生大量输出，不适合长期线上使用；可使用采样、客户端埋点、代理统计和 Redis 自身延迟监控。大 Key 可通过离线扫描、redis-cli --bigkeys 的抽样能力、MEMORY USAGE key 和慢日志定位，但在生产执行全量 KEYS * 会阻塞服务，应该避免。

信号 热 Key 更常见 大 Key 更常见
单 Key QPS 很高 未必高
单命令耗时 可能正常 集合遍历/删除常升高
网络出口 高 单响应包很大
内存占用 未必明显 单 Key 占用异常
迁移/复制 可能平稳 可能出现长尾和超时

热 Key 的分层治理

先判断能否减少读取：本地缓存适合允许短暂陈旧的数据，请求合并适合同一进程同一 Key 的并发 miss，CDN 适合公开静态内容。仍需访问 Redis 时，可以对只读热点建立多副本 Key：product:1:0 到 product:1:7，读请求按随机或一致规则分散，更新时写所有副本或发布失效事件。

多副本只能解决读热点；写热点如全局计数器会集中在一个键。可采用分片计数（多个子 Key 后聚合）、本地累计后批量上报、消息队列削峰或改变指标口径。必须接受读到稍旧计数，或使用专门的强一致存储。

大 Key 的拆分策略

不推荐：user:1001:all-orders -> 100 万元素 List
推荐：user:1001:orders:2026-07 -> 当月分桶
      user:1001:orders:2026-08 -> 下月分桶

集合可以按时间、哈希范围、业务子类型或分页游标拆分。每次读取限制元素数，SCAN/HSCAN/SSCAN/ZSCAN 以渐进方式遍历，而不是一次性取回。删除时使用 UNLINK 或分批删除，并评估复制、AOF 重写和持久化期间的额外压力。

热点与 Cluster 的关系

Cluster 通过槽把不同 Key 分散到不同节点，但单个 Key 只能落在一个槽，一个热 Key 仍会打满其主节点。使用 hash tag 将多个 Key 固定到同槽更会加剧局部热点，只有需要原子多键操作时才使用，并限制其数据规模。

处置步骤

  1. 确认具体 Key、命令类型、QPS、大小和所属节点，不要凭整体 CPU 猜测。
  2. 先用限流、缓存、读副本或临时扩容保护服务。
  3. 设计拆分或副本方案，双写/双读灰度切换。
  4. 验证热点是否均衡、命中率是否下降、数据是否一致。
  5. 增加 Key 大小、访问频率和过期策略的长期监控与告警。

大 Key 治理

按业务维度拆成多个 Key，集合按时间或哈希分桶，读取分页并限制单次返回。删除大集合优先异步释放或小批量渐进删除，同时监控复制和持久化影响。

容易踩坑的地方

Key 名称长不是大 Key 的核心，真正问题是值体积或元素数量。增加 Cluster 节点也不会自动拆散同一个 Key，它仍只属于一个槽和一个主节点。

常见问题

追问：如何定义大 Key 阈值？

没有统一数字，应根据网络带宽、延迟 SLO、持久化和迁移窗口制定，并分别限制字符串字节数与集合元素数量。

追问：为什么不能直接 DEL 一个几百 MB 的 Key？

释放复杂对象可能占用主线程很久，阻塞其他命令；还会造成复制和持久化尖峰。优先业务拆分，必要时使用异步释放或小批量渐进处理。

追问：本地缓存会带来什么风险？

不同实例的数据可能短暂不一致，发布失效消息丢失会延长陈旧时间，且每个实例占用内存。需要 TTL、版本、失效广播和容量上限。

追问：热点 Key 可以迁到专用节点吗？

可以作为隔离措施，但若该 Key 自身单线程命令或网络已成为瓶颈，专用节点只能隔离影响，不能无限提升单 Key 吞吐，仍需减少或分散访问。