把Redis的面试题叫成“八股”，其实有点冤枉它。换个角度看，能在整个行业里沉淀成千篇一律的考点，恰恰说明这些知识点是无数团队踩坑踩出来的共识。我自己面试别人时也绕不开这几个问题，但我从来不想听标准答案——单线程为什么快、持久化怎么选、缓存三大件怎么解决，这些题目背后真正想确认的，是你遇到线上故障的一瞬间，脑子里能不能浮现出正确的排查方向。这篇就按我这些年折腾Redis的真实思路来写，不按“标准答案背诵”的方式罗列，而是按“面试官连环追问时，我脑子里真正过的那条逻辑链”来展开。

1. 单线程模型：为什么快，以及为什么6.0又偷偷开了多线程

1.1 单线程凭什么跑满高性能

面试第一题通常是“Redis为什么快”，标准答案能背出一长串：内存、多路复用、单线程避免锁竞争。但如果你把回答顺序换一下，逻辑会清晰得多。Redis快，最根本的原因是数据在内存里，内存的随机访问是纳秒级，比磁盘快几个数量级，这是地基。其次才是IO多路复用，单线程通过epoll同时盯住大量客户端连接，哪个socket有数据就处理哪个，不会像阻塞IO那样傻等某一个连接。最后才是“单线程”这个特性带来的红利：线程切换开销没了，并发访问下的锁竞争也没了，所有命令按顺序执行，简单直接。

我面试时遇到说“Redis快是因为单线程”的候选人，都会追问一句：那用多线程岂不是更快？能把这个反问答明白的人不多。单线程快的前提是命令执行本身极快，真正的瓶颈在网卡和内存带宽上。在带宽成为瓶颈之前，事件循环加单线程执行模型已经足够能打；就算引入多线程，主要收益也不在命令执行，而在网络收发。所以“单线程快”不是口号，是工程上权衡出来的结论。

1.2 真正会拖慢Redis的几类操作

这里有个容易背漏的点：所谓“单线程”指的是执行命令的主事件循环是单线程，Redis内部其实还有后台线程——fork出来的持久化子进程、异步删除线程、AOF刷盘线程都在并行工作。

也正因为命令执行是单线程，任何一个耗时的命令都会把整个实例卡住。实战里最容易出问题的有几类：

• KEYS、SMEMBERS、HGETALL这类全量扫描命令，在key量或member量大时耗时很长；
• SORT、ZRANGEBYSCORE大范围查询这类时间复杂度高的操作；
• 对一个体积很大的key执行DEL，或者执行FLUSHDB，删除本身要释放大块内存，同样会阻塞主线程。

我踩过的一个具体教训：线上有人把一个大list当消息队列用，list里堆了几十万条，消费者消费完直接DEL，瞬间把实例阻塞了两三秒，下游超时告警一片。后来改成小批量删除，或者用4.0之后的UNLINK让删除走后台线程。从那次之后我养成一个习惯：所有会扫全量或释放大内存的操作，先估算数据规模再决定能不能直接执行。

1.3 6.0的多线程IO到底改了什么

顺着“为什么不用多线程”往深问，就是Redis 6.0的多线程IO。这里有一个很多人会背错的关键点：6.0并不是让命令并行执行，而是把网络数据包的读取和写出分担到多个IO线程上，命令的真正解析和执行仍然在主线程完成。

从工程角度理解很简单，单线程处理小流量没有问题，但是高并发场景下网络读写本身非常耗CPU，先由多线程把数据从内核缓冲区搬运到用户空间，主线程只负责解析命令、操作内存、再交给IO线程回包，等于给主线程减负。还要注意，多线程IO默认并不开启，需要手动修改配置。“Redis 6.0改成多线程了”是流传很广的错误说法，准确说法是“网络IO多线程化，命令执行保持单线程”。面试时能把这句话主动说出来，和只会背“支持多线程”的人立刻拉开差距。

2. 持久化：别背RDB和AOF的区别，先想清楚你要丢多少数据

2.1 快照背后的写时复制机制

RDB是定期把全量内存数据序列化成一份二进制快照文件。save命令是同步阻塞的，生产环境基本不用；bgsave会fork出一个子进程，子进程负责写文件，父进程继续对外服务。这里面的核心机制是写时复制（Copy On Write）。

