缓存击穿风险取决于key的qps与失效窗口并发数是否超过数据库承载阈值，需通过失效冲击测试验证；高风险key包括开关、规则、限流等影响主流程的配置类数据；应监控“失效后首次加载耗时”，并根据数据时效性选择分布式锁或定时刷新方案。
缓存击穿风险和业务QPS强相关
缓存击穿不是“有没有”的问题，而是“扛不扛得住”的问题。核心判断依据是：该 key 的每秒请求数（QPS） × 失效窗口内并发数是否超过数据库单点承载阈值。比如一个商品详情页，日常 QPS 是 800，峰值能到 3500；如果 product:12345 设置了固定 EXPIRE 3600，又没做保护，0 点整过期那一刻，所有请求直接打库——哪怕只有 200 个并发同时抵达，MySQL 单表查主键也容易触发慢查询告警。
关键不是看“是不是热点”，而是看“失效瞬间有没有能力兜住”。建议用线上真实流量压测工具（如 redis-benchmark + 模拟 key 过期）跑一次“失效冲击测试”，观察数据库连接数、CPU、慢日志突增情况。
业务语义决定风险权重：读多写少 ≠ 低风险
有些业务看似“只读”，但实际风险极高。比如风控规则配置、权限白名单、灰度开关等 key，它们更新频率极低（可能一周一更），但一旦过期，所有鉴权/放行请求都会 fallback 到数据库查全量规则表——这种场景下，哪怕 QPS 只有 50，也可能因 SQL 复杂度高、无索引或锁表导致雪崩式延迟。
以下几类 key 要重点标红评估：
-
feature:switch:*类开关控制 key -
rule:antifraud:*类策略规则 key -
config:rate_limit:*类限流参数 key - 任何在
if判断分支中被高频读取、且影响主流程通路的 key
不能只看 Redis 命中率，要盯住“失效后首次加载耗时”
很多团队监控只看 keyspace_hits / (keyspace_hits + keyspace_misses)，但这掩盖了击穿本质。真正危险的是：缓存 miss 后，从 DB 加载 + 回填 Redis 这一整条链路的 P99 耗时。如果这个耗时 > 300ms，而下游服务超时设置是 500ms，那大概率出现级联超时。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
实操建议：
- 在加载逻辑里埋点，统计
loadFromDBAndSetCache方法的执行时间分布 - 检查 DB 查询是否走了索引、是否加了
FOR UPDATE或其他阻塞操作 - 确认回填 Redis 是否用了 pipeline 或原子命令（避免
GET+SET中间被中断）
定时刷新 vs 分布式锁：选型要看数据变更粒度
如果业务要求“数据必须最新”，比如实时报价、库存余量，就不能靠“永不过期+后台刷新”，因为刷新间隔内存在脏读。这时候必须用互斥锁方案，但要注意：SETNX + EXPIRE 非原子，得换 SET key value EX 30 NX；锁超时时间必须大于 DB 查询最大耗时，否则可能多个线程同时加载。
反过来，如果数据允许分钟级延迟（如用户画像标签），用定时任务提前 2 分钟刷新 user:profile:* 更轻量，也避免锁竞争。但要注意任务失败重试机制，别让刷新断档。
最容易被忽略的一点：锁 key 的命名必须带业务上下文，比如用 lock:cache:product:12345 而不是笼统的 lock:product，否则不同商品会互相阻塞。
