做后端项目尤其是把黑马点评这种完整商城项目放进简历的同学大概率都在 Redis 缓存上栽过跟头。缓存穿透、缓存击穿这两个词面试官几乎必问理论背得再熟落到代码层面很多人是懵的。真正把这两个问题落地解决的是黑马点评项目里那个CacheClient工具类——queryWithPassThrough解决穿透queryWithMutex和queryWithLogicalExpire解决击穿。代码不长但信息量极大。这篇文章就专门拆它工具类为什么这么设计、每个方法逐行怎么走、有哪些易踩的坑以及面试官追问时该怎么答。适合正在做黑马点评项目的 Java 后端学习者也适合所有想把手里的缓存代码升级成“能讲出设计思路”的人。1. 先搞清楚三兄弟穿透、击穿、雪崩到底差在哪1.1 一个查询商铺接口三种崩溃姿势黑马点评里有一个很典型的接口根据 id 查询商铺详情。商铺表就是普通 MySQL 单表几千条数据查询本身不慢但如果有一天运营在首页推了一个活动瞬间几万个请求同时过来没有缓存的话数据库 QPS 会直接被打满。这就是为什么要给这个普通查询加一层 Redis。但加了缓存以后问题并没有彻底结束而是从“一次查询打 DB”变成“什么情况下还会打 DB”缓存穿透查询一个数据库中根本不存在的 id。比如有人写脚本连续请求id99999999、id99999998每次 Redis 都查不到于是每次都落到底层数据库。DB 查不到就返回空但请求本身已经把数据库查询链路打满了。攻击者甚至不用并发很高持续的小流量就能让一个应用“看起来没死但数据库已经在崩溃边缘”。缓存击穿某个非常热的 key比如主力商铺id1在缓存过期的那一瞬间大量请求同时发现缓存没命中于是同时涌向数据库去重建缓存。注意它不是一直打 DB而是集中在过期后那一小段时间属于热点 key 的失效问题。缓存雪崩大量 key 在同一时间段集体失效比如设置了相同的固定 TTL缓存一下子空了一大片请求全部落到 DB形成大规模打垮。它和击穿的区别在于击穿是单点失效雪崩是面状失效。一句话总结穿透是“查了个不存在的东西”击穿是“一个热点 key 过期瞬间”雪崩是“一批 key 同时过期”。查缓存查不出结果来是穿透查一个热点 key 时正好过期是击穿查一百个 key 时恰好一起过期是雪崩。缓存问题触发场景核心特征典型后果缓存穿透查询不存在的 key每次请求都穿透缓存数据库持续承受无效查询缓存击穿单个热点 key 过期瞬间大量请求集中在到期瞬间数据库瞬时 QPS 冲顶缓存雪崩一批 key 同时过期缓存大面积失效数据库整体被打垮黑马点评把前两个作为重点原因很简单穿透和击穿是“一个查询接口”上最容易复现、最容易演示、也最常被面试官拿出来追问的场景。雪崩更多靠部署层面解决比如给 key 的过期时间加随机数、做集群和哨兵单靠一个工具类解决不了。1.2 CacheClient 在项目里的定位如果你打开黑马点评的代码仓库会发现com.hmdp.utils包下面有一个CacheClient类它没有继承任何父类、没有实现任何接口就是一个手工封装出来的缓存工具类。它的定位非常清楚把所有和 Redis 缓存读写相关的逻辑从 Service 层抽离出来让业务代码只关心“查数据”和“回写数据”这两件事。在它出现之前Service 里最常见的写法是查缓存、判断命中、查数据库、回写缓存、处理各种分支全部堆在业务方法里。一个项目里如果要查询商铺、查询商品、查询用户同样的“先查 Redis没命中再查 DB回填缓存”逻辑就要复制三份。任何一处修改都要改三个地方漏一个就出问题。CacheClient 干的事情就是把“查缓存→回填缓存→处理穿透/击穿”这个通用流程抽象出来通过泛型和函数式回调把“具体查哪个表”留给调用方去填。这种封装思路比背几个缓存方案更值得学——它本质上是一个模板方法模式 函数式接口的工程应用。2. 工具类的骨架设计为什么选 StringRedisTemplate 函数式回调2.1 字段设计与构造器先看这个类的基础结构按黑马点评课程里常见写法还原public class CacheClient { private final StringRedisTemplate stringRedisTemplate; // 缓存 key 前缀例如 cache:shop: id private static final String CACHE_SHOP_KEY cache:shop:; // 互斥锁 key 前缀用于缓存击穿处理 private static final String LOCK_SHOP_KEY lock:shop:; // 缓存空值的 TTL2 分钟 private static final Long CACHE_NULL_TTL 2L; private static final TimeUnit CACHE_NULL_TTL_UNIT TimeUnit.MINUTES; // 正常数据的 TTL30 分钟 private static final Long CACHE_SHOP_TTL 30L; private static final TimeUnit CACHE_SHOP_TTL_UNIT TimeUnit.MINUTES; // 重建缓存用的线程池 private static final ExecutorService CACHE_REBUILD_EXECUTOR Executors.newFixedThreadPool(10); public CacheClient(StringRedisTemplate stringRedisTemplate) { this.stringRedisTemplate stringRedisTemplate; } }这里最容易被忽略的一个点为什么是StringRedisTemplate而不是普通的RedisTemplate我刚开始做项目时用的默认 RedisTemplate打开可视化客户端一看key 是一串\xAC\xED\x00\x05t\x00开头的乱码value 也是一堆二进制序列化内容根本没法直接读。这就是JDK 默认序列化的锅没有指定序列化器时RedisTemplate 使用 JdkSerializationRedisSerializer把对象序列化成二进制后再存进去。黑马点评里用 StringRedisTemplate 的原因很简单key 和 value 全部按字符串存字符串的序列化器默认就是 UTF-8。存的是cache:shop:1这种肉眼可读的 keyvalue 是 JSON 字符串。这样在可视化工具里能直接看到数据排查问题时也能一眼看出缓存里到底有什么不用再猜。代价自然是“值”的类型信息丢了所以读到 JSON 后需要通过ClassR来反序列化成目标对象这也是后面方法签名里会有ClassR type参数的原因。2.2 泛型 Function 回调的设计意图CacheClient 的方法签名看起来有点吓人其实拆开很清晰public R, ID R queryWithPassThrough( String keyPrefix, ID id, ClassR type, FunctionID, R dbFallback, Long time, TimeUnit unit)四个参数分别解决四个问题keyPrefix缓存 key 的前缀调用方传cache:shop:就是商铺缓存传cache:user:就是用户缓存。id业务主键泛型 ID 意味着不一定是 Long字符串主键也能用。typeClass 对象用来把 JSON 反序列化成目标类型。dbFallback一个FunctionID, R函数式接口入参是 id返回值是 DB 查询结果。调用方只需传id - shopMapper.selectById(id)工具类完全不关心底层是 MyBatis 还是 JPA。这么设计最大的好处是复用性。同一个 CacheClient无论以后要缓存商铺、缓存商品还是缓存用户调用方式完全一致。项目中查询商铺的实际调用大概是这样的Shop shop cacheClient.queryWithPassThrough( CACHE_SHOP_KEY, id, Shop.class, shopId - shopMapper.selectById(shopId), CACHE_SHOP_TTL, CACHE_SHOP_TTL_UNIT);注意shopId - shopMapper.selectById(shopId)这一行它就是“数据库查询策略”由调用方注入。工具类里不会出现ShopMapper、不会出现UserMapper没有任何具体业务类的依赖。这就是函数式接口在工程里的实际价值把“流程”和“具体业务”解耦。3. 缓存穿透解法queryWithPassThrough 逐行拆解3.1 缓存空值方案完整代码先看全貌我用课程里最常见的版本public R, ID R queryWithPassThrough(String keyPrefix, ID id, ClassR type, FunctionID, R dbFallback, Long time, TimeUnit unit) { // 1. 拼接缓存 key String key keyPrefix id; // 2. 查 Redis String json stringRedisTemplate.opsForValue().get(key); // 3. 命中缓存且值非空直接返回 if (StrUtil.isNotBlank(json)) { return JSONUtil.toBean(json, type); } // 4. 命中的是空值说明数据库里也没有返回空 if (json ! null) { return null; } // 5. 缓存未命中查数据库 R r dbFallback.apply(id); // 6. 数据库也查不到写入空值占位TTL 要短 if (r null) { stringRedisTemplate.opsForValue().set(key, , CACHE_NULL_TTL, CACHE_NULL_TTL_UNIT); return null; } // 7. 数据库存在写入缓存正常 TTL stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(r), time, unit); return r; }这段代码解决缓存穿透的核心思路就是一句话查不到的数据也往缓存里写一个占位符下次再来查直接在缓存层返回空不再打到数据库。整个过程走一遍第一个请求查id999Redis 没有DB 也没有于是往 Redis 里写一个空字符串TTL 设为 2 分钟然后返回 null。第二个请求再查id999Redis 能取到。此时StrUtil.isNotBlank()是 false所以不会进入第 3 步的命中分支但json ! null为 true于是走进第 4 步直接返回 null。关键点在于从这一步开始每一个对空 key 的请求都止步于 Redis不会再碰到 MySQL。注意第 2 步和第 4 步的区别Redis 里“没有这个 key”返回的是 null而“有这个 key 但 value 是空字符串”返回的是。这正是空值占位方案能成立的根本json null表示“没缓存过”json ! null表示“缓存命中过但缓存的内容是空”。三个分支有值、空值、没缓存通过StrUtil.isNotBlank和json ! null两个判断就能完整区分开。注意写入空值的时候Redis 里存的虽然是空字符串但它依然是一个真实的 key。所以这个方案的本质是用 Redis 的少量内存挡住对无效 key 的重复 DB 查询。3.2 空值为什么要设 2 分钟短 TTL这是面试官非常喜欢追问的点也是我自己最初写代码时完全没意识到的细节。如果空值 TTL 和正常数据一样都是 30 分钟会出现什么情况运营突然在后台补录了一条id999的商铺数据数据库里已经能查到了但 Redis 里cache:shop:999这个 key 还有 29 分钟才过期缓存里存的是空字符串。这 29 分钟里所有查询这个 id 的用户都会在缓存层拿到空值并直接返回“商铺不存在”新增的数据对用户完全不可见。这种“数据已经存在但查不到”的问题直接影响业务正确性。把空值 TTL 设置成 2 分钟意思是最多只承担 2 分钟的“假不存在”风险。2 分钟之后这个空 key 自动过期下一个请求就会重新走到 DB 查询链路如果数据库里已经有数据了就能拿到并回填正常缓存。我实践中会把它再细化一点如果项目对数据可见性要求很高空值 TTL 甚至可以缩短到 30 秒甚至 10 秒如果空值流量特别大、内存压力明显可以把空值 TTL 适当拉长到 5 分钟同时定期清理空 key。这是一个需要根据业务容忍度去权衡的参数没有绝对标准。黑马点评里的 2 分钟是一个兼顾“可见性”和“命中率”的折中值。3.3 穿透方案的另一条路线布隆过滤器缓存空值不是唯一解另一个常被提到的方案是布隆过滤器。它的思路是在查询缓存之前先用一个 bitmap 去判断“这个 id 到底存不存在”。如果判断结果为“一定不存在”就直接返回空连缓存都不查如果判断为“可能存在”才继续查缓存、查 DB。它和缓存空值方案对比起来对比点缓存空值方案布隆过滤器方案实现成本低几行代码高需要额外维护 bitmap 结构空间占用每个空 key 占一个 Redis key会越来越多固定大小与数据量无关误判无误差但存在短时间“假不存在”有误判率但可控制删除支持支持key 到期自动清不支持误判率会积累适用场景中小项目、通用查询海量 key、内存敏感的大型系统黑马点评作为教学项目选择缓存空值法是因为它能在最小代码量下把问题解决。你在回答时可以说“项目中用了缓存空值 短 TTL 的方案因为它实现简单、可控性高如果将来数据量达到亿级、空 key 数量多到影响内存可以升级为布隆过滤器前置拦截。”这个回答比只说一种方案好得多因为它展示了你对两种方案边界条件的理解。4. 缓存击穿解法互斥锁与逻辑过期的两套代码4.1 互斥锁方案queryWithMutex 的加锁与重试缓存击穿最典型的场景一个热点商铺 key 在 30 分钟 TTL 到期的一瞬间同时有两万个请求在查它。没有锁的情况下这两万个请求会全部打到 DB执行两万次 select数据库直接高负载。互斥锁的思路就是只让一个请求去重建缓存其他请求先“等一下”。public R, ID R queryWithMutex(String keyPrefix, ID id, ClassR type, FunctionID, R dbFallback, Long time, TimeUnit unit) { String key keyPrefix id; String lockKey LOCK_SHOP_KEY id; // 1. 先查缓存 String json stringRedisTemplate.opsForValue().get(key); if (StrUtil.isNotBlank(json)) { return JSONUtil.toBean(json, type); } if (json ! null) { return null; } // 2. 尝试获取互斥锁 boolean isLock tryLock(lockKey); if (!isLock) { // 3. 没拿到锁说明别的线程正在重建缓存休眠 50ms 后重试 Thread.sleep(50); return queryWithMutex(keyPrefix, id, type, dbFallback, time, unit); } try { // 4. 拿到锁后 double check防止其他线程在等待期间已经重建了缓存 json stringRedisTemplate.opsForValue().get(key); if (StrUtil.isNotBlank(json)) { return JSONUtil.toBean(json, type); } // 5. 查 DB回填缓存 R r dbFallback.apply(id); if (r null) { stringRedisTemplate.opsForValue().set(key, , CACHE_NULL_TTL, CACHE_NULL_TTL_UNIT); return null; } stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(r), time, unit); return r; } finally { // 6. 释放锁 unlock(lockKey); } } private boolean tryLock(String key) { Boolean flag stringRedisTemplate.opsForValue() .setIfAbsent(key, 1, 10, TimeUnit.SECONDS); return Boolean.TRUE.equals(flag); } private void unlock(String key) { stringRedisTemplate.delete(key); }这里有几个关键点加锁用setIfAbsent而不是先exists再set。setIfAbsent(key, 1, 10, TimeUnit.SECONDS)是 Redis 原生的原子操作等价于 SETNX只有 key 不存在时才会写入并返回 true。如果你先查 exists 再 set两步之间存在时间窗口两个线程可能同时判断“锁不存在”同时去 set锁就失效了。这是初学者最容易犯的错。锁一定要带过期时间。这里的 10 秒是兜底用的如果拿到锁的线程在重建缓存时发生了网络异常、Full GC、机器宕机没有正常走到 finally 释放锁10 秒后 Redis 会自动删除这个 key其他线程才有机会重新拿锁。没有过期时间的锁一次异常就能让整个系统死锁所有请求都阻塞在拿锁阶段。面试官问“锁如果没设置过期时间会怎样”答案就是这个。拿不到锁为什么要休眠 50ms 而不是立刻重试。立刻递归重试会让所有没拿到锁的线程以极高频率反复抢锁CPU 空转Redis 请求量反而被重试逻辑放大。休眠 50ms 是给持有锁的线程留出重建缓存的时间实测下来这个间隔对“DB 查询 回填缓存”这种毫秒级操作比较合适。50ms 本身是经验值太短重试过于频繁太长用户等待明显。实际代码里Thread.sleep(50)要处理 InterruptedException课程版本里通常用 try-catch 包住或直接向上抛这里为展示核心逻辑做了精简。拿到锁之后必须 double check。我见过很多简化版代码拿到锁就直奔 DB完全不重新查缓存结果就是同一个缓存被重建两次第二次查询完全多余。double check 就是在拿锁后先把缓存重新读一次如果已经有值直接返回不去打扰 DB。finally 里的unlock也不能省如果 DB 查询抛出异常锁不会自动释放有了 finally无论成功还是失败锁都会在方法结束时被删除。4.2 逻辑过期方案过期时间放进 value 里业务线程异步重建互斥锁有一个明显的副作用缓存失效的那一刻大量请求会阻塞等待。高峰期如果 DB 重建缓存需要 200ms那 2 万个请求中大部分用户都要白白等上几轮 50ms体验很差。于是黑马点评里还有第二个方案逻辑过期。所谓逻辑过期核心是不让 Redis 真的把 key 删掉而是把一个“业务过期时间”塞进 value 里。缓存数据永远不过期只是 value 里记录的这个时间戳过期了。先看数据结构Data public class RedisData { private LocalDateTime expireTime; private Object data; }写入缓存时不再直接写业务对象而是包一层 RedisDataRedisData redisData new RedisData(); redisData.setData(shop); redisData.setExpireTime(LocalDateTime.now().plusSeconds(30)); stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(redisData));查询逻辑就变成从缓存里取出 JSON转成 RedisData判断 expireTime 与当前时间谁大谁小。public R, ID R queryWithLogicalExpire(String keyPrefix, ID id, ClassR type, FunctionID, R dbFallback, Long time, TimeUnit unit) { String key keyPrefix id; // 1. 查缓存 String json stringRedisTemplate.opsForValue().get(key); if (StrUtil.isBlank(json)) { // 逻辑过期方案依赖缓存预热缓存缺失先直接返回空 return null; } // 2. 反序列化 RedisData redisData JSONUtil.toBean(json, RedisData.class); R r JSONUtil.toBean((JSONObject) redisData.getData(), type); LocalDateTime expireTime redisData.getExpireTime(); // 3. 逻辑时间还没到直接返回旧数据 if (expireTime.isAfter(LocalDateTime.now())) { return r; } // 4. 逻辑过期了尝试拿互斥锁 String lockKey LOCK_SHOP_KEY id; boolean isLock tryLock(lockKey); if (isLock) { // 5. 拿到锁的线程异步重建缓存 CACHE_REBUILD_EXECUTOR.submit(() - { try { R newR dbFallback.apply(id); RedisData newData new RedisData(); newData.setData(newR); newData.setExpireTime(LocalDateTime.now().plusSeconds(time)); stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(newData)); } finally { unlock(lockKey); } }); } // 6. 无论是否拿到锁都先返回旧数据 return r; }这套逻辑的精妙之处在于业务请求永远不等待逻辑过期时间未到直接返回缓存里的数据零耗时。逻辑过期时间已到不再要求请求方等缓存重建完而是谁抢到锁谁去异步重建所有没抢到锁的请求直接拿着旧数据返回。对用户来说看到的可能是最多滞后一个重建周期的旧数据但对商铺详情这类读多写少的场景短暂的数据滞后完全不影响体验。需要特别注意的一个前提逻辑过期方案必须配合缓存预热。如果某个热点 key 从来没写入过缓存查询时json是 null这里直接返回空——逻辑过期方案里它没有“查 DB 兜底”的逻辑。黑马点评对这种方式的使用是项目启动或者运营编辑商品后先把热点数据写入缓存之后查询就走这套缓存逻辑。如果业务上不能接受“缓存没有就不返回”也可以在这个分支里加一层 DB 兜底。异步重建的线程池也很关键。我见过有人直接用new Thread(...)去重建缓存低流量下没问题但一旦热点 key 多、重建任务多每来一个过期请求就 new 一个线程线程数会失控。用固定大小的线程池把重建任务收敛起来既能控制对 DB 的并发压力也能避免线程爆炸。4.3 两种方案怎么选阻塞换一致性还是旧数据换响应速度这两个方案没有绝对的好坏选型往往取决于业务对“一致性”和“响应速度”的容忍度。给一个可以直接抄的对比对比维度互斥锁方案逻辑过期方案缓存失效瞬间的表现并发请求阻塞等待重建有用户会感到延迟并发请求立刻拿到旧数据响应速度稳定数据一致性更好重建完成立即读到新值弱过期后还会返回一段时间旧值实现复杂度低只要 tryLock double check高需要 RedisData 包装、线程池、预热依赖预热不需要缓存没有时自然查 DB 回填需要缓存缺失时没有兜底逻辑DB 压力重建瞬间只有一个线程查 DB但有阻塞等待只有抢到锁的线程异步查 DB且不阻塞请求典型案例下单、库存、账务等强一致场景商品页、活动页、详情页等读多写少场景我的建议是默认优先用互斥锁方案。它实现简单、一致性有保证小项目里很快就能跑通只有当压测发现“互斥锁在热点 key 失效瞬间导致接口 RT 暴涨、用户投诉明显”或者你对“允许读到旧数据”有明确业务容忍度时再考虑逻辑过期。面试时被问到“为什么黑马点评里有两个方法”你直接把这个选择逻辑说出来比单纯背书值钱得多。5. 高并发下的坑锁误删、序列化、一致性问题5.1 锁不能乱删从 SETNX 到值校验 Lua前面queryWithMutex里的tryLock/unlock是简易写法加锁时setIfAbsent(key, 1, 10, TimeUnit.SECONDS)释放时直接delete(key)。这种写法在小并发、短任务下没问题但生产环境有一个非常经典的坑锁误删。场景线程 A 拿到锁后因为 GC 停顿或者网络超时执行了很久10 秒锁过期了。此时线程 BsetIfAbsent成功拿到了锁。线程 A 终于缓过来执行完自己的逻辑走到 finally 里delete(lockKey)——它删的其实是线程 B 的锁。线程 B 的临界区瞬间失去保护下一个线程 C 也能拿到锁两个线程同时进入 DB 查询互斥锁的效果就没了。解决锁误删的标准做法是给每个线程的锁 value 赋一个唯一标识比如 UUID释放前先get比对是自己的锁再del。但“先 get 再 del”不是原子操作中间也有窗口更严谨的做法是用 Lua 脚本把“比对 删除”合并成一个原子操作if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end在 Java 里把lockKey和 UUID 作为参数传给脚本执行就能保证删除时的原子性。黑马点评课程在分布式锁那一章单独讲的就是这个演进路线SETNX 简易锁 → 加过期时间 → UUID 校验 → Lua 原子删除。回到 CacheClient 的小场景里即使只是做缓存重建我也建议至少把 UUID 校验加上。5.2 序列化与泛型JSON 反序列化时的一个隐蔽坑CacheClient 通篇用的都是JSONUtil.toBean(json, type)这个 API 大多数时候很顺手但碰到RedisData这种带有 Object 字段的结构时容易翻车。JSONUtil.toBean(json, RedisData.class)反序列化之后RedisData的data字段类型是 ObjectHutool 在解析时通常会把这一块变成一个JSONObject而不是期望的Shop对象。如果你直接写(Shop) redisData.getData()运行时会报 ClassCastException。正确做法是先拿到JSONObject再二次转换R r JSONUtil.toBean((JSONObject) redisData.getData(), type);这个细节我第一次写时没注意线上日志里全是类型转换异常。说白了就是JSON 反序列化只能还原成它认识的结构Object 字段在运行期不会自动变成业务对象。如果你用的是 Jackson 或 Gson同样有这个问题只是报错形式不同。与序列化相关的另一个决策是为什么存 JSON 而不是 Java 对象默认序列化。前面提到了可读性问题这里再补一句JSON 字符串在跨语言、跨版本升级时兼容性更好缓存服务端没有 Java 也能解析出内容而 JDK 默认序列化类一旦改了包名或字段旧缓存全部作废启动时还会出现反序列化失败。所以StringRedisTemplate JSON的组合几乎是我所有项目中处理缓存时的默认选项。5.3 缓存与数据库的一致性为什么说“先更库再删缓存”有读者可能会问CacheClient 处理了“缓存没有时怎么查 DB 回填”但 DB 更新后缓存怎么更新黑马点评课程里确实没有在 CacheClient 里做更新逻辑但面试官一定会追到这里提前准备好答案非常划算。最常见的更新策略是先更新数据库再删除缓存。因为修改数据库是耗时操作修改 Redis 很快把“快操作”放在最后能缩短不一致的窗口。反过来“先删缓存再更新数据库”有一个典型坑线程 A 删除缓存线程 B 此时查询发现缓存不存在去 DB 读到旧数据并回填随后线程 A 才更新数据库——缓存里就永远留着旧数据了这是缓存治理中最容易犯的顺序问题。如果对一致性要求再高一点会用到延迟双删更新数据库后删缓存等几百毫秒再删一次。第二次删除针对的是“第一次删除后、数据库更新完成前被某个读请求回填的旧缓存”。延迟时间需要根据业务链路估算一般 500ms 到 1s。再往上就是引入 MQ 异步重试删除、Canal 监听 binlog 自动触发删除等重型方案这些属于大厂面试进阶内容写在小项目简历上反而容易被追问到答不上来按需了解即可。5.4 雪崩的补充给 TTL 加一点随机性黑马点评里没有在 CacheClient 里做雪崩的随机 TTL但这是一个只需要几行代码就能补上的亮点。正常数据回填缓存时TTL 不要用固定 30 分钟可以在 30 分钟基础上加一个随机数让 key 的过期时间在 30 分钟附近离散分布避免大量热点 key 在同一时刻集体失效。long randomTtl CACHE_SHOP_TTL ThreadLocalRandom.current().nextLong(0, 300); stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(r), randomTtl, TimeUnit.SECONDS);这只是最基础的一种做法。部署层面的 Redis 集群、哨兵本地缓存 Caffeine 兜底也都是雪崩治理的常用手段提前把这些串成一条线回答“你做了哪些缓存治理”时就能形成完整闭环。6. 简历和面试怎么把 CacheClient 讲成亮点6.1 简历上的一句话包装很多同学简历上写黑马点评只会写“实现了 Redis 缓存商铺信息”这句话基本等于没写。更有效率的写法是突出你解决了什么、用什么手段、达到什么效果“针对商铺查询热点场景基于 Redis 封装通用缓存工具类 CacheClient通过缓存空值 短 TTL 解决缓存穿透问题针对热点 key 失效实现互斥锁与逻辑过期两套方案通过 SETNX 加锁与 double check 控制重建并发热点 key 失效时数据库 QPS 从瞬时打满降为常数接口 P99 耗时保持稳定。”写完之后自己对着检查一遍每个词后面能不能接一句“为什么”。比如“为什么是 SETNX不是先查再设”“为什么加 double check”“空值 TTL 为什么是 2 分钟”。能答出来的细节才是真亮点答不出来的细节就是挖给自己的坑。6.2 面试追问 Top 5围绕 CacheClient面试官的问题几乎离不开下面这几个我把回答要点整理一下面试追问参考答案要点缓存穿透和缓存击穿的区别穿透是查询不存在的数据每次都越过缓存打到 DB击穿是热点 key 失效瞬间大量请求同时打 DB。一个“必然不存在”一个“存在但缓存正好过期”。为什么空值要设置较短的 TTL避免“数据库已有数据但客户端长时间读不到”空值占内存短 TTL 让无效占用尽快释放。互斥锁和逻辑过期怎么选互斥锁阻塞请求换一致性逻辑过期用旧数据换响应速度强一致用互斥锁高并发读多写少用逻辑过期。锁为什么带过期时间 10 秒防止持锁线程异常导致死锁过期时间要大于“重建缓存”的预估耗时太小会提前释放锁太大会拖长异常恢复时间。缓存和数据库一致性怎么保证先更库再删缓存必要时延迟双删极端场景走 MQ 重试或 binlog 监听按项目体量说明即可。还有一个容易被追问的点“逻辑过期方案里缓存如果被 Redis 清掉了怎么办”如果你在简历里写了逻辑过期最好把预热策略也准备好——项目启动时把热点 key 提前写入缓存清理后通过定时任务或者查询兜底逻辑重新预热。这个问题答得上来基本就证明你真的不是背的面试题。最后分享一个我自己的练习方法把CacheClient的代码关掉只留方法名自己凭记忆完整默写一遍queryWithPassThrough和queryWithMutex。我第一次默写时卡在“空值判断为什么是json ! null而不是json ”和“拿锁后为什么要再读一次缓存”这两个地方。这两个问题想通了整个缓存治理的套路才算真正长在脑子里了面试时自然也就能比只会背概念的候选人多说出一层“为什么”。