fork那一下是面试官最爱展开的地方。子进程初始和父进程共享全部内存页，只有当父进程某个内存页被修改时，才会复制一份再改。这意味着bgsave期间如果写流量很大，COW会复制大量内存页，内存占用可能明显上涨；同时fork本身要遍历页表，大实例的fork会短暂阻塞主线程。所以maxmemory别顶满物理内存，要留出COW和系统本身的余量。

RDB的优点很明确：文件紧凑、恢复快、适合做冷备。缺点也直白：两次快照之间的数据可能丢掉。如果你能接受“最多丢十几分钟甚至几十分钟”的数据，RDB够用；接受不了，就得看AOF。

2.2 AOF的三种写回策略到底该怎么选

AOF是把每次写命令以Redis协议格式追加到文件里。落到“什么时候真正写盘”上，就是三种appendfsync策略的区别：

实际选型里，除非是金融类强一致场景，everysec基本是默认答案。为什么总是说“最多丢1秒”？因为后台线程每秒执行一次fsync，如果实例正好在两次fsync之间崩溃，这一秒内的写命令就丢了。这是设计上明确了接受的小概率损失，比always的性能代价划算得多。

AOF还有一个绕不过去的问题：文件越来越大。于是有了重写机制。BGREWRITEAOF同样要fork子进程，扫描当前数据集，生成一组尽量少的写命令来代表全量数据；重写期间新来的写命令会进重写缓冲，等子进程写完再合并，所以不丢命令。重写同样有fork阻塞和COW内存上涨的问题，需要关注触发阈值和触发频率。

2.3 混合持久化：成年人两个都要

Redis 4.0之后有了混合持久化，AOF文件开头是RDF格式的二进制快照，快照之后的增量命令用AOF方式追加。实例重启时，先加载RDB部分快速到达快照状态，再回放一小段AOF增量，就追到了停机前的状态。对多数业务来说，这是“恢复速度”和“丢失数据量”之间最划算的组合。

我自己的习惯是：开启AOF并选择everysec，同时周期性执行bgsave生成RDB备份文件归档到远端存储。Redis自身的持久化只负责“实例重启别丢太多”，真正的冷备兜底还得靠外部定期RDB归档。如果只用RDB，也别完全依赖默认的save触发条件，最好用定时任务主动触发快照，把丢失窗口压缩到可控范围。

3. 缓存穿透、击穿、雪崩：三个名字像，根因和解法完全不同

3.1 先分清三个问题再谈方案

很多人直到现在还会把这三个词混在一起用。我总结过一张简表，面试时喜欢直接抛给候选人看：

穿透的根因是“数据根本不存在”，击穿是“单点过期”，雪崩是“群体失效”。面试官真正想听的不是这三个名字的定义，而是你能不能根据现象快速定位是哪一种——因为解法思路完全不一样：穿透靠拦截不存在的数据，击穿靠同一时间只让一个请求去重建缓存，雪崩靠错开过期时间加故障降级。

3.2 穿透的两种兜底手段

对付穿透，最直接的办法是缓存空值。查一个不存在的用户时，往缓存里写一个null占位，并设置一个较短的TTL，比如60秒。同一个ID反复来查，第二次起就命中缓存，不再打到DB。代价是空key短期占一点内存，如果业务遭遇大量随机ID攻击，空值缓存也会被塞满，所以通常还要配合参数校验——非法格式的请求直接挡在入口，根本不放进去。

另一个常见方案是布隆过滤器。原理是用N个哈希函数把key映射到一个很长的位数组上，写入时把对应位都置1；查询时看这N个位是否都是1，只要有一个是0，就说明该key一定不存在。特别注意，“一定不存在”是确定的，“可能存在”是带误差的——位数组越长、哈希函数越多，误判率越低，但内存占用越大。布隆过滤器的弱点是没法精确删除，删除一个key会导致其他key的误判率升高；如果业务对误判敏感，可以用计数布隆过滤器，或者定期整体重建过滤器。

