01

60 秒回答模板

Redis 热点 key 要先发现再治理。发现可以看 Redis hotkeys、slowlog、命令统计、代理层访问计数、节点流量和业务日志。治理上读多的热点可以加本地缓存、读副本、多级缓存、key 拆分或多副本 key；过期重建要用互斥锁、请求合并、提前刷新和逻辑过期防止击穿。强一致数据不能盲目本地缓存，需要短 TTL、版本号、主动失效或只缓存可容忍旧值的数据，同时配合限流降级保护 Redis 和数据库。

考点 核心机制与工程取舍
难度 中高频面试题
回答目标 按定义、机制、场景讲清楚
02

深入解析

01

先识别热点类型

热 key 是访问频率或瞬时并发远高于其他 key，可能打满单个 Redis 分片、网络带宽或 CPU。它不同于大 key：热 key 的问题是请求集中，大 key 的问题是 value 太大、序列化和网络传输重。

02

观测来源要多层

Redis 自身可以用 hotkeys、slowlog、INFO、latency 事件和命令统计；代理层可以统计 key 维度 QPS；业务侧要能把具体活动、商品、榜单或配置 key 与流量峰值关联起来，避免只看到节点负载却不知道哪个 key 热。

03

读流量分散

可容忍短暂旧值时，优先用进程本地缓存或 CDN/边缘缓存承接热点读；Redis 层可以做读副本、客户端本地缓存、多副本 key、hash tag 拆分或按业务维度分片。拆分时要能合并结果，并避免把一致性复杂度转嫁给调用方。

04

重建过程要限流

热点 key 过期时，大量请求同时回源数据库会形成缓存击穿。常见做法是互斥重建、singleflight 请求合并、逻辑过期返回旧值并后台刷新、热点 key 提前续期，以及对回源和重建并发做限流。

05

一致性按业务分级

本地缓存和多副本会带来旧值风险。配置、榜单、商品详情这类可短暂旧读的数据可用短 TTL 或版本号；库存、账户、权限等强一致路径不能只靠缓存读写，要把数据库约束、事务或专门的库存服务放在主链路。

03

易错点

  • 把热 key 和大 key 混为一谈，导致治理手段不对。
  • 没有先定位具体 key，只笼统说 Redis 慢就扩容。
  • 本地缓存没有失效策略，导致用户长期读到旧数据。
  • 热点 key 统一过期，重建时所有请求同时回源数据库。
04

面试官追问

热 key 和缓存击穿是什么关系？

热 key 是访问集中；击穿是热点 key 失效后大量请求直接打到后端。热点不一定击穿，但热点 key 一旦同时过期，击穿风险最大。

本地缓存怎么失效？

常见方式是短 TTL、版本号校验、发布订阅失效、配置中心推送或只缓存可容忍旧值的数据。关键是承认本地缓存不是强一致存储。

热点 key 能不能靠扩容 Redis 解决？

如果所有请求集中到同一个 key，同一个分片仍是瓶颈，单纯加节点可能没有效果。要拆流量、加本地缓存、多副本 key 或调整数据模型。

怎么避免重建锁本身成为问题？

锁要有过期时间和唯一标识，重建逻辑要短；等待方可以读旧值或快速失败，不能让大量线程阻塞堆积。重建失败也要保留旧值或进入降级。