你们项目里Redis都在干什么这是Redis面试里出现频率最高的一道送命题。听起来人畜无害其实坑非常深。要是只能答用来做缓存大概率会被判成熟练使用但理解不深面试官马上进入追问模式什么数据结构key怎么设计更新策略是什么缓存穿透、击穿、雪崩各自怎么防这些问题一旦接不住就算项目里用了好几年Redis也很难拿到想要的结果。反过来要是能把场景拆得清清楚楚把底层原理讲到为什么这个层面整场面试的节奏就会被你带着走。这篇内容是我准备跳槽面试和带团队做技术考核时反复梳理的一条Redis知识主线。不敢说覆盖全部冷门考点但高频、容易拉开差距的知识点基本都串在这条线上了。走完这条线也就算把Redis精通的探险之路走通了一大半。全文不贴大段源码更偏向面试官视角下怎么讲清楚适合有一定使用经验、想再往上走一步的开发者。1. Redis用来做什么送分题其实是送命题1.1 先想清楚Redis在你的业务里扮演什么角色很多人回答Redis用来做什么时习惯倒过来先报技术名词缓存、分布式锁、排行榜再补场景。正确的顺序恰恰相反先说业务链路里哪个环节有痛点再说Redis以什么身份解决最后补上关键配置和潜在风险。这个顺序看似只是说话习惯实际上反映了你有没有真正处理过线上问题。举个例子我上一个电商项目里有个首页热榜功能。如果直接说用Redis的ZSet做排行榜结论正确但没有任何信息量。面试官真正想听的版本是分层的业务侧运营希望首页有个按销量和时间加权的热门商品榜秒级更新数据结构侧用ZSetscore设为综合得分商品id作为member读多写少查询走Redis一分钟一次增量更新score最后主动暴露风险点热门榜算热点数据要防缓存击穿所以还做了降级缓冲Redis挂了直接返回上一次的快照列表。这样一轮讲完面试官就不需要从零开始挖背景你的层次也清楚了。1.2 高频场景和价值清单我把Redis高频场景整理成一张清单每个场景都可以作为面试里的一个故事单元按需取用应用场景常用数据结构业务价值容易被追问的细节热点数据缓存String / Hash降低DB压力提升响应速度缓存和DB的一致性怎么保证秒杀/计数器String (INCR/DECR)原子计数防止超卖库存扣减与订单写入的关系分布式锁String (SETNX)多实例互斥锁过期与误删问题排行榜/热度榜ZSet实时排序、区间查询分数相同时的排序策略会话共享String EXPIRE多节点登录态一致过期时间与续期策略限流ZSet / INCR滑动窗口限流窗口粒度与边界平滑延迟队列ZSet 定时任务订单超时关闭等扫描精度与性能开销这张表不要求全背但建议至少准备两个讲得深的应用场景。面试不会让你把八个全讲一遍而是喜欢顺着一个场景追问到底。我在模拟面试时发现很多候选人准备了一堆名词被追问到冷门场景的边界条件就卡住。比如限流如果只答用INCR加过期时间实现固定窗口其实只答了一半。固定窗口的临界流量问题、滑动窗口怎么用ZSet实现、双倍窗口边界怎么平滑这些最好也能说出个一二。面试官听完场景之后大概率会顺着往下问这个场景你用的是谁底层结构是什么这就自然过渡到下一个高频考点数据类型和它们的编码结构。场景不是背完就完它是整场Redis面试的地基工程。1.3 主动把四层信息讲完掌握面试节奏我最后想多说一句关于答法的问题。上面例子里的业务-数据结构-性能-风险四层并不是每个候选人都能答全。面试官最怕遇到只答一层的人。你想如果只答到用ZSet做排行他根本没法往下判断你的水平只能随机选一个点深挖。主动把四个层次讲完看似多说其实是在控制面试节奏把它引到你熟悉的领域。这也是我带团队考核新人时必问讲讲项目里Redis的使用链路而不是直接问ZSet底层是不是跳表的原因。2. 数据类型背后的编码int、embstr、quicklist、skiplist都是什么意思2.1 从OBJECT ENCODING认识编码层Redis对外只有五种数据类型但同样是一个String值不同底层编码完全不同。这是很多候选人翻车的地方背了五大数据类型却不知道还有一层encoding。可以先在本地跑一下这个命令直观感受什么是编码127.0.0.1:6379 SET num 100 OK 127.0.0.1:6379 OBJECT ENCODING num int 127.0.0.1:6379 SET poem hello OK 127.0.0.1:6379 OBJECT ENCODING poem embstr以String为例纯数字用int编码44字节以内的短字符串用embstr超过44字节用raw。Hash在元素少且值小的时候用ziplist超过阈值后升级为hashtableList在3.2之前是ziplist加链表的组合3.2之后改成quicklist7.x开始内部节点逐步换成了listpackSet元素全是整数且数量少用intset否则hashtableZSet元素少时用ziplist元素多或member过长时切skiplist。这些编码并不是越高级越好而是Redis在不同数据规模下做的空间与性能折中。阈值不能死记主要看两个参数元素数量和单个元素大小。以Hash举例就是hash-max-ziplist-entries和hash-max-ziplist-value默认分别为128和64字节超过任一条件整个key都会升级为hashtable且不可逆。所以设计小对象缓存时把value压在64字节以内不只是省内存也是在管理编码状态。2.2 跳表 vs 红黑树ZSet面试追问的标准答法为什么有序集合要用跳表而不是红黑树或B树这个问题几乎必考我总结了一个能立住的回答结构。第一跳表实现简单插入、删除、查找都是O(logN)级别对有序集合最常见的操作范围查询非常友好。比如排行榜Top50跳表本质上是一层层链表从高层往低层跳跃查找天然适合按区间遍历。第二红黑树在内存里也能做到相似的复杂度但实现复杂得多范围查询需要中序遍历跳表在链表结构上横向移动就能取到整个区间。第三Redis是纯内存场景不需要B树那种面向磁盘页存储设计的索引也没有磁盘IO压力。内存里的有序索引用跳表足够高效、足够省心。答到这三层面试官基本能确定你不是背答案而是真的理解过选型。2.3 SDS为什么Redis不直接拿C字符串当StringSDSSimple Dynamic String是String编码中embstr和raw背后的实际载体。回答这个问题可以从三个点展开第一C字符串获取长度要遍历到结尾的\0是O(N)SDS在头部记录lenO(1)就能拿到长度这在大value场景影响明显。第二C字符串以\0判断结尾不能安全存二进制数据SDS依靠长度字段整体是二进制安全的。第三SDS有预分配机制追加内容时会提前分配冗余空间减少频繁的内存重分配次数。面试时主动提一句SDS通常能换来不错的印象分因为它说明你不光会用命令还认真看过内部长什么样。这个知识点性价比极高值得花十分钟看一遍源码里的结构体。3. 缓存穿透、击穿、雪崩三个名字相近对策完全不同的高频题3.1 先分清三个问题的边界很多人背概念时把这三个搞混面试时一说岔专业度直接打折。我习惯用一个判断口诀穿透是要查的东西根本不存在击穿是存在且是热点但key恰好过期那一刻被打穿雪崩是大量key同时失效或Redis整体不可用。边界分清后每个问题的根因和对策就完全不一样。最怕的不是答不对而是面试官问穿透你答击穿的方案显得没有真正接触过故障排查。3.2 穿透的修复布隆过滤器和空值缓存兜底穿透的根因是DB里都没有的数据还在反复请求。比如一个恶意客户端拿一串随机的负数id去刷商品详情接口每次请求都能绕进DB。修复链路一般分四步入口参数校验请求格式不合法直接拒绝布隆过滤器拦掉不存在的key万一仍然被穿透再对空结果做短时间缓存比如60秒过期避免同一个恶意key反复打DB。这里有两个细节值得展开。布隆过滤器是可能存在的判断有误判率但不会漏报一个不存在的数据可能被误判为存在所以仍需要空值缓存兜底。误判率由bit数组大小和hash函数个数决定工程上用bf.reserve可以预设容量和误差率比如cap1000000 error0.01Java里则常见Redisson的RBloomFilter。空值缓存也要控制生命周期否则大量空结果会把Redis内存占满这个点能说出来就是加分项。3.3 击穿的修复互斥锁 vs 逻辑过期击穿的关键词是热点key过期的那一瞬间。比如某个爆款商品的详情页key过期几万个并发同时回源DB直接被压垮。互斥锁的思路最直观热点key过期后只允许一个请求去重建缓存其它请求先返回默认值或短暂阻塞等待。细节点在于重建完成后要立即把新缓存写回去避免后续请求继续等。它对一致性要求高的场景最稳我目前仍认为互斥锁是首选。逻辑过期则是另一种流派value里塞一个逻辑过期时间字段物理上key永不过期后台线程定期扫描并刷新。读请求永远不会因为缓存重建而卡住代价是数据会存在短暂不一致而且长期占据内存。方案一致性并发支撑复杂度适用场景互斥锁高重建期间有短暂等待中对一致性和时效性要求都高的场景逻辑过期稍低极高读永不阻塞较高秒杀、大促等极高并发读场景3.4 雪崩的修复时间随机化和多级缓存雪崩强调大规模同时失效。最简单的治理是给过期时间加随机误差。比如原定300秒写成300加random(0,60)秒让key的失效时间在时间轴上散开而不是整点集体失效。再往上做就是多级缓存本地缓存挡第一层Redis挡第二层DB兜底这份本地缓存通常用Caffeine或者一个带过期策略的小Map就够。最后再加限流熔断保证极端情况下DB至少能保住写入链路。我在线上处理过的几次缓存故障里真正挽救系统的往往是这层看起来不高级的本地兜底而不是花哨的对齐方案。4. RDB与AOF持久化面试里最硬的骨头4.1 RDB快照的触发时机与fork代价RDB本质是某个时间点的全量内存快照。触发有三类手动执行save或bgsave按配置自动触发例如save 900 1、save 300 10、save 60 10000表示900秒内至少1次变更300秒内至少10次变更60秒内至少10000次变更其中之一满足就触发另外shutdown或主从全量复制时也会生成RDB。这里要特别注意save和bgsave的区别save是同步阻塞主线程写盘线上绝不该用bgsave会fork出一个子进程子进程负责写盘父进程继续处理请求。fork之后父子进程共享同一份内存页持久化期间父进程有新写入才会对被修改页做拷贝这称为写时复制。优点是不需要整个内存翻倍代价是写入量巨大时内存占用和fork耗时都会上升。大实例fork的耗时可能达到毫秒甚至秒级这类问题在小数据量环境根本遇不到只有线上踩过才说得出来。注意save命令会阻塞主线程生产环境千万不要手动执行。4.2 AOF的刷盘策略与重写机制AOF记录的是写命令而不是数据快照理论上可以做到秒级以内丢失。关键配置是appendfsync三种取值决定了性能和安全的平衡策略刷盘方式性能安全性always每次写命令都刷盘最差最多丢失一条命令everysec每秒刷盘一次较好最多丢失1秒数据no交给操作系统决定最好可能丢失多条数据生产里everysec是性价比最高的选择我很少见到线上用always。AOF有一个必然面对的问题文件会随命令追加越来越大于是有了AOF重写机制。重写不是简单重放原命令而是fork子进程根据当前内存状态生成最小化命令集同时父进程把新写入追加到重写缓冲区最后一起落到新AOF。面试官喜欢追问重写会不会阻塞主线程答案是并非完全不阻塞fork阶段和最后落盘提交阶段都有短暂阻塞窗口小实例无感大实例必须关注。4.3 混合持久化与崩溃恢复顺序Redis 4.0之后支持混合持久化打开aof-use-rdb-preamble后AOF文件开头先是一个RDB格式的全量快照后面再追加增量命令。这样既保留RDB恢复快、体积小的优点又继承AOF丢数据少的特性。恢复顺序也很简单重启时如果AOF存在优先加载AOFAOF不存在再加载RDB。原因就是AOF数据新鲜度更高。如果AOF文件损坏导致启动报错可以用redis-check-aof --fix修复但修复本质是截断损坏部分极端情况会丢尾部数据。所以生产环境里把检查文件完整性写进日常运维脚本里非常有必要。5. 主从、哨兵、Cluster高可用方案背后的权衡逻辑5.1 主从复制全量同步和增量同步的分界线主从复制第一步是讲清楚全量同步和增量同步的边界。建立主从关系后首次同步是全量复制主库bgsave生成RDB传给从库从库清空内存并加载此后的写命令持续同步给从库。如果网络断开从库重连后先尝试增量同步主库会从复制积压缓冲区里把断点之后的命令补发出去。这个缓冲区大小由repl-backlog-size控制默认只有1MB非常容易被写满。一旦从库落后超过缓冲区主从就会被迫重新全量同步对主库和带宽都是巨大冲击。我在生产上排查过一次每小时全量同步的故障最后发现就是从库网络抖动一会儿backlog太小追不回来导致的。所以遇到主从同步异常第一反应先调大repl-backlog-size比如到64MB再观察。5.2 哨兵主观下线、客观下线与选主规则哨兵本身也是Redis实例职责是监控、通知和自动故障转移。被固定下来作答的三个阶段是主观下线单个哨兵发现主库ping超时此时只是它自己认为有问题客观下线达到quorum数量的多个哨兵都确认主库失联才判定主库真正挂掉故障转移哨兵集群内部先选出一个leader由leader在所有从库里挑一个提升为新主库。为什么哨兵至少三个是面试官特别爱追问的答案跟选举机制有关。哨兵集群判定下线依赖多数派。两个哨兵时只要其中一个出现故障或网络分区剩下的单票无法凑成多数整个哨兵机制就退化或失效三个哨兵时最多挂掉一个剩下两个还能凑出多数票故障转移决策才能收敛。所以生产上至少一主两从三哨兵是硬基线只部署两个哨兵的本质是伪高可用。5.3 Cluster16384个哈希槽和重定向Cluster用固定16384个哈希槽做分片键通过CRC16(key) % 16384定位到槽每个主节点负责一段槽区间。两个追问概率很高。第一为什么是16384而不是65536。因为节点间心跳包要携带全量槽位bitmap16384个bit占2KB65536要占8KB。集群设计的合理规模也就几百个节点16384足够做数据均衡8KB心跳成本就不划算了。第二客户端访问错节点会收到MOVED重定向集群扩容迁移中收到的是ASK重定向两者语义不同后者需要客户端做一次性转发。Cluster的故障恢复同样依赖多数派选举这也是官方生产要求至少3主3从的根本原因3个主节点才能容忍1个主节点故障2个主节点的话一台挂了就无法选举整个集群会退化。6. 分布式锁与Lua脚本手写题的高频考点6.1 SETNX EXPIRE为什么是经典错误答案分布式锁最老的写法是两条命令分开执行SETNX lock 1 EXPIRE lock 10问题是两条命令不具备原子性。SETNX成功了进程在EXPIRE之前崩溃锁的key会一直存在后续所有请求都拿不到锁形成死锁。正确写法是用一条命令完成SET lock unique_value NX EX 10NX表示不存在时才写入EX设置过期时间。实际项目里还有两个必须交代的细节。第一过期时间必须明显大于业务最长执行时间否则业务没跑完锁先没了。第二value必须放唯一标识比如UUID或请求id释放的时候靠它校验防止误删别人的锁。注意SETNX EXPIRE 分开写是经典错误答案原因在于不具备原子性。6.2 释放锁为什么要用Lua脚本如果直接DEL锁会遇到一个经典的并发问题。A线程业务执行完准备释放锁但锁恰好因为超时被删除B线程这时抢到了锁A再执行DEL就把B的锁删了。B失去保护整个临界区就白搭了。解决思路是释放前先GET比较value一致再DEL。但判断后删除这两步必须原子否则判断完成、删除之前仍可能被其它命令插入。于是用Lua脚本if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 endRedis执行整个Lua脚本时不会插入其它命令天然保证原子性这也是为什么扣库存、限流计数等复合操作都推荐用Lua的原因。6.3 Redisson的看门狗和RedLock的争议Java生态里最常用的是Redisson它有两个设计值得在面试里重点讲。一是可重入同一线程可以重入获取锁内部用Hash结构维护持有次数重入加1释放减到0才真正删除。二是看门狗默认锁超时30秒如果业务没结束后台线程每10秒自动续期避免业务还在跑、锁先过期的尴尬。但看门狗也有反向问题Redis主节点宕机锁的持久化跟不上锁依然可能丢失。官方因此提出了RedLock在多个独立Redis节点上加锁超过半数成功才算获取成功。实际工程里RedLock真正常用的不多因为它引入多节点部署复杂度和时钟问题性价比不高很多团队的生产结论是主从加合理过期与续期就够了。面试时提一句了解RedLock的思路但生产多数基于单实例主从并不会失分关键是要能说明理由。6.4 手写一个可用锁的完整思路如果面试现场让手写我建议能徒手把完整思路写出来加锁用SET key unique_value NX EXvalue是唯一ID释放用刚才那段Lua锁内业务要放在try/finally或defer里保证即使异常也能释放如果需要可重入用Hash结构记录线程ID和次数如果业务耗时不可控要能说清看门狗续期是怎么做的。写到这里分布式锁这道题基本就是稳稳拿下。7. 大Key、热Key、过期策略与单线程模型最后几道加分细节题7.1 大Key和热Key的发现、危害与治理面试前面答得不错时面试官会用大Key和热Key做压力测试因为它直接检验线上经验。大Key指单个key占据内存过大或集合类型元素数量过多。危害包括读写流量大慢查询多删除时可能阻塞主线程集群模式下内存倾斜跨机房复制延迟。发现手段最常用redis-cli --bigkeys它会扫描实例并统计每种类型里最大的key。注意它默认按集合元素数量判断不完全等于字节大小。更精准的排查要结合监控看实例内存分布或者按业务特征主动拆key。热Key指某个key的访问量极高常见于爆款商品、热点新闻。识别可以用redis-cli --hotkeys前提是把内存淘汰策略设置为LFU也可以临时用monitor观察但线上要慎用它会产生性能损耗。治理最常用的两招热Key做本地缓存在应用进程内兜住第一层流量或者把一个逻辑key拆成多个副本比如goods:1拆成goods:1:0到goods:1:9把读请求打散到多个key上。7.2 过期策略与内存淘汰容易被记混的机制Redis删除过期key并不是等到点就立刻删除而是惰性删除加定期删除配合。惰性删除是每次访问key时检查是否过期定期删除是后台循环随机抽查一批带过期时间的key清理其中已过期的。这样设计是为了避免一次性大量删除阻塞主线程也避免过期key长期占用内存。当内存写满时Redis按maxmemory-policy决定淘汰策略。这张表建议直接背下来面试真的常考策略作用域淘汰目标noeviction全局不淘汰新写入直接报错allkeys-lru全部key淘汰最近最少使用volatile-lru设置过期时间的key淘汰最近最少使用allkeys-random全部key随机淘汰volatile-random设置过期时间的key随机淘汰volatile-ttl设置过期时间的key淘汰剩余存活时间最短allkeys-lfu全部key淘汰最不频繁使用volatile-lfu设置过期时间的key淘汰最不频繁使用另一个高频细节是Redis的LRU不是严格LRU而是近似LRU。它通过采样方式先挑一批候选key再淘汰其中最老的maxmemory-samples默认5。严格LRU需要维护按访问时间排序的链表内存和操作成本都高Redis选择用采样估算换性能。LFU则是基于访问频次估算避免LRU被偶发的大流量访问欺骗。7.3 单线程为什么快避免在最后一题翻车这道题答错的人非常多。标准三层答法数据在内存读写没有磁盘IOIO多路复用让事件循环能高效处理大量连接单线程避免了线程切换和锁竞争命令执行天然有序。不过别把Redis说成完全单线程。4.0开始引入后台线程处理异步删除等耗时操作比如UNLINK、FLUSHDB ASYNC6.0又引入了多线程处理网络IO的读写但命令执行仍然由主线程串行。能答到这一层就是加分项。顺着单线程还有一个常被追问的点是Pipeline和事务的区别。Pipeline只是批量发送命令减少网络往返命令依然逐条执行不保证原子MULTI/EXEC事务会把一批命令打包执行但不支持回滚和关系型数据库的事务是两个概念。这两个概念放在一起讲会比单背Redis快因为单线程显得扎实很多。最后再分享一个我准备面试时的习惯别按知识点一个个背而是按使用场景到数据结构、到底层编码、到可靠性、到异常处理这条链路去串。比如聊排行榜自然带到ZSet带到ziplist和跳表带到分数更新和热点key再带到持久化最后带到缓存击穿和降级。这样不管面试官从哪个点切入你都在掌控范围内。准备Redis这条路没有捷径但把知识点织成网比死记硬背效率高得多。