我在实际项目里的选择是：入口参数校验挡住明显非法请求，再结合业务数据的范围特征做过滤。不是所有场景都非得引入布隆过滤器不可，先评估流量里非法请求的占比再决定，很多时候参数校验加空值缓存就够了。

3.3 击穿的互斥锁与逻辑过期

击穿的关键词是“单点热点、瞬间过期”。最经典的解法是互斥锁：热点key没有命中缓存时，只让第一个线程去加锁查DB并回填缓存，其他线程发现拿不到锁，等一小段时间后重新读缓存，或者直接返回降级数据。这个锁必须是分布式环境下有效的锁，而且锁的过期时间要足够覆盖一次DB查询和缓存回填。如果锁的过期时间短于业务耗时，锁提前释放后会有多个线程同时重建缓存，又回到击穿状态。

另一套思路是逻辑过期。业务上不设置真正的物理过期时间，而是在value里放一个expire时间戳字段。读的时候判断逻辑是否过期：没过期直接返回；过期了先返回旧数据，同时让后台线程异步重建缓存。好处是“永远有旧数据兜底”，不会出现瞬间没有缓存的情况，非常适合读取量大、对短暂旧数据容忍度高的场景。代价是数据更新最多延迟一个重建周期，业务需要评估能否接受这个延迟。

3.4 雪崩的分散与降级

雪崩最常见的成因就是“大批key在同一时间点过期”。最有效的解法是给TTL加随机偏移量，比如基础5分钟加上0到60秒的随机值；实操时我在代码里统一走一个带随机量的过期时间生成方法，批量写入缓存时天然把过期时间打散。

除了过期时间分散，还要考虑Redis进程本身不可用引发的雪崩。很多团队把缓存挂了和业务挂了画上等号，这是最危险的。降级思路要分层：进程内加一层本地缓存兜底；依赖Redis的模块要有熔断限流和快速失败的预案；DB侧做好连接池保护，别让穿透流量一口气打满。雪崩的根因一半在缓存策略设计，一半在故障预案设计，面试时能同时把这两个层面讲清楚，基本就过关了。

4. 过期删除与内存淘汰：一个是“给缓存续命”，一个是“内存不够时谁先走”

4.1 惰性删除和定期删除怎么配合

Redis的过期key删除策略，很多人知道是一套组合拳：惰性删除加定期删除。

惰性删除的意思是，key到了过期时间后不会立刻被删除，等到有人访问它、或者某些命令触达它的时候，才检查发现已经过期再顺手删掉。优点是省CPU，缺点是过期key如果一直没人访问，就会一直占着内存不释放。

定期删除是Redis每隔一段时间（默认每秒大约十次，可通过hz配置调整）随机抽一批设置了过期时间的key，把其中已经过期的删掉。为什么不全量扫？因为key可能上亿，全表扫描的代价太大。抽样的设计目标是把每次删除的耗时控制在一个极小的上限内，让清理动作对主线程的影响降到最低。

两者配合的逻辑是：定期删除负责大规模回收，惰性删除负责兜底处理漏网之鱼。可以打个比方：定期删除是保洁阿姨定时打扫公共区域，惰性删除是住户用到了某个角落才发现脏了顺手擦一下。面试时如果能点出这种设计是在CPU开销、内存回收及时性、主线程阻塞三者之间做的取舍，比单纯背定义要加分不少。

4.2 maxmemory-policy的八种策略怎么选

过期删除关心的是“key到没到时间”，内存淘汰关心的是“内存不够了哪些key先滚蛋”。这是两个不同维度，别混为一谈。Redis设置了maxmemory之后，内存占用一旦超过上限，就按maxmemory-policy执行淘汰：

这里有一个很隐蔽的坑：凡是volatile开头的策略，如果当前实例里一个带过期时间的key都没有，淘汰就无从谈起，Redis会直接退回noeviction的行为，继续往内存里写数据照样报错。所以配策略之前，要确认你的业务key到底有没有设置TTL，不能光看策略名字顺眼就选。

4.3 近似LRU与LFU的实际差别

很多人以为Redis淘汰用的是严格LRU算法，其实不是。Redis用的是近似LRU：不维护全量访问历史，而是在超过maxmemory时采样一部分key放入淘汰池，按最近访问时间排序，从池子里挑最旧的淘汰。默认采样数量由maxmemory-samples配置控制，采样数越大结果越接近真实LRU，CPU开销也越高。

