# Redis缓存实战：更新策略与三大核心问题（穿透/雪崩/击穿）全解析（含面试重点）

Redis缓存实战更新策略与三大核心问题穿透/雪崩/击穿全解析含面试重点在分布式系统中Redis作为高性能的分布式缓存是提升系统并发能力、减轻数据库压力的核心组件。但缓存的使用并非“一存了之”若不妥善处理缓存更新、缓存穿透、雪崩、击穿等问题反而会引发系统性能瓶颈甚至服务宕机。本文将从缓存更新策略入手深入拆解三大缓存问题的成因、解决方案并结合实战代码解析思路补充面试高频考点帮你彻底吃透Redis缓存实战核心。一、核心基础Redis缓存更新策略缓存的本质是“内存中的数据副本”其核心价值是减少数据库访问压力。但内存资源有限且缓存数据需与数据库数据保持一致因此需要一套合理的缓存更新策略。Redis的缓存更新主要分为三大类内存淘汰、超时剔除、主动更新三者相辅相成覆盖不同业务场景。1.1 三大更新策略详解1.1.1 内存淘汰Redis自动执行当Redis的内存使用达到配置的max-memory阈值时Redis会自动触发淘汰机制删除部分“不重要”的数据释放内存空间。核心要点无需业务代码干预由Redis内核自动处理淘汰策略可配置面试高频常用策略如下LRULeast Recently Used最近最少使用淘汰最长时间未被访问的数据最常用LFULeast Frequently Used最不经常使用淘汰访问次数最少的数据volatile-lru仅淘汰设置了过期时间的、最近最少使用的数据allkeys-lru淘汰所有key中最近最少使用的数据noeviction不淘汰任何数据内存满时拒绝写入操作会报错。适用场景内存过载保护无需手动管理缓存生命周期。1.1.2 超时剔除开发配置在向Redis写入数据时手动给Key设置TTLTime To Live过期时间到期后Redis会自动删除该Key避免缓存数据长期占用内存同时保证数据时效性。核心要点由开发人员在代码中配置灵活可控过期时间设置需结合业务场景如热点数据设置较短过期时间冷门数据设置较长过期时间Redis的过期删除采用“惰性删除定期删除”结合的机制面试高频惰性删除只有当访问某个过期Key时才会检查并删除定期删除Redis每隔一段时间默认100ms随机检查部分过期Key并删除避免过期Key堆积。适用场景时效性强的数据如商品库存、新闻资讯。1.1.3 主动更新业务代码控制当数据库中的数据发生变更时手动通过代码删除或更新Redis中的缓存数据核心目的是解决“缓存与数据库数据不一致”的问题这是业务开发中最常用、最需要关注的更新方式。核心要点由业务代码主动触发完全可控核心目标保证缓存数据与数据库数据一致适用场景核心业务数据如用户信息、订单数据、商铺信息。1.2 缓存与数据库一致性解决方案面试重点缓存的数据源来自数据库当数据库数据变更时若缓存未同步会导致“缓存脏数据”用户读取到过期数据影响业务正确性。目前行业内有三种主流解决方案各有优劣需结合业务场景选择。1.2.1 三种一致性方案对比方案名称核心逻辑优点缺点适用场景Cache Aside Pattern双写方案业务代码手动控制更新数据库后同步操作缓存删除/更新实现简单、灵活可控一致性强需手动编码增加业务代码复杂度大部分业务场景最常用Read/Write Through Pattern读写穿透由系统层如缓存中间件自动同步业务代码只操作缓存不直接操作数据库对业务透明无需手动处理缓存与数据库同步系统实现复杂依赖中间件支持对业务侵入性要求低的场景Write Behind Caching Pattern异步双写业务代码只操作缓存由异步线程后台同步到数据库实现最终一致性性能高不阻塞业务流程存在数据丢失风险一致性弱最终一致高并发、对一致性要求不高的场景如点赞、浏览量1.2.2 最佳实践先更数据库再删缓存面试高频综合性能、一致性和实现难度Cache Aside Pattern是最常用的方案但在使用时需解决两个核心问题“操作缓存还是删除缓存”“先操作数据库还是先操作缓存”。问题1删除缓存 vs 更新缓存更新缓存每次更新数据库后同步更新缓存。缺点是“无效写操作多”——若更新后无人查询缓存更新操作毫无意义浪费IO资源删除缓存更新数据库后直接删除缓存。下次查询时缓存未命中再从数据库读取最新数据并写入缓存。优点是减少无效IO推荐使用。问题2先操作数据库还是先删除缓存核心结论先更新数据库再删除缓存避免并发场景下的“旧数据覆盖”问题。反例先删缓存再更数据库线程1删除缓存线程2查询缓存未命中从数据库读取旧数据并写入缓存线程1更新数据库此时缓存中是旧数据数据库中是新数据出现数据不一致。正例先更数据库再删缓存线程1更新数据库线程1删除缓存线程2查询缓存未命中从数据库读取最新数据并写入缓存缓存与数据库数据一致。1.3 实战商铺缓存与数据库双写一致代码思路解析以“商铺查询/更新”业务为例落地“先更数据库再删缓存”的方案核心思路的是查询时懒加载缓存更新时同步删除缓存。核心代码实现Spring Boot MyBatis-Plus Redis1. 常量定义避免硬编码// 商铺缓存Key前缀privatestaticfinalStringCACHE_SHOP_KEYcache:shop:;// 缓存过期时间30分钟privatestaticfinalLongCACHE_SHOP_TTL30L;2. 查询商铺带缓存懒加载/** * 查询商铺缓存未命中则查询数据库再写入缓存 * 代码思路 * 1. 拼接缓存Key从Redis查询缓存 * 2. 缓存命中直接反序列化为Shop对象返回 * 3. 缓存未命中查询数据库若数据库存在数据写入缓存并设置过期时间 * 4. 数据库也不存在返回null后续结合缓存穿透优化。 */OverridepublicShopqueryById(Longid){StringkeyCACHE_SHOP_KEYid;// 1. 查询Redis缓存StringshopJsonstringRedisTemplate.opsForValue().get(key);// 2. 缓存命中直接返回if(StrUtil.isNotBlank(shopJson)){returnJSONUtil.toBean(shopJson,Shop.class);}// 3. 缓存未命中查询数据库ShopshopgetById(id);if(shopnull){returnnull;}// 4. 写入缓存设置30分钟过期stringRedisTemplate.opsForValue().set(key,JSONUtil.toJsonStr(shop),CACHE_SHOP_TTL,TimeUnit.MINUTES);returnshop;}3. 更新商铺先更库再删缓存/** * 更新商铺先更新数据库再删除缓存 * 代码思路 * 1. 先调用父类方法更新数据库 * 2. 更新成功后删除对应缓存让下次查询加载最新数据 * 3. 返回更新结果。 * 注意必须先更库再删缓存避免数据不一致。 */OverridepublicbooleanupdateById(Shopshop){// 1. 更新数据库booleansuccesssuper.updateById(shop);if(success){// 2. 删除缓存关键步骤stringRedisTemplate.delete(CACHE_SHOP_KEYshop.getId());}returnsuccess;}二、Redis缓存三大核心问题面试高频在高并发场景下单纯使用缓存还不够若不处理好“缓存穿透、缓存雪崩、缓存击穿”这三大问题会导致缓存失效大量请求直接打到数据库引发系统崩溃。下面逐一拆解成因、解决方案和实战代码。2.1 缓存穿透请求“穿透”缓存直击数据库2.1.1 什么是缓存穿透客户端请求的数据在缓存和数据库中都不存在导致请求永远绕过缓存直接访问数据库。若存在大量此类请求如恶意查询不存在的ID会导致数据库压力骤增甚至宕机。核心成因请求数据在缓存和数据库均不存在缓存无法生效。2.1.2 两种核心解决方案面试重点解决方案核心逻辑优点缺点缓存空对象数据库查询结果为空时仍将“空值”如、null写入缓存设置较短过期时间实现简单、维护方便无需额外组件额外占用内存存在短期数据不一致如数据库新增该数据后缓存空值未过期布隆过滤器用二进制数组多次哈希提前过滤“不存在的数据”拒绝请求进入数据库内存占用少无冗余Key过滤效率高实现复杂存在误判哈希冲突导致认为存在但实际不存在无法删除数据2.1.3 实战缓存空对象解决缓存穿透代码思路解析在原有查询逻辑基础上新增“缓存空对象”逻辑避免请求直接打到数据库。// 新增缓存空值的过期时间2分钟避免内存泄漏privatestaticfinalLongCACHE_NULL_TTL2L;/** * 查询商铺解决缓存穿透缓存空对象 * 代码思路 * 1. 正常查询缓存命中则返回 * 2. 缓存未命中查询数据库 * 3. 数据库不存在写入空值到缓存设置2分钟过期返回null * 4. 数据库存在写入缓存返回数据。 */publicShopqueryByIdWithPenetrationPrevent(Longid){StringkeyCACHE_SHOP_KEYid;StringshopJsonstringRedisTemplate.opsForValue().get(key);// 1. 缓存命中包括空值if(StrUtil.isNotBlank(shopJson)){returnJSONUtil.toBean(shopJson,Shop.class);}// 2. 缓存命中空值说明数据库也不存在if(shopJson!null){returnnull;}// 3. 缓存未命中查询数据库ShopshopgetById(id);if(shopnull){// 写入空值到缓存设置2分钟过期stringRedisTemplate.opsForValue().set(key,,CACHE_NULL_TTL,TimeUnit.MINUTES);returnnull;}// 4. 写入正常缓存stringRedisTemplate.opsForValue().set(key,JSONUtil.toJsonStr(shop),CACHE_SHOP_TTL,TimeUnit.MINUTES);returnshop;}2.1.4 缓存穿透防御补充面试拓展增强ID复杂度避免使用自增ID如恶意猜测ID批量查询采用UUID、雪花算法等参数校验在接口层过滤无效参数如ID为负数、字符串等权限校验限制未登录用户的查询权限防止恶意请求热点参数限流对高频查询的参数如不存在的ID进行限流避免数据库压力过大。2.2 缓存雪崩大量缓存同时失效引发数据库灾难2.2.1 什么是缓存雪崩在同一时段大量缓存Key同时过期或者Redis服务宕机导致海量请求无法命中缓存全部直接打到数据库引发数据库压力过载、甚至宕机进而导致整个系统崩溃。核心成因缓存批量失效 高并发请求。2.2.2 四大解决方案面试重点TTL随机化最常用给不同Key的过期时间添加随机值如30±5分钟避免大量Key在同一时间过期。代码示例// 给过期时间添加随机值5分钟内随机 long random ThreadLocalRandom.current().nextLong(0, 5 * 60); long ttl CACHE_SHOP_TTL * 60 random; stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shop), ttl, TimeUnit.SECONDS);Redis集群高可用采用主从复制、哨兵模式或Redis Cluster集群避免单点故障。即使主节点宕机从节点也能快速切换保证Redis服务可用。降级限流兜底方案当缓存雪崩发生时通过降级策略如关闭非核心接口、限流策略如限制每秒请求数减少数据库的请求压力保护数据库不宕机。多级缓存层层防护引入本地缓存如Caffeine 分布式缓存Redis形成多级缓存体系。当Redis宕机时本地缓存可临时承接部分请求降低数据库压力。2.3 缓存击穿热点Key过期瞬间压垮数据库2.3.1 什么是缓存击穿也叫“热点Key问题”一个被高并发访问、且缓存重建逻辑复杂如查询数据库耗时久的Key突然过期导致瞬间大量请求同时打到数据库造成数据库冲击。核心成因热点Key过期 高并发访问 缓存重建耗时久。注意缓存击穿与缓存雪崩的区别——击穿是“单个热点Key失效”雪崩是“大量Key同时失效”。2.3.2 两种核心解决方案面试高频对比记忆解决方案核心逻辑优点缺点适用场景互斥锁只允许一个线程重建缓存其他线程等待避免大量线程同时查询数据库数据一致性强实现简单无额外内存消耗串行执行性能下降存在死锁风险对一致性要求高、缓存重建耗时久的场景逻辑过期缓存永不过期将过期时间存入Value中过期后异步线程后台重建缓存用户无需等待性能好不阻塞用户请求无死锁风险实现复杂存在短期脏数据重建缓存期间返回旧数据高并发、对一致性要求不高的场景2.3.3 实战一互斥锁解决缓存击穿代码思路解析利用Redis的setIfAbsent方法对应Redis指令SETNX实现分布式互斥锁保证只有一个线程能重建缓存。1. 锁工具方法核心/** * 尝试获取分布式锁 * 核心思路利用setIfAbsentSETNXRedis中无该Key则插入成功获取锁有则失败未获取锁 * param key 锁的Key如lock:shop:1 * return true获取锁成功false获取锁失败 */privatebooleantryLock(Stringkey){// setIfAbsentKey不存在则插入返回true存在则返回false// 同时设置10秒过期时间防止线程宕机导致锁永久占用避免死锁BooleanflagstringRedisTemplate.opsForValue().setIfAbsent(key,1,10,TimeUnit.SECONDS);// BooleanUtil.isTrue处理flag为null的情况Redis客户端异常避免空指针returnBooleanUtil.isTrue(flag);}/** * 释放分布式锁 * param key 锁的Key */privatevoidunlock(Stringkey){stringRedisTemplate.delete(key);}2. 核心业务代码/** * 查询商铺互斥锁解决缓存击穿 * 代码思路 * 1. 正常查询缓存命中则返回 * 2. 缓存未命中尝试获取互斥锁 * 3. 未获取到锁休眠50ms后重试递归 * 4. 获取到锁查询数据库重建缓存释放锁返回数据 * 5. 数据库不存在缓存空值释放锁返回null。 */publicShopqueryWithMutex(Longid){StringkeyCACHE_SHOP_KEYid;// 1. 查询缓存StringshopJsonstringRedisTemplate.opsForValue().get(key);if(StrUtil.isNotBlank(shopJson)){returnJSONUtil.toBean(shopJson,Shop.class);}// 2. 缓存命中空值直接返回if(shopJson!null){returnnull;}StringlockKeylock:shop:id;// 锁的Key与商铺ID绑定Shopshopnull;try{// 3. 尝试获取互斥锁booleanisLocktryLock(lockKey);if(!isLock){// 4. 未获取到锁休眠后重试Thread.sleep(50);returnqueryWithMutex(id);// 递归重试}// 5. 获取到锁查询数据库此时只有一个线程执行shopgetById(id);if(shopnull){// 缓存空值stringRedisTemplate.opsForValue().set(key,,CACHE_NULL_TTL,TimeUnit.MINUTES);returnnull;}// 6. 重建缓存stringRedisTemplate.opsForValue().set(key,JSONUtil.toJsonStr(shop),CACHE_SHOP_TTL,TimeUnit.MINUTES);}catch(Exceptione){thrownewRuntimeException(e);}finally{// 7. 释放锁必须在finally中确保锁一定释放避免死锁unlock(lockKey);}returnshop;}2.3.4 实战二逻辑过期解决缓存击穿代码思路解析核心思路缓存Key永不过期将过期时间封装到Value中当检测到数据过期时异步线程后台重建缓存用户无需等待直接返回旧数据。1. 封装缓存数据结构新增实体类/** * 封装Redis缓存数据带逻辑过期时间 * 作用不修改原有Shop实体类降低代码侵入性 */DatapublicclassRedisData{// 逻辑过期时间不作用于Redis仅用于业务判断privateLocalDateTimeexpireTime;// 实际业务数据Shop对象privateObjectdata;}2. 缓存预热提前加载热点数据热点数据需要提前写入缓存如通过单元测试、定时任务避免首次查询时缓存未命中。/** * 缓存预热将商铺数据写入Redis设置逻辑过期时间 * param id 商铺ID * param expireSeconds 逻辑过期时间秒 */publicvoidsaveShop2Redis(Longid,LongexpireSeconds){// 1. 查询数据库ShopshopgetById(id);// 2. 封装成RedisData对象RedisDataredisDatanewRedisData();redisData.setData(shop);redisData.setExpireTime(LocalDateTime.now().plusSeconds(expireSeconds));// 3. 写入Redis永不过期逻辑过期由业务控制stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEYid,JSONUtil.toJsonStr(redisData));}// 单元测试预热热点数据如ID1的商铺TestpublicvoidtestSaveShop2Redis(){saveShop2Redis(1L,20L);// 逻辑过期时间20秒}3. 核心查询逻辑// 线程池用于异步重建缓存固定10个线程避免线程过多privatestaticfinalExecutorServiceCACHE_REBUILD_EXECUTORExecutors.newFixedThreadPool(10);/** * 查询商铺逻辑过期解决缓存击穿 * 代码思路 * 1. 查询缓存未命中则返回null * 2. 缓存命中反序列化为RedisData对象判断是否过期 * 3. 未过期直接返回Shop数据 * 4. 已过期尝试获取互斥锁异步线程重建缓存当前线程直接返回旧数据 * 5. 未获取到锁直接返回旧数据。 */publicShopqueryWithLogicalExpire(Longid){StringkeyCACHE_SHOP_KEYid;// 1. 查询缓存StringjsonstringRedisTemplate.opsForValue().get(key);if(StrUtil.isBlank(json)){// 缓存未命中直接返回null热点数据已预热此处基本不会触发returnnull;}// 2. 缓存命中反序列化为RedisDataRedisDataredisDataJSONUtil.toBean(json,RedisData.class);ShopshopJSONUtil.toBean((JSONObject)redisData.getData(),Shop.class);LocalDateTimeexpireTimeredisData.getExpireTime();// 3. 判断数据是否过期if(expireTime.isAfter(LocalDateTime.now())){// 3.1 未过期直接返回returnshop;}// 3.2 已过期需要缓存重建StringlockKeylock:shop:id;booleanisLocktryLock(lockKey);if(isLock){// 4. 获取到锁异步线程重建缓存不阻塞当前请求CACHE_REBUILD_EXECUTOR.submit(()-{try{// 重建缓存设置逻辑过期时间20秒saveShop2Redis(id,20L);}catch(Exceptione){thrownewRuntimeException(e);}finally{// 释放锁unlock(lockKey);}});}// 5. 无论是否获取到锁都返回旧数据保证用户体验牺牲短期一致性returnshop;}三、面试高频问题总结必背3.1 缓存更新相关**Redis的缓存更新策略有哪些**答三种核心策略——内存淘汰Redis自动按配置策略淘汰、超时剔除手动设置TTL到期自动删除、主动更新业务代码手动控制解决数据一致性。**如何保证缓存与数据库的数据一致性**答首选Cache Aside Pattern先更新数据库再删除缓存。原因避免先删缓存再更数据库的并发脏数据问题删除缓存比更新缓存更高效减少无效IO。**为什么不推荐“先删缓存再更新数据库”**答并发场景下会出现旧数据覆盖问题线程1删缓存 → 线程2查缓存未命中 → 线程2读旧数据写入缓存 → 线程1更新数据库 → 缓存为旧数据出现不一致。3.2 缓存穿透相关**什么是缓存穿透如何解决**答请求数据在缓存和数据库中都不存在导致请求直接打到数据库。解决方案① 缓存空对象简单易实现② 布隆过滤器内存高效有误判③ 辅助手段ID复杂度、参数校验、限流。**缓存空对象的缺点是什么如何优化**答缺点额外占用内存、短期数据不一致。优化设置较短的过期时间如2分钟避免内存泄漏数据库新增数据时主动删除缓存空值。**布隆过滤器的原理和缺点**答原理通过二进制数组多次哈希判断数据是否存在。缺点存在误判哈希冲突无法删除数据删除会影响其他数据的判断。3.3 缓存雪崩相关**什么是缓存雪崩与缓存击穿的区别**答缓存雪崩是大量Key同时过期或Redis宕机导致海量请求打数据库缓存击穿是单个热点Key过期导致大量请求打数据库。核心区别影响范围批量vs单个。**如何解决缓存雪崩**答① TTL随机化避免批量过期② Redis集群高可用③ 降级限流兜底④ 多级缓存本地缓存分布式缓存。3.4 缓存击穿相关**什么是缓存击穿两种解决方案的对比**答热点Key过期大量高并发请求打数据库。两种方案对比互斥锁一致性强、实现简单但性能下降、有死锁风险逻辑过期性能好、不阻塞请求但实现复杂、有短期脏数据。**互斥锁为什么要用Redis的setIfAbsent如何避免死锁**答setIfAbsent对应SETNX指令能实现“原子性”获取锁避免多线程同时获取锁避免死锁给锁设置过期时间且在finally中释放锁。**逻辑过期方案中为什么要异步重建缓存**答避免阻塞用户请求保证高并发场景下的响应速度异步线程后台重建缓存不影响当前请求的返回牺牲短期一致性换取性能。3.5 综合实战相关**如何设计一个高可用的Redis缓存系统**答① 合理选择缓存更新策略先更库再删缓存② 解决三大缓存问题穿透、雪崩、击穿③ 搭建Redis集群主从哨兵④ 引入多级缓存⑤ 做好监控和降级限流。**实际开发中缓存过期时间如何设置**答① 热点数据较短过期时间如30分钟 TTL随机化② 冷门数据较长过期时间如1天③ 缓存空值极短过期时间如2分钟④ 核心数据结合业务场景设置合理过期时间同时做好缓存预热。四、总结Redis缓存的核心价值是“提升并发、减轻数据库压力”但要发挥其价值必须解决好两大核心问题缓存更新与数据一致性、缓存穿透/雪崩/击穿。本文从基础的缓存更新策略入手结合实战代码解析了三大缓存问题的成因和解决方案补充了面试高频考点覆盖了从理论到实战的全流程。实际开发中需结合业务场景选择合适的方案如对一致性要求高用互斥锁对性能要求高用逻辑过期同时做好高可用设计才能让Redis真正成为系统的“性能加速器”。