1. 破题Redis缓存面试题到底在考什么先聊点实在的。我面试过不少人简历上写着“熟悉Redis”但一问“缓存穿透和缓存击穿有什么区别”十个人里有六七个会卡壳。这不是背题的问题而是很多人刷“Redis缓存面试题50道”这种题库时只记住了答案的骨架没搞懂面试官真正想听什么。Redis缓存面试题的核心从来不是考察你记住了多少命令、多少种数据类型。它考察的是三件事第一你有没有真的理解缓存系统的本质——用空间换时间用牺牲一致性换性能第二你有没有在线上遇到过缓存引发的事故比如大促时缓存雪崩把数据库打挂第三你解决问题时有没有工程思维能不能说出每个方案的代价和适用场景。所以这篇东西我不打算按“第1题、第2题”的方式机械罗列。我会把高频考点拆成几个大块缓存三兄弟穿透、击穿、雪崩、缓存一致性、持久化与淘汰策略、分布式锁、缓存治理与线上实战、容易串台的概念辨析。每个考点我都会站在面试官视角告诉你“他在问什么”再站在干活儿的人视角告诉你“实际怎么解”。文章涉及的Redis数据类型、过期策略、分布式锁、缓存治理这些热词也都会逐个落到场景里讲透。如果你是准备面试的候选人这篇能帮你把零散知识点串成体系如果你已经在用Redis但总觉得知其然不知其所以然这篇也能补上不少“为什么”。我自己就是一边踩坑一边把这些东西捋清楚的下面进入正题。2. 缓存三兄弟穿透、击穿、雪崩的原理与解法2.1 三个概念先分清别在面试第一关就翻车这三个词是Redis缓存面试题的绝对C位几乎每场面试都会碰到。先把定义说清楚缓存穿透请求的数据在缓存和数据库中都不存在。比如查一个不存在的用户ID每次请求都直接打到数据库缓存永远无法命中。缓存击穿某个热点key的缓存过期瞬间大量并发请求同时打到数据库。注意这里key是存在的只是刚好在那一瞬间失效了。缓存雪崩大量key在同一时间段集中过期或者Redis整个宕机导致海量请求直接打到数据库。很多人的误区是把穿透和击穿搞混。我总结一个记忆方法穿透是“数据本身就不存在缓存形同虚设”击穿是“单点热点key过期缓存短暂失效”雪崩是“大面积key过期或缓存整体不可用”。面试官如果让你举例子你就说穿透像查一个已经被注销的账号击穿像微博热搜词条在刷新瞬间的爆发流量雪崩像双十一零点整点缓存集体失效。2.2 缓存穿透的三种解法以及各自代价穿透最经典的解法是参数校验 缓存空值 布隆过滤器。参数校验很好理解非法的参数直接拦截在入口比如ID不能为负数、长度不能超过限制。这块成本最低但只能挡住低级攻击。缓存空值是指如果数据库查不到就向缓存里写一个null值并设置一个较短的过期时间比如3到5分钟。这样后续同样的查询会命中缓存而不会反复打库。代价是缓存里会积累大量空值占内存解决办法是过期时间别设太长再配合前面说的参数校验把明显不合理的请求过滤掉。布隆过滤器是另一条路。它可以在缓存前面加一道屏障把所有可能存在的数据ID预加载到布隆过滤器里请求进来先问过滤器“这个ID存在吗”如果过滤器说不存在那肯定不存在直接返回。注意布隆过滤器有误判率它只会误判“存在”不会误判“不存在”所以宁可错杀不可放过的场景非常合适。我实际用下来的心得是布隆过滤器适合数据量大体量相对固定的业务比如商品ID、用户ID。数据频繁新增删除的场景要慎用因为标准布隆过滤器不支持删除删一个ID得重建整个位数组。真要支持删除得上Counting Bloom Filter那又是一套复杂度。2.3 缓存击穿互斥锁和逻辑过期怎么选击穿的解法我推荐两种主流方案互斥锁Mutex Lock和逻辑过期Logical Expiration。互斥锁的思路是当缓存失效时不是所有线程都去查数据库而是只让一个线程去重建缓存其他线程等待。实现上常见的是用SET key value NX EX命令抢锁# 抢锁 SET lock:hotkey 1 NX EX 5 # 抢到锁的线程查数据库重建缓存 # 其他线程 sleep 后重试读缓存这里有个细节锁的过期时间不能太长否则持有锁的线程还没重建完缓存锁就被人抢走了也不能太短否则并发下会有多个线程同时进数据库。一般根据重建缓存的时间来定我会在后面的分布式锁章节细说。逻辑过期方案更巧妙缓存value里不存纯数据而是存一个对象包含data和expireTime两个字段。读取时如果发现逻辑过期不立即删除缓存而是返回旧数据的同时让一个线程去后台重建缓存。这样用户在缓存重建期间依然能读到旧值体验无损。两种方案我都在生产环境用过总结一下适用场景方案优点缺点适用场景互斥锁实现简单数据强一致缓存重建期间有短暂不可用可能阻塞请求对一致性要求高并发量中等的场景逻辑过期用户体验好无阻塞实现复杂过期时间内读到的是旧数据热点key重建成本高允许短暂脏读的场景2.4 缓存雪崩的防御别只盯着“过期时间错开”雪崩的常见原因有两个一是大量key同时过期二是Redis本身挂了。针对第一个原因最朴素的做法是给过期时间加随机值。比如原来统一过期时间是1小时现在改成1小时 随机0到10分钟把过期时间打散。这个方案简单有效我在实际项目里一直在用。更进一步的方案是多级缓存本地缓存比如Caffeine或Guava Redis。即使Redis挂了本地缓存还能扛住一部分流量。Nginx层面也可以做一层缓存但那是架构层面的事面试能提到就已经算加分。针对第二个原因Redis挂了怎么扛老实说单靠Redis自身很难完全避免关键看高可用架构。主从 哨兵可以保证Redis故障自动切换集群模式可以分片分散压力。但即便Redis集群整体不可用你的系统也该有兜底方案接口层做降级直接返回默认数据或提示稍后重试别让请求穿透到数据库。我在一次分享里说过一个观点缓存雪崩的防守重点不在缓存本身而在于数据库的限流和降级。你无法保证缓存100%可用但你可以保证数据库不被打挂。用Sentinel或Hystrix给数据库调用加上熔断限流这才是雪崩防御的最后一层保险。3. 缓存一致性双写不一致的根源与工程解法3.1 为什么缓存和数据库永远会有不一致缓存一致性是另一个高频考点而且比三兄弟更考验工程理解。先明确一个前提只要用了缓存就一定存在不一致的窗口。你不可能做到缓存和数据库绝对一致只能追求最终一致性和可接受的不一致时间。不一致的根源在于读写并发。经典场景是一个线程更新数据库把旧值改成新值另一个线程刚好在读缓存——它可能读到更新前的旧缓存。更麻烦的是如果更新数据库和更新缓存两个操作不是原子的中间任何一个环节失败都会导致不一致。面试里最常见的方案是Cache Aside旁路缓存模式它有两个关键原则读的时候先读缓存读不到就读数据库再回填缓存。写的时候先更新数据库再删除缓存。注意这里写的时候是删除缓存不是更新缓存。为什么因为更新缓存有两个问题一是频繁更新浪费性能可能你刚更新完缓存还没被读又被下一次写入覆盖了二是并发写容易导致缓存里留下旧值——比如A线程把数据库改成1B线程改成2但B先写缓存A后写缓存最终缓存里是1数据库是2。删除缓存能规避这个竞态因为下次读的时候会自动回填最新值。3.2 延迟双删以及它的两个致命细节Cache Aside有一个经典问题线程A更新数据库为2然后删除缓存但删除动作还没执行时线程B读取缓存得到旧值1并回填了缓存等A删缓存时其实已经把B回填的1删掉了问题不大。但反过来如果A删缓存的动作执行得太早B在那之后把旧缓存回填了缓存就永远留下了旧值。解法是延迟双删Delay Double Delete先删除缓存再更新数据库再延时删除缓存。伪代码如下1. 删除缓存 2. 更新数据库 3. 休眠一段时间比如500ms 4. 再次删除缓存延迟的目的是把B线程回填旧缓存的窗口覆盖掉。但这里有两个致命细节第一休眠时间到底设多少太短盖不住B的回填窗口太长影响写入性能。实际项目中我一般按读请求的平均响应时间来估算通常500ms到1秒你可以通过监控数据来校准。第二第二次删除失败了怎么办这就是很多人面试答不出来的点。光靠延迟双删不能保证绝对一致必须配合重试机制。常用的做法是订阅MySQL的binlog或者用一个消息队列异步重试删除。更进一步的做法是引入Canal这类中间件监听MySQL binlog变更解析后同步给消费者去删缓存。这个方案因为解耦了业务代码被认为是比较优雅的最终一致性方案。3.3 面试加分项Cache Aside的替代方案对比面试官问到“你还有什么方案”时如果你能主动对比几种方案印象分会明显不一样。Write Through写直通写入数据库的同时同步写缓存保证强一致但每次写都要操作两个存储性能较差。Write Back写回只写缓存异步批量写回数据库性能最好但丢数据风险大适合读多写少且允许丢失的场景。Cache Aside性能与一致性折中是目前应用最广的方案。我给面试者的建议是先说Cache Aside是默认选择然后立刻补充它的不一致窗口问题接着引出延迟双删和binlog订阅方案。这一套下来面试官基本会认为你不是背题而是真的处理过线上问题。还有一个高频追问**为什么是删除缓存而不是更新缓存**这个问题前面已经解释过但面试时你还要补一句更新缓存需要额外的并发控制考虑ABA问题而删除缓存天然是幂等的——删两次和删一次效果一样。4. 持久化与淘汰策略数据可靠性与内存效率的平衡4.1 RDB和AOF的取舍面试官最想听的关键词Redis缓存面试题里持久化出现的频率不低。虽然Redis常被当作缓存但生产环境很多人会开持久化防止重启丢数据。持久化两大方案RDB快照和AOF日志。RDB是fork一个子进程将内存数据全量落盘。优点是文件紧凑、恢复快缺点是fork瞬间可能阻塞主线程而且两次快照之间的数据会丢失。AOF是把每次写命令追加到日志文件可配置appendfsync策略always每条命令都同步刷盘性能最差但最安全。everysec每秒刷一次性能与安全的折中也是默认配置。no交给操作系统刷盘性能最好但可能丢1秒以上数据。面试官如果追问“AOF文件越来越大怎么办”答案是AOF重写RewriteRedis会fork子进程生成一个新的AOF文件把当前数据用最精简的命令重新表达一遍覆盖旧文件。我自己的生产实践是缓存数据可以接受丢失一般关掉持久化或者只开AOF everysec但如果Redis里存了业务关键数据建议开混合持久化——RDB做全量快照AOF记录快照之后的增量命令兼顾恢复速度和数据安全。4.2 Redis为什么快除了内存还有三个底层机制这个考点经常被安排在“说说你对Redis的理解”这类泛问题里。很多人第一反应就是“因为Redis是基于内存的”这没错但不够。真正的答案包括三点第一单线程模型避免了上下文切换和锁竞争。Redis的网络IO和命令处理都在一个线程里完成没有线程切换开销也没有多线程资源竞争问题。很多人会问“那多核CPU不是浪费了吗”Redis官方后来引入了多线程IO但命令执行依然是单线程。第二IO多路复用机制。Redis使用epoll同时监听大量客户端连接当某个socket可读或可写时再处理对应请求而不是一个连接开一个线程。第三高效的数据结构。Redis的每种数据类型底层都有精妙设计比如跳表skip list用于有序集合的二分查找压缩列表用于小数据量的内存优化这些在“Redis数据类型”面试题里会延展。顺带一提很多面试者会把“Redis是单线程的”说成“Redis性能瓶颈在于CPU”这就把因果关系搞反了。Redis的瓶颈通常在网络IO和内存大小而不是CPU。4.3 过期删除与内存淘汰两套机制别搞混过期删除针对的是设置了TTL的key策略是惰性删除 定期删除的组合惰性删除是指访问key时才检查是否过期过期就删除定期删除是每100ms随机抽取一部分key检查并删除过期key。懒加载的好处是省CPU坏处是过期key可能残留占内存。内存淘汰针对的是Redis达到maxmemory上限时的处理策略。Redis 8种淘汰策略如下策略含义noeviction不淘汰写入返回错误allkeys-lru从所有key中按LRU淘汰allkeys-lfu从所有key中按LFU淘汰allkeys-random从所有key中随机淘汰volatile-lru从设置了过期的key中按LRU淘汰volatile-lfu从设置了过期的key中按LFU淘汰volatile-random从设置了过期的key中随机淘汰volatile-ttl从设置了过期的key中淘汰剩余TTL最短的面试里我建议你真的把这张表记下来并且能说出至少四种策略的名称和区别。继续追问时你要能答出LRU和LFU的区别LRU按最近最少访问淘汰LFU按最不经常访问淘汰。LFU能解决LRU的“偶发批量访问污染”问题——某key只是被刷了一下就占据缓存位置LFU更照顾长期访问频率高的key。实际配置经验是如果Redis只当缓存用maxmemory-policy设为allkeys-lru如果部分key禁止淘汰用volatile-lru但前提是那些允许淘汰的key都设置了过期时间。线上我见过有人配了allkeys-lru导致某些存session的key被莫名其妙踢掉用户被迫重新登录排查半天才找到原因。5. 分布式锁与并发场景从setnx到Redisson的进化5.1 setnx加过期时间的正确姿势分布式锁是Redis面试的另一大热点尤其在后端岗位里几乎必问。最常见的实现是用Redis的SETNX命令——只有key不存在时才设置成功配合过期时间防止死锁SET lock:order:12345 1 NX EX 30 -- 业务处理完成后 DEL lock:order:12345注意这里必须使用SET key value NX EX原子命令而不能拆成SETNX然后EXPIRE两步。拆开的话如果SETNX成功但EXPIRE执行前进程挂了锁就永远不会释放直接造成死锁。但这只是最基础的版本面试官一定会继续挖如果业务还没执行完锁就过期了怎么办这就是看门狗机制要解决的问题。5.2 Redisson看门狗能解决什么不能解决什么Redisson是Java生态里最常用的Redis客户端之一它内置了看门狗Watchdog机制当锁被获取后只要业务线程还在运行Redisson会每隔一段时间自动给锁续期默认情况下锁的租期是30秒看门狗每10秒续期一次直到业务完成释放锁。这个机制确实解决了“业务超时锁提前释放”的问题。但面试官会问看门狗续期期间其他线程一直拿不到锁阻塞时间过长怎么办答案是用tryLock带等待时间RLock lock redissonClient.getLock(lock:order:12345); boolean acquired lock.tryLock(2, 30, TimeUnit.SECONDS); if (acquired) { try { // 业务逻辑 } finally { lock.unlock(); } }tryLock的第一个参数是等待时间超过等待时间就放弃这样不会无限阻塞。更深一层的追问是主从架构下锁写入主节点后主节点挂了从节点还没有同步锁数据另一个线程从从节点获取同一把锁成功锁就失效了。这就是分布式锁在主从架构下的经典问题。Redisson的解决思路是红锁RedLock要求锁必须写入大多数Redis节点才算成功。但红锁本身在工程界有争议因为它在极端网络分区下依然存在理论漏洞。我的建议是面试可以提RedLock这是加分项但实际生产中大多数场景用单节点Redisson锁加合理超时已经够用真到了需要RedLock的级别可能要考虑更可靠的一致性协调服务。5.3 幂等性与锁释放的边界分布式锁里还有一个容易忽略的坑——锁的释放必须判断持有者。最常见的错误是线程A拿到锁业务超时后锁自动释放线程B拿到同一把锁此时线程A业务完成执行DEL命令把线程B的锁删了。这会导致两个线程同时进入临界区。解法是锁的value存一个唯一标识比如UUID删除前先比对# 伪代码比较value后再删除必须用Lua保证原子性 if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end面试时能答出“释放锁前要校验唯一标识”基本就能把锁释放这个考点覆盖住了。如果再能提到Lua脚本保证原子性会更出彩。6. 缓存治理与线上实战面试题之外的硬功夫6.1 大key、热key、key集中过期三类线上事故的排查套路“Redis缓存治理”这个词在热搜里出现频率很高它本质上说的是线上Redis日常运维的一系列动作。面试官也会问“线上Redis出过什么故障怎么排查的”这时候光背理论就不够用了得有实战细节。大key是指单个key的value过大比如一个Hash里有几百万个字段或者一个String value有几十MB。大key的隐患是阻塞Redis单线程删除大key时Redis需要释放大块内存可能卡顿几秒读取大key会占用大量网络带宽。排查方法是用redis-cli --bigkeys命令扫描它会找出每种数据类型里最大的key。治理手段包括拆分大key、压缩value、对大key单独设置淘汰策略以及用UNLINK命令异步删除。热key是指某个key的QPS异常高比如网红商品的库存key。热key会把流量都压到Redis的某一个分片上造成集群负载倾斜。治理方案有热key加随机后缀分散到多个key、本地缓存兜底、读写分离。注意热key的读取不适合用分布式锁因为锁本身就是串行的会把热点放大。key集中过期会引发前面说的雪崩排查时要看监控里expired_keys的曲线如果有陡增的波峰说明存在集中过期问题。6.2 序列化问题RedisDesktopManager里看到的全是乱码连接工具相关的热搜词出现频率不低这背后其实藏着一个很常见的问题——序列化。很多人用Spring的RedisTemplate存数据打开Another Redis Desktop Manager或RedisInsight一看key是一堆\xAC\xED\x00\x05t...这样的乱码value也读不出来一脸懵。原因是默认的RedisTemplate使用JDK序列化把Java对象的类信息和二进制流都写进了Redis。解决方案是自定义序列化器value用Jackson JSON序列化key用String序列化。比如RedisTemplateString, Object template new RedisTemplate(); template.setKeySerializer(new StringRedisSerializer()); template.setHashKeySerializer(new StringRedisSerializer()); template.setValueSerializer(new GenericJackson2JsonRedisSerializer()); template.setHashValueSerializer(new GenericJackson2JsonRedisSerializer());还有一个更简单的方法直接用StringRedisTemplate手动把对象转成JSON字符串。缺点是每次都要自己序列化优点是可控性强。面试时如果聊到“Redis序列化”你不仅要能说出JDK序列化的缺点最好还能提一句GenericJackson2JsonRedisSerializer会保存class类型信息方便反序列化时还原对象类型。6.3 Docker搭建Redis主从的常见姿势本地开发或快速验证主从架构时Docker是最省事的方式。我常用的一条命令就能起一个主节点docker run -d --name redis-master -p 6379:6379 redis:7.0 redis-server --appendonly yes从节点再起一个容器用--slaveof或--replicaof指向主节点docker run -d --name redis-slave -p 6380:6379 redis:7.0 redis-server --slaveof 172.17.0.1 6379注意两点第一容器内的Redis默认没有密码如果开了requirepass从节点要配置masterauth第二容器重启后IP会变生产环境别用IP硬编码要用服务发现或固定网络。这些细节面试官如果问“你搭建过主从吗”你能说出这些坑比单纯背原理有说服力得多。6.4 缓存命中率与缓存治理指标最后补充一个容易被忽略但面试偶尔会冒出来的点怎么评估缓存效果。很多人会答“看命中率”但面试官更希望听到你有一套量化方法。常用的指标有缓存命中率keyspace_hits / (keyspace_hits keyspace_misses)可用INFO stats命令查看。缓存覆盖率有多少比例的读请求走了缓存评估key设计是否合理。过期淘汰率evicted_keys曲线判断maxmemory设置是否合理。命中率不是越高越好。过高的命中率可能说明你缓存了太多低频数据收益低过低的命中率说明key设计有问题或者缓存空间不足导致频繁淘汰。我一般建议命中率保持在85%以上低于这个值就要考虑增加内存或调整淘汰策略。7. 容易串台的概念Spring三级缓存、MyBatis缓存与Redis缓存7.1 三个“缓存”不是一回事别在面试时答串热搜词里有“Spring三级缓存原理”和“MyBatis缓存”这两个经常和Redis缓存混在一起但它们在面试里完全是不同的问题方向。Spring三级缓存解决的是Spring IOC容器中循环依赖的问题。它有三个Map一级缓存存放完整的Bean二级缓存存放早期暴露的Bean还没完成属性填充三级缓存存放ObjectFactory用于生成代理对象。核心逻辑是当A依赖B、B依赖A时先实例化A暴露一个早期引用让B能注入AB创建完后再回头完成A的剩余初始化。这是Spring框架内部的机制和Redis没有直接关系。MyBatis缓存是ORM框架层面的缓存一级缓存是SqlSession级别的默认开启同一个SqlSession内重复查询会走缓存二级缓存是Mapper级别的需要配置开启多个SqlSession共享。它的作用是减少数据库查询但也没用到Redis。面试时如果面试官问“聊聊缓存”你要先确认他问的是Redis缓存还是Spring缓存还是MyBatis缓存否则很容易答错方向。一个聪明的回答方式是“您说的缓存是指Redis这种分布式缓存还是Spring三级缓存或者MyBatis缓存这几个我都能聊但方向不同。”这样既展示了知识面又避免答串。7.2 本地缓存与分布式缓存的协同还有一个容易被问到的衍生题本地缓存和Redis缓存怎么选、怎么配合。本地缓存的优点是快没有网络IO缺点是每个节点各存一份存在数据不一致问题而且占用JVM堆内存。Redis缓存的优点是集中管理、天然一致缺点是多一次网络IO。实际项目中常见的是两级缓存先查本地Caffeine缓存没命中再查Redis再没命中才查数据库。这个方案能在Redis抖动时保护系统但代价是本地缓存的一致性更难保证。写操作后要主动失效本地缓存通常配合消息广播或版本号机制。面试官如果追问“本地缓存怎么更新”你可以提到两种方案一种是用Redis Pub/Sub广播失效消息另一种是给本地缓存设置极短的过期时间比如30秒牺牲一点点一致性换实现简单。后一种方案在小规模集群里非常实用。8. 我的实操体会写到这里该说的考点基本都覆盖了。最后分享一点个人经验面试官问Redis最想听到的不是标准答案而是你在真实场景里的选择。比如“缓存击穿你用的互斥锁还是逻辑过期”如果你能说出“我考虑到重建缓存放了太多外部依赖怕锁超时所以用的逻辑过期代价是允许几秒钟脏读”这个回答的质量远高于背诵“互斥锁是XXX逻辑过期是XXX”。我自己踩过最大的坑是缓存击穿的互斥锁实现——当时图省事用了SETNX加EXPIRE两段式结果某个深夜进程重启把EXPIRE漏掉了第二天早上锁僵死在那所有请求全部穿透到数据库运维电话被打爆。从那之后我写任何分布式锁都坚持用原子命令或Redisson再也不手写拆两步。另外一个小技巧准备Redis面试题时不要光看答案要把每个方案在脑子里过一遍“如果我上了浓烟环境这个方案会带来什么新问题”。比如延迟双删你一旦说出来面试官大概率追问“第二次删除失败怎么办”这就是考察你有没有深入想过方案的边界。你能接住追问这场面试关于Redis的部分基本就稳了。这篇东西不是让你背的是让你在面试前把思路理顺的。看完之后建议你把每个方案都用自己的话重新讲一遍讲给同事听也行录音自己听也行。能讲顺了就算真的吃透了。