LFU是Redis 4.0之后加入的，核心差别在于它追踪的是访问频率，而非最近访问时间。为什么需要LFU？考虑这个场景：某个key每天只被访问一次但每次访问时间离现在都很近，LRU会认为它“很热”；另一个key昨天被访问了一万次但今天还没被访问，LRU反而可能先淘汰后者。LFU能更准确地保住真正高频的key。我的一个选型经验是：商品详情页这类访问频率稳定的热key，用allkeys-lfu更贴合；通用会话缓存，allkeys-lru足够。

实操层面的老教训：maxmemory不要配到物理内存的100%，必须留出COW复制、AOF缓冲和操作系统本身的余量。我之前在一个8G实例上把maxmemory设成7.5G，平时没事，一到高峰期bgsave的COW把内存顶满，直接触发了系统OOM。这个坑值得提前避开。

5. 分布式锁：SET NX EX只是第一步，后面全是坑

5.1 从原子性开始：为什么不能分两步

分布式锁在Redis里的经典命令是：

SET lock_key unique_value NX EX 30

NX表示只有key不存在时才能设置成功，EX表示过期时间。两个条件凑在一起，保证同一时刻只有一个客户端能拿到锁，而且锁不会永久占着。为什么这两步必须连在一起？早期版本是先SETNX，再单独EXPIRE，两步之间有致命窗口——如果第一步执行成功、第二步之前进程挂了，锁就永久存在，后续所有客户端再也拿不到锁。所以“原子性”不是八股里的抽象概念，它解决的实际问题是“命令之间的空白缝隙不能成为死锁的来源”。

释放锁的时候同样要谨慎，通常用这样一段Lua：

if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end

先比较value再删除，两个动作放进Lua里原子执行。为什么要比value？因为锁有可能已经被其他客户端拿走了，你还稀里糊涂地DEL，就会把别人的锁删掉，导致两个客户端同时进入临界区。这个场景我在代码评审里见到过不止一次，漏掉唯一性判断的锁，在低并发下测不出来，一上压力就出事。

5.2 误删锁和看门狗续期

误删锁的具体时间线需要说清楚。客户端A拿到锁，业务执行超过30秒，锁到期自动释放；客户端B拿到锁开始执行；A终于执行完，随手一个DEL把B的锁删了，B背后的业务就失去了保护。解决方式就是用上面Lua脚本里的唯一value判断——每次加锁时生成一个随机值，可以是UUID或者雪花ID，释放时只能删自己那一个。

但这里又牵出一个更本质的矛盾：锁的过期时间到底设多长？设太长，持有者宕机后锁会长时间占着；设太短，业务没跑完锁就没了。业界一个成熟解法是Redisson的看门狗机制：通过Redisson的lock接口加锁时，默认leaseTime是30秒，成功拿到锁的客户端会自动启动一个定时任务，每隔10秒把锁的剩余时间重置回30秒，直到业务代码主动释放。相当于“锁的有效期跟着业务走”，不会因为业务执行太久而锁提前失效。注意看门狗生效是有前提的：必须使用Redisson自带的加锁接口，并且不手动指定固定leaseTime，否则它不会续期。

5.3 RedLock的争议与业务的最终兜底

面试到这里通常就会上升到RedLock：当单个Redis master节点也扛不住“锁可能丢失”的场景时，需要在多个相互独立的master上都尝试加锁，要求超过半数的节点加锁成功才算真正拿到锁，从理论上解决“主从切换导致锁丢失”的问题。但RedLock在圈内争议非常大，受到过多位分布式系统资深研究者的公开批判，核心问题包括节点故障时的时钟漂移、网络分区下的加锁行为、加锁耗时带来的不确定性。

对小团队来说，更理性的做法是评估风险等级。如果锁丢失后最坏结果是极少量的重复执行，那单实例Redis加看门狗就已经足够；如果锁丢失会引发资金、库存类的严重问题，才需要考虑RedLock，或者直接换用数据库唯一约束、版本号机制这类强一致方案。

