系统架构设计师 · 高频练习

热点缓存失效时,怎样避免大量请求同时回源重建?

高级 单选题 第 1054 题 中等 系统架构设计师缓存击穿Singleflight请求合并热点Key
题目

促销开始时,一个访问量极高的商品详情缓存刚好过期。数千个请求同时发现缓存未命中并查询数据库,数据库负载瞬间升高。较合理的核心治理方式是()。

A 把缓存有效期改为1秒,让数据更快刷新
B 让同一热点Key只由一个请求负责回源重建,其他请求短暂等待或读取可接受的旧值,并给过期时间加入抖动
C 所有请求都绕过缓存直接访问数据库
D 关闭数据库连接池,让每个请求新建连接
题目类型:原创高频练习题 用途:用于帮助理解系统架构设计师相关考点和答案解析,不等同于官方真题。
正确答案
B
答案解析

Singleflight或请求合并把同一Key的并发回源压缩为一次加载。其他请求等待结果或在业务允许时读取短暂旧值;过期时间抖动还能避免大量Key同时失效。

选项分析

A

错误。更短TTL会让热点更频繁失效,可能加重回源压力。

B

正确。单加载者回源能抑制同一Key的并发重建,等待、旧值和抖动用于控制用户延迟与集中失效。

C

错误。完全绕过缓存会把持续流量直接压给数据库。

D

错误。频繁建连会增加数据库与应用开销,不能解决重复查询。

本题为什么容易错

缓存击穿和雪崩都可能表现为数据库突增。题眼是“一个极热Key刚好过期”;若是大量Key同一时间失效或缓存集群整体不可用,才更接近雪崩。

先看结论

简短答案

热点缓存失效时,怎样避免大量请求同时回源重建,正确答案是 B(让同一热点Key只由一个请求负责回源重建,其他请求短暂等待或读取可接受的旧值,并给过期时间加入抖动)。Singleflight或请求合并把同一Key的并发回源压缩为一次加载。其他请求等待结果或在业务允许时读取短暂旧值;过期时间抖动还能避免大量Key同时失效。

解析

易混淆概念对比表

概念本题判断区别要点记忆提示
把缓存有效期改为1秒,让数据更快刷新 本题干扰项 错误。更短TTL会让热点更频繁失效,可能加重回源压力。 看到该词不要急着选,先判断是否真正解决题干问题
让同一热点Key只由一个请求负责回源重建,其他请求短暂等待或读取可接受的旧值,并给过期时间加入抖动 本题正确答案 正确。单加载者回源能抑制同一Key的并发重建,等待、旧值和抖动用于控制用户延迟与集中失效。 看到题干核心场景时优先联想到它
所有请求都绕过缓存直接访问数据库 本题干扰项 错误。完全绕过缓存会把持续流量直接压给数据库。 看到该词不要急着选,先判断是否真正解决题干问题
关闭数据库连接池,让每个请求新建连接 本题干扰项 错误。频繁建连会增加数据库与应用开销,不能解决重复查询。 看到该词不要急着选,先判断是否真正解决题干问题
本题易混淆选项怎么区分
  • 把缓存有效期改为1秒,让数据更快刷新:错误。更短TTL会让热点更频繁失效,可能加重回源压力。
  • 所有请求都绕过缓存直接访问数据库:错误。完全绕过缓存会把持续流量直接压给数据库。
  • 关闭数据库连接池,让每个请求新建连接:错误。频繁建连会增加数据库与应用开销,不能解决重复查询。
复习

知识点详解

缓存击穿发生在高并发访问的已存在数据失效时。Singleflight、互斥重建或请求合并可以让同一Key在一个时间窗口内只执行一次后端加载。业务能容忍短暂旧数据时,可采用stale-while-revalidate降低等待;大量Key应使用随机化TTL避免集中到期。实现还要限制等待时间、处理加载失败并监控回源放大倍数。

备考速记

热点过期别让万人重建:一人回源,众人复用,TTL再错峰。

Singleflight 在热点Key场景中的作用

如果重建需要300毫秒,1万请求不做协调可能产生近1万次数据库查询;请求合并后,理想情况下只有一次回源,其余请求复用结果。节省的不是缓存空间,而是重复后端工作。

拓展

同类题怎么考

  • 根据热点Key失效场景选择请求合并。
  • 判断TTL抖动、旧值服务和互斥重建各自解决什么问题。
Singleflight 在系统架构设计师软考中的考法

看到“单个热点Key到期”先找互斥重建或请求合并;看到“不存在的ID”找空值缓存或布隆过滤;看到“大量Key一起到期”再考虑随机TTL和分批预热。

解题思路

先问数据存不存在:商品详情当然存在,只是热点缓存突然到期,所以不是穿透。再看压力从哪里来:不是一次查询慢,而是大家同时做同一件事。最有效的动作是把并发重建合并成一个加载者,其他请求等它把缓存写回。B 还补了旧值兜底和TTL抖动,边界最完整。

考点定位

缓存击穿的关键是“数据本来存在、单个热点Key失效、并发请求集中回源”。治理重点是协调重建,而不只是延长或缩短TTL。

易错提醒

  • 重建锁没有超时,加载者异常后其他请求永久等待。
  • 释放锁时不校验持有者标识,误删了后来请求新获得的锁。
  • 所有等待请求超时后再次一起回源,形成第二波洪峰。

备考提示

  • 先按数据存在性和失效范围区分穿透、击穿、雪崩。
  • 把热点重建过程画成一个加载者、多名等待者和一次缓存写回。

你可能还想了解

  • Singleflight如何防止缓存击穿?
  • 缓存击穿和缓存雪崩有什么区别?
  • 热点缓存重建失败时其他请求怎么办?

本文小结

热点Key失效时,应让一个请求负责回源重建,其他请求等待或读取可接受的旧值;TTL抖动还能减少集中失效。