后台隔三差五就有朋友拿着网上的Redis题库来问我“这50道题答案靠谱吗是不是背完就能过”我的回答一向是背题保底但保不了你拿高评价。Redis面试题看起来散实际上是有主线的。面试官不会平白无故问你“SDS是什么”他问的是你有没有在真实环境里排查过问题。这篇东西我就按自己面试和被面试的经验把最常见、最容易踩坑的50道Redis缓存题拆成五组每道题都附上解题思路和加分点方便你自测也能当临考前的速查表。1. 先别急着背题Redis面试到底在考什么1.1 五个考察维度我自己面人时Redis相关问题的出题思路基本围绕五条线第一是基础功底数据类型、持久化、过期淘汰这个答不上来基本就可以结束了第二是缓存三兄弟和一致性这属于线上实战题没有真实处理经验很容易露馅第三是分布式特性锁、集群、哨兵、脑裂这些考察的是你系统设计的深度第四是底层原理SDS、跳表、IO多路复用考察的是你有没有研究过源码第五是工程化和治理序列化选型、热Key处理、监控告警考察的是你的运维意识。这五条线基本覆盖了从校招到高P的绝大多数Redis问题。你能答到哪一层直接决定面试官对你定位的上限。我带过不少候选人最可惜的就是基础题背得溜一追问细节就变成“我记得好像是……”这种回答比直接说“没研究过”更败好感。1.2 不同年限、不同岗位准备重心不一样面试官的题海不是随机的而是跟着简历走的。3年以下的候选人我基本只问基础加缓存三兄弟3到5年的我会追问锁和一致性的细节5年以上的我重点问治理和极端场景——热Key打爆了怎么降级、大Key删不掉怎么处理、集群扩容时数据怎么迁移。如果你面试时发现对方问的问题超出了你的预期年限先别急着觉得是压力面大概率是你简历上写了相关项目。简历上写过的Redis相关内容必须往死里抠细节这是我见过最多人翻车的地方。比如你在项目里写了“使用Redis做分布式锁”那就得把setnx、过期时间、看门狗、误删别人锁这些细节全部准备到位。2. 基础篇数据类型、持久化与淘汰策略2.1 14道基础题自测清单基础题属于“基本功”如果答起来卡顿先别急着面试回去补课。先过一遍清单Redis为什么这么快答案至少要涵盖内存、IO多路复用、单线程、高效数据结构四点。Redis是单线程还是多线程注意6.0之后IO读写有多线程命令执行仍然单线程。String的底层结构是什么SDS为什么要用SDS而不是C字符串。List、Hash、Set、ZSet各自适合什么场景排行榜、去重、缓存对象、简单消息队列。Redis为什么用跳表实现ZSet而不是红黑树RDB和AOF有什么区别什么时候用哪种能混合吗AOF重写是什么为什么要重写怎么触发Redis的过期删除策略是什么惰性删除加定期删除。内存淘汰策略有哪几种至少说出LRU和LFU的区别。手写一个LRU怎么做LinkedHashMap或者哈希表加双向链表。数据明明设置了过期时间为什么还占着内存过期key没被访问也没被清理。String最大能存多大512MB。Redis默认有16个库能随便用吗答案是不能生产环境基本只用一个库。线上Redis键太多怎么快速扫描keys慎用大库用scan。这几道题我几乎每次面试都会问到。别看简单很多人答完第一题就开始飘后面一追问细节就露馅。2.2 高频题深挖为什么快、单线程、数据结构第一题的“为什么快”是面试官最常用的开场问题也是区分背诵型和实战型的分水岭。老实说纯内存是根本IO多路复用解决的是网络瓶颈单线程避免的是竞态和上下文切换高效数据结构解决的是操作时间复杂度。如果你想体现深度建议主动提一句“Redis 6.0引入了多线程IO但命令执行依旧单线程因为瓶颈在网络IO而不是CPU”这句话一说面试官大概率会往下追问这时候你把线程模型讲清楚印象分会明显不一样。第3题关于String底层很多人知道SDS却说不清好在哪。核心就三点O(1)获取长度、杜绝缓冲区溢出、减少修改字符串时的内存重分配次数另外二进制安全。面试的时候最好用“C字符串读长度是O(n)、拼接可能溢出”来反衬SDS的价值。ZSet为什么用跳表不用平衡树也常被追问跳表实现简单、范围查询方便而且层数随机化在并发写场景比红黑树好实现得多。第4题数据类型最容易答成背定义。面试官听你背完“String是字符串、List是列表”没有任何意义。更好的答法是带场景String存对象和计数器List做简单的消息队列Hash存商品详情这种对象字段经常变动的数据Set做用户标签去重ZSet做排行榜和延迟队列。每个数据结构都说出至少一个业务场景面试官才知道你真的用过。2.3 过期与淘汰不起眼却最能看出深浅的两道题第8题过期策略最标准的答法是“惰性删除定期删除”每次访问key时检查是否过期过期就删同时后台每隔一段时间抽取部分key检查删除。我习惯在答完之后补一句“主从复制场景下过期key删除是靠主节点发DEL命令通知从节点而不是从节点自己判断”这句话能体现你真正看过Redis源码或者排查过缓存不一致面试官会记下这个加分点。第9题内存淘汰先把8种策略说全再谈生产环境怎么配。重点区分volatile开头的策略只淘汰设置了过期时间的keyallkeys开头的对所有key生效LRU是最近最少使用LFU是频率最低优先淘汰。面试官经常追问“为什么Redis 4.0引入LFU”因为LRU在扫描式遍历的场景下会被一次性流量污染比如一个大促活动页瞬间访问大量商品LRU可能把真正长期热门的key挤掉LFU能更好地识别真正的热点。另外提一下4.0之前默认noeviction写满直接报错现在更推荐把maxmemory-policy配成allkeys-lru但热点明显的场景建议用LFU保护关键数据。3. 缓存三兄弟与一致性线上翻车高发区3.1 12道进阶题清单缓存与一致性这一部分最容易分出高下因为它们都来源于线上事故。先过清单缓存穿透是什么如何预防缓存击穿和穿透有什么区别缓存雪崩是怎么发生的怎么解决布隆过滤器原理是什么有什么缺点缓存和数据库双写时先更新谁为什么延迟双删是怎么实现的能保证强一致吗什么场景下删除缓存失败怎么补救缓存预热怎么做上线时如何避免第一波流量压垮数据库多级缓存怎么设计Redis之外还有哪些层空值缓存要注意什么缓存倾斜和热Key有什么关系如何保证最终一致性消息队列在缓存一致性里扮演什么角色3.2 三兄弟场景拆解别把答案背成一锅粥穿透、击穿、雪崩这三个词很多人背得滚瓜烂熟但一问到“你们线上怎么处理的”就变成背书。给一个场景化的答法穿透是查询了根本不存在的数据比如用一个不存在的user_id去查每次都会打到数据库。解决的核心思路是挡住“空”一是缓存空值设置一个较短的过期时间二是用布隆过滤器用极小内存成本挡住大量无效查询。这里要提一句布隆过滤器存在误判率而且不支持删除所以更精细的业务可以用布谷鸟过滤器不过面试能说到误判率这一点已经合格了。击穿说的是某个热点key过期瞬间大量请求同时打到数据库。两个经典方案互斥锁和逻辑过期。互斥锁很简单缓存失效时只放一个线程去数据库加载其他线程等待逻辑过期是缓存里不设置物理过期时间而是存一个过期标记发现过期就异步去刷新。如果面试官追问区别就说互斥锁会有一小段时间的阻塞和等待逻辑过期能保证接口始终有数据但会短暂返回旧数据需要业务接受。雪崩是大量key同时过期或者Redis本身宕机。区分开这两个原因是加分项前者通过过期时间加随机值、集群分片打散后者靠哨兵或Cluster做高可用再加本地缓存兜底也就是多级缓存。能主动讲出“过期时间不要用固定值用3600加上随机0到300秒”的人说明真的处理过缓存雪崩。3.3 缓存一致性延迟双删到底删几次第19、20、21题是最近几年的“网红题”。先说结论没有完美的同步强一致方案现实里追求的是最终一致。最正统的Cache Aside模式读时先读缓存没有就查数据库再回填写时先更新数据库再删除缓存。为什么删除而不是更新缓存因为更新缓存有概率把写一半的脏值写进去而且如果写操作频繁缓存会积累大量无效写删除的话下次读再回填写操作本身不会污染缓存。延迟双删是删除缓存后等一段时间再删一次核心是处理“先删缓存、然后并发读写导致缓存被回填脏数据”的情况。但很多人理解错了一点延迟双删并不能保证强一致它只是把不一致窗口缩小。真正想兜底得靠binlog订阅或者消息队列异步删除删除失败时重试。我面试喜欢听到的回答是“延迟双删在绝大多数场景够用但如果对一致性要求真高我会用canal监听binlog解析出变更后删缓存确保删除操作有重试机会。”第24题空值缓存最容易忽略的细节是空值也要设置过期时间而且要比正常数据短否则大量不存在的数据会把Redis内存打爆另外还要防止“空值过期后请求再穿透”的振荡可以考虑在空值上再加一层短TTL。第22题缓存预热别只答“写个脚本提前灌数据”要答出预热前的容量评估、key分布、过期时间分散以及预热过程中如果服务已经上线要对第一波流量做兜底比如限流、降级、熔断配合着用。3.4 热Key与大Key治理能力才是高级感第25题热Key典型场景是秒杀、热门直播。应对手段从轻到重可以这样讲本地缓存兜底热点、Redis集群把热Key散列到多个节点、给逻辑层做限流和降级。面试时最好的回答是结合你自己的项目说清楚“当时怎么发现热Key的”比如监控到Redis单分片CPU飙高或者抓包看到大量GET同一个Key。大Key问题更隐蔽一个Big List几百万元素del的时候直接阻塞Redis这在生产上是事故级的问题。处理办法首先要发现用slowlog、redis-cli --bigkeys先扫一遍然后拆分把大List改成分片或者把大Hash拆成多个Hash删除时不要直接del用unlink异步删或者渐进式删除hscan加hdel分批删。这一整段回答如果能带出“我曾经因为大Key导致业务超时”的案例含金量会直线上升。4. 分布式锁、集群与高可用4.1 12道分布式高可用题清单对经历过生产环境的人来说这里才是Redis面试的硬核区。先列清单分布式锁用Redis实现核心命令是什么setnx加expire能保证原子性吗锁的value为什么要唯一锁过期了但业务还没执行完怎么办Redisson的看门狗机制了解吗RedLock是什么为什么有人批判它Redis主从复制是同步还是异步丢了数据怎么办哨兵机制的工作原理是什么Cluster集群的哈希槽是怎么分配的集群为什么用16384个槽Cluster模式下scan、批量操作为什么有问题脑裂是如何产生的Redis怎么尽量规避4.2 分布式锁从setnx到Redisson的进化第27、28题几乎是必问。早期的实现是setnx加expire两条命令分开写这是经典的原子性问题——如果setnx成功但expire没执行锁永远不释放。所以至少要用set key value nx ex seconds把两条操作合并成一条。这是最普通的答法。想拿高分要往下说三层。第一value必须唯一比如UUID或业务ID释放锁时用Lua脚本先比较value再删除防止误删别人的锁。第二锁过期时间怎么定设置得太短业务没跑完锁就断了设置得太长万一宕机又要等很久所以要有续期机制这就是Redisson的看门狗——默认30秒每10秒续期一次业务执行完主动释放。第三Redis主从异步复制会导致锁丢失比如主节点写入了锁还没同步给从节点就宕机了从节点顶上来别的线程又能抢到同一把锁所以RedLock才想用多个独立节点来投票。但同时要说清楚RedLock在业内是有争议的它对系统时钟、网络分区有依赖很多团队宁可zookeeper也不用RedLock。能把争议说清楚比盲目吹RedLock高级得多。面试官问到这里基本就知道你是真用过Redis做锁而不是只看过博客。4.3 主从、哨兵与集群可用性三道坎第33题主从复制记住主从之间的数据复制默认是异步的所以主节点刚写完就宕机数据在从节点上可能还没到这会导致数据丢失。Redis从2.6开始推荐主节点开启min-replicas-to-write从节点数或者延迟不满足要求时主节点拒绝写请求用可用性换可靠性。这个细节能看出你认真配置过生产Redis。第34题哨兵核心讲清楚三个角色监控、通知、自动故障转移。哨兵节点之间通过投票选出leader来执行故障转移然后从候选从节点里选master标准通常是优先级、复制偏移量、runid。另外提醒一个容易被忽略的点哨兵至少三个、奇数个防止脑裂后投票无法达到多数。第35、36题Cluster最关键是哈希槽的概念。16384个槽每个key做CRC16再对16384取模落到某个槽槽分布在多个主节点上。为什么不直接用一致性哈希因为槽的设计让数据分布和迁移都更好控制。至于为什么是16384可以提一个说法16384是2的14次方足够大又不会让心跳包太大实际使用中节点数很难超过这个数量级。第37题是实战题Cluster模式下scan只能保证单节点内部的一致性跨节点扫描会有重复和遗漏mset、mget这类多key操作如果key不在同一个槽直接报错。这时候要用hash tag比如user{1}:profile和user{1}:orders让同一业务的多key落在同一个槽。能主动提到hash tag的人基本是有过集群迁移经验的。5. 底层原理与实战收官5.1 最后的12道题前38道题已经覆盖了绝大部分高频考点这里再补上最后一批也是最能拉开区分度的一批为什么Redis用跳表而不用红黑树做ZSet渐进式rehash是怎么个渐进法Redis的IO多路复用为什么比多线程好Redis 6.0多线程IO到底改了啥内存碎片产生的原因怎么处理Redis的慢查询日志怎么配置怎么定位慢命令线上Redis内存突然飙升怎么排查Redis和数据库的序列化方式怎么选为什么生产环境建议关闭keys命令Redis可以做消息队列吗和专门MQ的区别缓存key怎么设计才清爽如何复习Redis面试题才能避免背了忘、忘了背5.2 底层原理三道必答源码题第39题跳表和红黑树的对比重点在于范围查找。红黑树虽然也是O(logN)但它的中序遍历需要递归或栈范围查询实现复杂跳表按层索引做范围查找非常自然而且插入删除只需要调整前后指针并发场景下比红黑树更容易实现。再加上Redis本身只需要排序和范围操作不需要删除最大最小值等复杂操作跳表是更务实的选择。第40题渐进式rehash这是哈希表扩容避免阻塞的关键。简单说就是rehash不是一次性完成而是分多次每次增删改查时顺带迁移一些桶同时维护两个哈希表查询时先查正在使用的再查迁移中的。答这个问题要补一句“如果一次性rehash大量数据Redis主线程会卡顿”这就带出了单线程模型的取舍。第41题IO多路复用把epoll的机制讲清楚内核帮你监听一堆fd哪个fd可读可写了再通知你处理。Redis把事件循环封装成一个主线程连接事件、读写事件、定时任务都在这一个线程里轮询。核心思考点是Redis的瓶颈从来不是CPU而是网络IO和内存所以用单线程加IO多路复用是最省事的方案。如果面试官追问“为什么6.0又加多线程”那是因为Redis每秒能处理十万级命令网络协议解析和IO读写消耗开始占据大头把这些部分放到多线程里主线程专注命令执行收益才足够明显。5.3 工程治理内存飙升、序列化与消息队列第44、45题慢查询和内存排查属于一定要讲案例的题。我一次线上排查Redis内存从2G涨到6G一开始怀疑是业务缓存泄漏后来用redis-cli --bigkeys扫了一遍发现是一个大Hash忘记设置过期时间而且某个字段一直在被高频写入。处理方式很简单给业务key加过期时间把这个Hash按业务id拆掉。这种案例在面试里非常加分因为比任何理论都更能证明你处理过真实问题。第46题序列化很多人踩过坑。默认的JdkSerializationRedisSerializer会把对象序列化成带有类全名的二进制可读性差、内存占用高换成JSON之后内存直接降了一半。面试官喜欢追问“为什么有的对象序列化成JSON会报错”因为对象里有循环引用或者没有默认构造函数所以生产上更推荐GenericJackson2JsonRedisSerializer加手动指定class或者干脆用protobuf。第47题keys命令是典型的反模式因为keys会遍历整个键空间单线程下所有请求都会被阻塞。替代方案是scan但scan不能保证完整不遗漏适合分批处理大量key的场景。答这道题记得用“线上事故”来佐证同事在2亿key的实例上执行keysRedis直接卡了十几秒这比任何理论都有说服力。第48题Redis做消息队列要区分版本List的BLPOP是早期的队列模式发布订阅方式不持久化Stream则是从Redis 5.0开始提供的正式消息队列能力支持消费者组、ACK、Pending。但和RabbitMQ、Kafka相比Redis的短板是消息堆积后的内存压力、不擅长海量堆积消息所以适合轻量级场景。5.4 收尾答题的姿势比答案本身更值钱最后想说的是第49题和第50题其实是给自己做复盘用的。缓存key设计得好线上能少掉一半问题我有一次接手别人的项目发现所有缓存key都长成“xxx_yyy_zzz”没有统一前缀排查问题非常痛苦。后来统一改成“业务:模块:对象:id:场景”比如“user:profile:9527:summary”一眼就能看出是哪个业务、哪个对象、哪个字段。至于第50题怎么复习才不容易忘我自己带人的经验是不要按题号背要按“故事”背。把缓存穿透的布隆过滤器、缓存击穿的互斥锁、缓存雪崩的随机过期时间串成一个完整的“缓存治理”叙事把从setnx到看门狗到RedLock的演进串成“分布式锁”叙事把主从、哨兵、Cluster串成“高可用”叙事。面试官问哪个你都能从故事里抽出来讲而不是从记忆里抽出来背。这样哪怕临场紧张也能说出自己真正做过、思考过的内容。