我特别想强调一句：不管用哪种Redis分布式锁，业务侧都必须做幂等兜底。锁只能降低并发冲突的概率，不能杜绝所有异常。我接手过的项目里最典型的问题不是锁选型选错了，而是队友觉得“有锁就万事大吉”，结果锁过期后两条消息同时进来，把订单状态写重复了。锁加幂等，才是一个完整闭环。

6. 缓存一致性：先更新库还是先删缓存，最后我选了哪套方案

6.1 Cache Aside模式下的两种固定写法

缓存与数据库的一致性，业界最主流的模式是Cache Aside（旁路缓存）。读的流程不用多说：先查缓存，没命中再查DB，查完回填缓存。写的流程有两种候选顺序，面试官通常会让你对比、分析为什么最终大家选了“先更新DB，再删缓存”。

先看“先删缓存，再更新DB”的问题。线程A删了缓存key，线程B刚好读到缓存不存在，去DB读到旧值并写回缓存；此时线程A才更新DB，缓存里留下的就是旧值。这个顺序有很大的脏数据窗口，基本是被否掉的方案。

再看“先更新DB，再删缓存”：理论上是安全的，因为删除发生在写库之后，读请求最多在中间窗口读到旧缓存，等缓存删掉后下一次读就是新值。真正的隐患只剩一个：删除缓存这个动作可能失败，导致缓存长期是旧值。所以问题从“先删还是先更”就转换成了“如何保证删缓存一定成功”，这是一个工程问题，不是理论问题。

6.2 延迟双删和它治不了的问题

为了解决“删除动作之后总有一小段旧值可能被读请求写回缓存”的残余窗口，有一种补救方案叫“延迟双删”：先更新DB，删除缓存，等待一小段时间，再删一次缓存。它的逻辑是覆盖那个非常窄的竞争窗口——线程A更新DB后、准备删除缓存前，恰好吃一个线程B读了旧DB值并写回缓存；A等一小段时间后再次删除，就能把这批脏缓存清掉。实践中这个等待时间通常取500毫秒到1秒之间。

但我必须直说：延迟双删是一个可用但不严谨的方案，它依赖时间假设，无法证明在所有并发时序下都正确。比如第二次删除之前又有一个读请求把旧值写回去，延迟双删也一样无能为力。所以我的建议是：延迟双删可以和缓存自带TTL兜底配合使用，把不一致的时间窗口压缩到很小，但不要把它当成严谨的最终解。

6.3 补偿重试与订阅binlog的工程化做法

真正工程化的做法，是把“删除缓存”这个动作变成一条可靠的任务。更新DB成功后，向消息队列发一条“删除某个缓存key”的消息；专门的消费者消费消息、执行删除；删除失败就进入重试队列，直到成功。这样即使Redis短暂不可用，也不会因为一次性删除失败而留下永久脏缓存。

如果想进一步解耦，可以订阅数据库的binlog增量。通过数据同步中间件监听DB的变更事件，解析出变化的业务主键，再异步删除对应缓存。这套方案的好处是业务代码里不再有“先做A再删缓存”的耦合，读写主路径只关心自己的事，缓存一致性由中间链路统一保证。代价是引入了中间件，链路变长、延迟增加，需要一定的运维能力。

我自己项目的最终选型是：Cache Aside模式，写库成功之后发MQ消息删缓存，删除失败自动重试，同时所有缓存统一设置过期时间兜底。坚持的哲学是：不追求强一致，只追求最长不一致的时间不超过缓存TTL。面试官如果继续追问强一致怎么办，答案就进入了分布式事务的范畴，系统复杂度会上一个档次，而绝大多数业务根本没有必要为这一点点不一致付出那么大的代价。

最后聊一句真实的体会。我带新人排查缓存问题的时候发现，最常见的坑不是“不知道答案”，而是“分不清现象和根因”——三大件背得滚瓜烂熟，真的面对DB压力飙升，却说不清到底该按击穿处理还是按雪崩处理。所以如果你也在准备这类问题，建议把每个知识点都还原成“某次真实故障里我该先看哪个指标、再动哪个开关”来记忆，而不是死记定义。面试官问完一整套八股链之后通常会追加一个开放题，想听的就是你如何用这套知识去指导排查动作。能把这一步做到，八股就不再是八股了。