这两年面试后端岗位，Redis几乎是必考题。我前前后后帮人做过很多次模拟面试，自己也参与过不少校招社招的候选评估，几乎每一轮都会有人栽在同一个地方：只背了答案，没接住追问。这篇把Redis面试里最高频的一批题目重新梳理了一遍，每题都从“面试官到底想听你讲什么”这个角度拆开讲，而不是简单堆结论。不管你是准备校招、还是在职跳槽，把这套内容吃透，Redis这一关基本不会拖后腿。
1. 缓存三兄弟：穿透、击穿、雪崩，这道题决定你过不过第一轮
会问缓存的人一般都会从“缓存穿透”这个词切进来。很多候选人能说出“查一个不存在的数据”，但要完整回答应对手段、适用场景、引入的新问题，就含含糊糊了。这类题目之所以高频，是因为它直接考察你对自己系统里缓存层有没有整体认知，而不是单纯考概念。
1.1 缓存穿透：布隆过滤器是答案，但不是唯一答案
先明确定义：缓存穿透指请求的数据在缓存和数据库里都不存在，每次请求都直接打到数据库。如果这是一个被大量刷的接口，数据库很快会被压垮。
一个完整的回答应该有三层：参数校验、空值缓存、布隆过滤器。
参数校验是最容易被忽略的。比如一个查询商品详情的接口，商品id必然有格式约束，负数、超长id、明显不存在的枚举值，直接在接口层拦截掉，根本不该进缓存逻辑。很多面试者一上来就谈布隆过滤器，反而把最简单的防线漏掉了。
空值缓存就是把查询结果为空的情况也写进缓存，并设置一个较短的过期时间，比如30到60秒，避免同一批恶意id反复穿透到数据库。这里有个坑：空值本身也是key，如果攻击者用随机id大量构造空key，缓存里会塞满无效数据。所以空值也要控制总量，必要时配合接口限流。
布隆过滤器是第三层。它用很小的内存代价挡住绝大多数不存在的key，但要知道它有误判率，只会告诉你“一定不存在”和“可能存在”。所以它筛不掉全部请求，被放过去的那一小部分仍然要靠空值缓存兜底。真正做方案的时候，布隆过滤器的bitmap大小和哈希函数个数要按预估key数量和期望误判率来算，公式大概是m = -n * ln(p) / (ln2)^2，n是预估key数，p是期望误判率。实际项目里可以直接用现成实现的布隆过滤器组件，省去自己踩内存和哈希分布的坑。
面试的时候把这三层关系说清楚，比单纯背出“布隆过滤器”五个字有价值得多。
1.2 缓存击穿和雪崩的区分与兜底方案
缓存击穿和缓存雪崩经常被混在一起说。击穿是单个热点key过期，一瞬间大量请求穿透到数据库；雪崩是大批量key同时过期，或者Redis整体不可用，导致大面积请求落到数据库。一句话总结：一个是点，一个是面。
击穿的主流方案是互斥锁。发现缓存没命中时，先尝试拿锁，拿到锁的线程去数据库查询，查完回写缓存；拿不到锁的线程短暂等待后再重试。锁可以用Redis的set命令，比如SET lock:key user_id NX EX 5，释放锁时建议用Lua脚本保证“判断是自己持有再删除”的原子性，否则高并发下很容易误删别人刚拿到的锁。
另一个思路是逻辑过期。不真的删除key，而是把过期时间放在value里，发现逻辑过期后先返回旧值，再异步去刷新缓存。很多高并发项目实际用的是这个方案，因为它不会因为加锁而阻塞大量请求，代价是用户可能短暂看到旧数据。
雪崩的应对就要分层了。首先在过期时间上做文章，给各个key的过期时间加一个随机偏移，比如30到300秒的随机值，避免集体失效。其次保证Redis本身高可用，主从加哨兵或者集群，别让单点故障变成雪崩的源头。最后数据库层面做限流和熔断，兜住最坏情况。
面试官经常接着追问：你项目里到底用了哪种组合？这时候要把方案落回自己的业务，比如某系统的商品详情场景里，热点商品用逻辑过期，普通商品用固定过期加随机偏移，业务侧再挂一层本地缓存。有具体场景的答案才算真正的答案。
2. 数据结构的底层设计，Redis面试中最容易拉开的差距
Redis快，很多人会答“因为它是内存数据库”。这只能算半个答案，真正能拉开差距的是底层数据结构的设计。这一类题目非常适合面试官步步追问，从“Redis有哪些数据结构”一路问到“为什么用跳表不用红黑树”。
2.1 五种基础类型背后的数据结构与设计动机
String类型底层可能是int、embstr或者raw。当一个字符串可以解析成整数值且长度较短时，Redis会直接按整数存储；短字符串用embstr，把对象头和字符串内容放在一块连续内存里，一次分配搞定；字符串超过阈值后就转成raw，用SDS动态字符串存储。
SDS和C语言的char数组最大的区别是：SDS记录了长度，获取字符串长度是O(1)操作；SDS会在尾部预留空闲空间，减少字符串追加时的内存重新分配次数；SDS是二进制安全的，字符串里带\0也不影响数据完整性。
List在Redis 3.2版本以前用压缩列表或双向链表，3.2之后引入了quicklist，把双向链表和压缩列表合在一起。Hash元素少且值小的时候用压缩列表，超过阈值转成hashtable。Set也有类似逻辑，元素全是整数时用整数集合，否则用哈希表。ZSet则用压缩列表或跳表加哈希表。
这些细节面试官不一定要求你背到源码级别，但说出压缩列表、整数集合、SDS这些名词，并且能解释“为什么小数据量用连续存储、大数据量用跳表或哈希表”，会比只会说“Redis是key-value存储”的候选人高出一个身位。
2.2 跳表为什么能撑起有序集合
ZSet需要同时支持两种查询：按member精确查找score，以及按score范围查询数据。哈希表能解决第一种，但无法高效处理范围查询；普通链表插入快，范围查询却要逐节点遍历。跳表通过多级索引把查找复杂度从O(n)降到O(logn)。
跳表实现起来比平衡树简单，不需要复杂的旋转操作，节点层级通过随机数决定，长期运行下来结构依然是近似平衡的。Redis源码里对ZSet的排序做了细节处理：score是主排序键，member是次排序键，所以即使两个元素score相同，也能按member的字典序排序。
面试记忆点：每次插入新节点时，有概率晋升到更高一层，通常给一个1/4的晋升概率，层数越高出现概率越低。这种随机化让跳表在大多数场景下性能稳定，同时实现和调试难度远低于红黑树。能答到“跳表支持范围查询”和“按字典序排序”，就已经抓到这道题的核心了。
排行榜功能是ZSet最典型的应用场景。往一个ZSet里写入用户id和分数，然后通过ZREVRANGE取前N名，分数变化时再ZINCRBY，整个排行榜的实现成本非常低。
3. 持久化：RDB和AOF怎么答才不掉坑
很多人会说“Redis持久化有两种，RDB和AOF”，然后就没有下文了。其实这个知识点非常适合往下挖，面试官只要顺着追问一句“重启时先加载哪个”，就能筛掉一批只会背名词的人。
3.1 RDB触发机制与bgsave的原理
RDB是快照持久化，把某个时间点的全量数据写入一个二进制文件。它有手动触发和自动触发两种方式：手动通过save或bgsave命令，自动则根据配置文件里的save规则判断。比如save 900 1表示900秒内至少有1次写入就触发快照。
这里有个重点：save和bgsave有本质区别。save会阻塞主进程，线上基本不会用；bgsave会fork一个子进程去执行快照生成，主进程继续响应请求。fork之后的父子进程共享同一份内存，通过操作系统的写时复制机制，只有父进程修改数据时才会复制对应内存页。所以bgsave并非完全不耗资源，如果写入量很大，fork和内存复制都会带来开销，实测时要关注fork耗时，超过几百毫秒就需要警惕。
还有一个经典追问：RDB能保证数据不丢吗？答案是显而易见的，默认配置下会丢最后一次快照之后的所有写入。如果业务对数据丢失很敏感，就必须让AOF参与进来。
3.2 AOF重写与fsync策略
AOF记录的是每一条写命令，恢复时重放命令。它有三种刷盘策略：always、everysec、no。always每条命令都刷盘，数据最安全但性能损失最大；everysec每秒刷一次，最多丢一秒数据；no完全交给操作系统决定什么时候落盘，丢的数据最多。生产环境多数用everysec，这个选择本身就是一道送分题：你要在性能和可靠性之间做取舍，而不是追求极端。
AOF文件会随着写入不断膨胀，所以需要重写。很多人以为重写是去修改旧文件，其实不是。重写是基于当前内存里的数据状态，生成一份新的最小命令集，然后替换旧文件。重写过程也由子进程处理，父进程在重写期间新收到的写命令会被缓存起来，等子进程完成后再合并进新文件。
记忆点：AOF重写触发条件是auto-aof-rewrite-percentage和auto-aof-rewrite-min-size，比如默认文件超过64MB并且比上次重写时增长了100%，就会触发自动重写。生产环境里需要根据写入量调整这两个参数，避免高频重写消耗磁盘IO。
3.3 混合持久化：许多人没听过的加分项
混合持久化从Redis 4.0开始引入。开启之后，AOF重写生成的文件头部是RDB格式的二进制快照，后面再追加AOF格式的增量日志。这样重启恢复时，先加载RDB部分快速恢复全量数据，再重放少量增量日志，恢复速度比纯AOF快，数据完整度又比纯RDB高。
这个知识点虽然已经出现好几年了，但放在面试里还是能筛选人。面试官如果问“你了解混合持久化吗”，能清楚说出文件格式和恢复顺序，属于明显的加分项。再深一层，Redis重启加载时的优先级是：AOF开启且AOF文件存在时优先加载AOF，否则加载RDB。原因很简单，AOF相对完整，宁可多花一点恢复时间，也要减少数据丢失。
4. 高可用架构：主从复制、哨兵、集群三条链路
高可用是生产环境的硬话题。面试题大多围绕三个链路展开：主从复制的流程、哨兵如何做故障转移、集群怎么分片和重定向。这一部分考的是候选人有没有真正维护过一套高可用的Redis系统，还是只在本地单机玩过。
4.1 主从复制的完整流程与常见断点
从节点启动后会发送psync命令，主节点根据复制偏移量和runid判断是走全量同步还是部分同步。首次连接或者数据差异太大时做全量同步：主节点生成RDB快照传给从节点，同时把期间新写入的命令放进复制缓冲区，最后把增量命令补发给从节点。
如果网络抖动导致短暂断线，只要从节点上报的偏移量还在主节点的复制积压缓冲区内，就能走部分同步，只补发缺失的增量命令。这个过程也叫增量同步，效率远高于全量同步。所以面试里问到“主从断开了怎么办”，不要张口就说重新全量同步，先判断能不能增量续传。
生产里需要注意：全量同步时RDB生成和传输会占用大量网络带宽和磁盘IO，尽量不要在业务高峰期扩容从节点。主从节点之间的网络延迟也不要忽略，延迟过大会导致从节点数据明显落后，读操作会读到旧数据。
4.2 哨兵如何完成故障转移
哨兵是独立部署的进程，用来监控主从集群。它通过三个定时任务向主从节点发送心跳，其中一个哨兵发现主节点不可达时，会标记为主观下线；当多个哨兵都判定主节点不可达，状态升级为客观下线，触发故障转移流程。
故障转移过程是：哨兵集群先选举一个leader，由leader负责选择一个从节点执行slaveof no one，让它成为新的主节点，然后通知其他从节点重新指向新主。选从节点时不是随机选，而是看配置优先级、复制偏移量是否最接近主节点、runid大小，综合排序选出最合适的一个。
能把这个顺序完整讲清楚，比背一句“哨兵可以自动切换”强太多。深入一些的追问还会涉及哨兵本身的高可用，所以哨兵通常也要部署多个节点，避免哨兵单点导致整个监控链路失效。
4.3 集群分片与MOVED、ASK重定向
集群模式把数据分成16384个槽位，每个主节点负责一段槽。写入一个key时，客户端或任意节点先用CRC16算法计算key的哈希值，再对16384取模，就能定位到目标槽位，然后请求转发到负责该槽的节点。
这里有个经典考点：客户端连接的是A节点，但key的槽位在B节点上，A节点会返回MOVED错误，并带上目标节点地址，客户端需要根据这个重定向重新发送请求。MOVED表示槽位已经稳定归属于某个节点，客户端可以缓存这个映射关系。
另一个容易混淆的是ASK。槽位迁移过程中，部分key可能已经从A节点迁到了B节点，此时A会遇到一个正在迁移中的key，它会返回ASK错误，让客户端带上ASKING命令去B节点请求。ASK是迁移过程中的临时状态，不改变客户端对槽位归属的长期认知。能把MOVED和ASK的区别说清楚，基本就能通过这一段。
集群模式的另一个特性是安全边界：只要有一部分槽位没有可用节点，整个集群就会拒绝服务，返回CLUSTERDOWN。这是为了避免读写过程中数据不完整，所以扩缩容时要格外小心，先迁移槽位再下线节点。
5. 生产环境排查题：慢查询、大Key、内存碎片
基本功问完，面试逐渐转向实战。有没有真正处理过生产环境的问题，问几个排查细节就能看出来。这类题不需要你背得很深，但必须给出可执行的操作路径。
5.1 慢查询日志怎么定位与调参
Redis提供了慢查询日志机制，通过slowlog-log-slower-than配置阈值，slowlog-max-len控制保留条数。执行时间超过阈值的命令会被记录下来，然后用SLOWLOG GET查看。
这里有个容易犯的错：阈值的单位是微秒，不是毫秒。默认配置往往偏大，线上建议根据接口耗时重新调整，比如调到10毫秒，甚至对高QPS系统调到1毫秒，才能真正捕获慢命令。看日志时需要关注命令名称、执行耗时、参数列表和发生时间，然后配合客户端调用来源定位问题根因。
常见的慢命令有大集合的排序、交集并集、KEYS全量遍历、SMEMBERS返回大集合等。定位到之后，处理思路一般是拆分key、把大集合拆小、让集合操作在业务侧改为增量计算，或者用Scan类命令分批处理，避免一次性全量操作。
5.2 大Key的判定标准与处理方式
大Key没有绝对标准，一般是综合判断：单个String过大，比如超过几MB；一个List、Set、ZSet里的元素数量过多，比如达到几十万甚至几百万；或者单个key占用内存明显高于其他key。
大Key的危害非常实际：网络传输成为瓶颈、阻塞删除操作、拖慢主从同步、导致内存碎片上升、影响cluster模式下的数据均衡。排查时可以直接用自带的扫描命令，比如redis-cli --bigkeys，它会遍历整个实例，输出大key分布情况。
生产环境删除大Key时要格外小心。直接使用del命令会阻塞主线程，尤其在有从节点的情况下，删除的bigkey还会同步阻塞从节点。现在Redis提供了unlink命令来异步删除，这是首选。如果是较老版本，可以用分批删除集合元素的思路，比如List用LTRIM逐步截断，Set用SREM分批移除。
5.3 内存碎片率怎么看
通过INFO memory可以看到内存碎片率，也就是mem_fragmentation_ratio。这个指标是used_memory_rss和used_memory的比值，反映物理内存占用和Redis实际使用的内存之间的差异。
碎片率大于1是正常的，因为内存分配器按固定大小块分配，数据不断增删改之后会产生碎片。如果碎片率明显偏高，比如超过1.5，说明内存浪费严重；如果小于1，则说明Redis可能使用了swap，性能会受到严重影响，这时需要关注物理内存是不是不够用。
处理碎片可以执行MEMORY PURGE尝试回收，但这种方法不一定有效，更稳妥的办法是在从节点上重启或扩容，然后通过主从切换把新节点提升为主节点。很多面试者连这个指标的名字都说不出来，你能主动提到mem_fragmentation_ratio和MEMORY DOCTOR，现场效果会完全不一样。
6. 现场发挥：几个容易翻车的高频追问
最后补充几个面试官喜欢追加的小问题。这些题目看似简单，但往往就是决定offer的最后一个台阶。
6.1 过期key到底是怎么被删除的
答案是惰性删除加定期删除。惰性删除是每次访问key时检查是否过期，过期才删除；定期删除是每隔一段时间随机抽查一部分key，把过期key清掉。之所以不直接扫全量key，是因为大实例里key数量可能上千万，全量扫描代价太高。定期删除不能保证key在过期后立刻被清理，所以两种机制配合使用。
如果大量key在同一时间过期，定期删除会消耗CPU，这也是缓存雪崩的成因之一。所以前面的随机过期时间方案，在这里又呼应上了。
6.2 单线程为什么还这么快
可以从三个方面回答：数据全部在内存中，核心操作是O(1)或接近O(1)；单线程避免了线程切换和锁竞争的开销；I/O多路复用让单线程能同时处理大量连接。Redis 6.0之后引入了多线程I/O，多线程只处理网络读写，真正的命令执行仍然在主线程完成，所以不要被“单线程”三个字误导。
这个问题还有引申：为什么命令执行不改成多线程？因为Redis的瓶颈几乎不在CPU，而在内存和网络，多线程执行命令会引入锁竞争，反而可能降低性能。能从“瓶颈在哪”回答这个问题，段位会高很多。
6.3 缓存和数据库一致性怎么保证
常见的方案是“先更新数据库，再删除缓存”。删除缓存如果失败，需要用消息队列重试，或者订阅数据库的变更日志做异步更新。比“先删缓存再更新数据库”出现不一致的概率更低，但依然有时间窗口。更严格的场景可以用延迟双删：更新数据库后先删一次缓存，等待一小段时间，再删一次，把并发下可能写入的旧缓存清理掉。
这个问题的关键不是背出某个方案，而是承认“强一致很难做到，最终一致是常态”，然后说明自己的业务选型和补偿手段。
我个人带人面试时有一个体会：Redis面试题考的不完全是知识点，而是你对自己系统里缓存层有没有完整的认知。与其把几十道题背下来，不如把自己负责的模块里Redis的部署架构、故障场景和处理手段梳理一遍。比如哨兵选主时为什么优先看优先级、AOF重写触发条件应该怎么调、大Key有没有在监控里暴露出来，这些细节比标准答案更能说明你真的在线上用过Redis。
最后再分享一个实用的技巧：回答任何Redis问题时，先给结论，再给理由，再补一个自己的场景。面试官不希望你像搜索引擎一样吐信息，而希望看到一个会判断、会取舍的工程师。把回答问题的方式调整好，面试效果会有质的区别。
