把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策略的区别策略行为安全性性能always每条写命令都fsync最安全最多丢一条命令最慢everysec每秒fsync一次最多丢1秒数据默认选择性能与安全折中no交给操作系统决定刷盘时机可能丢较多数据最快实际选型里除非是金融类强一致场景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 先分清三个问题再谈方案很多人直到现在还会把这三个词混在一起用。我总结过一张简表面试时喜欢直接抛给候选人看问题触发现象根因典型场景穿透请求打到DBDB根本查不到数据缓存和DB都没有这条数据恶意请求伪造不存在的ID击穿热点key恰好过期并发请求瞬间涌向DB单个key过期秒杀商品的库存key雪崩大量key同时过期DB被压垮大量key同一时间点失效缓存批量设置了相同TTL穿透的根因是“数据根本不存在”击穿是“单点过期”雪崩是“群体失效”。面试官真正想听的不是这三个名字的定义而是你能不能根据现象快速定位是哪一种——因为解法思路完全不一样穿透靠拦截不存在的数据击穿靠同一时间只让一个请求去重建缓存雪崩靠错开过期时间加故障降级。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执行淘汰策略作用范围淘汰依据适用场景noeviction不淘汰不淘汰写命令直接报错有状态、不能丢数据的场景allkeys-lru所有key最近最少使用通用缓存allkeys-lfu所有key最不经常使用访问热点稳定的缓存allkeys-random所有key随机淘汰数据访问比较均匀volatile-lru仅带TTL的key最近最少使用只淘汰缓存key、保留常驻keyvolatile-lfu仅带TTL的key最不经常使用同上但更看重访问频次volatile-random仅带TTL的key随机淘汰同上volatile-ttl仅带TTL的key剩余存活时间最短优先淘汰即将过期的key这里有一个很隐蔽的坑凡是volatile开头的策略如果当前实例里一个带过期时间的key都没有淘汰就无从谈起Redis会直接退回noeviction的行为继续往内存里写数据照样报错。所以配策略之前要确认你的业务key到底有没有设置TTL不能光看策略名字顺眼就选。4.3 近似LRU与LFU的实际差别很多人以为Redis淘汰用的是严格LRU算法其实不是。Redis用的是近似LRU不维护全量访问历史而是在超过maxmemory时采样一部分key放入淘汰池按最近访问时间排序从池子里挑最旧的淘汰。默认采样数量由maxmemory-samples配置控制采样数越大结果越接近真实LRUCPU开销也越高。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 30NX表示只有key不存在时才能设置成功EX表示过期时间。两个条件凑在一起保证同一时刻只有一个客户端能拿到锁而且锁不会永久占着。为什么这两步必须连在一起早期版本是先SETNX再单独EXPIRE两步之间有致命窗口——如果第一步执行成功、第二步之前进程挂了锁就永久存在后续所有客户端再也拿不到锁。所以“原子性”不是八股里的抽象概念它解决的实际问题是“命令之间的空白缝隙不能成为死锁的来源”。释放锁的时候同样要谨慎通常用这样一段Luaif 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压力飙升却说不清到底该按击穿处理还是按雪崩处理。所以如果你也在准备这类问题建议把每个知识点都还原成“某次真实故障里我该先看哪个指标、再动哪个开关”来记忆而不是死记定义。面试官问完一整套八股链之后通常会追加一个开放题想听的就是你如何用这套知识去指导排查动作。能把这一步做到八股就不再是八股了。
