很多人准备 Redis 面试时第一步是找一份“x x 问”合集从数据结构背到集群原理背完觉得踏实了。但真到面试现场面试官只要多问一句“为什么”答案往往就撑不住了。比如你刚说完“缓存穿透用布隆过滤器”他紧接着问“布隆过滤器误判了怎么办”——如果你只记住了方案名这一层就接不上。Redis 面试真正考的不是你背过多少道题而是你能不能把一个工具的底层机制和真实业务场景里的取舍解释清楚。缓存、分布式锁、集群这些高频主题背后都是同一条逻辑你对 Redis 的理解能不能支撑你做工程判断。所以这篇文章不提供“速背版 85 问”而是把 Redis 面试里最常见的几大主线拆开讲清楚每个考点背后的设计原因、适用边界和常见坑点。如果你能把这几层想明白面对追问会远比背题轻松。1. Redis 面试到底在考什么不只看你知道更看你怎么用1.1 为什么 Redis 是后端和运维面试里的“常驻嘉宾”看一下各种岗位的搜索词会发现 Redis 不只在后端面试里出现Java、Linux、前端、大数据、运维方向都会提到它。原因不复杂Redis 几乎成了现代应用里最常见的一层公共组件。比如 Java 项目里有用它做会话共享的有拿它做接口幂等和分布式锁的Linux 运维场景会关注 Redis 安装、主从配置、持久化策略容器化部署里又要处理 Redis 主从和集群的编排。前端方向虽然不直接写 Redis但问到 token 缓存、接口缓存、登录态共享时也会绕到 Redis 上。这说明一个问题Redis 不是某个岗位的专用技能而是分布式系统协作中的公共设施。面试官考察 Redis往往不是想听你背命令而是想确认你能否在一个实际系统里根据数据特点、并发规模、一致性要求做出不夸张、不误用的选择。所以准备时最好的心态不是“把 Redis 所有知识点背完”而是“我能用 Redis 解决哪些问题解决到什么程度不能解决什么”。1.2 多数人的误区把 Redis 当“概念清单”背我见过三类比较典型的误区。第一类是把知识点背得很熟但不会连接。比如知道SETNX能实现分布式锁也知道过期时间要设置但被问到“为什么用 Lua 脚本释放锁”时只是机械地回答“保证原子性”却说不清原子性到底保护了什么。第二类是只记“标准答案”不记适用条件。比如一看到缓存穿透就条件反射说布隆过滤器。但布隆过滤器解决的是“大量请求打到不存在的 key”的问题它的代价是误判和额外内存如果业务里不存在这个场景方案再标准也是多余。第三类是分不清“学习方案”和“生产方案”。很多教程为了演示简单只写最核心的命令但生产环境里依赖版本、持久化策略、集群模式、网络分区、监控告警每一个都可能改变结论。面试是一个快速暴露这些问题的场景。因为追问的本质就是不断验证你的知识是“能用的理解”还是“背过的名词”。1.3 建立自己的 Redis 知识框架与其在几十个知识点里乱转不如先把知识组织成一张地图。我建议按五个模块来建立框架数据结构与命令string、hash、list、set、zset以及它们的底层编码和适用场景。缓存设计穿透、击穿、雪崩、一致性、淘汰策略、过期机制。分布式锁加锁、解锁、续期、防误删、可重入、失败场景。高可用与集群主从、哨兵、Cluster、数据迁移、脑裂。性能与持久化RDB、AOF、慢日志、bigkey、hotkey、网络瓶颈。每个模块不需要追求“大而全”而是围绕几个核心问题去深入。比如缓存模块的核心问题是“数据一致性怎么保证”分布式锁模块的核心问题是“极端情况下锁会不会失效”。带着问题去准备比从题到答案更有效。有了框架之后面对任何一道面试题你都可以先把它归位到某个模块再用“场景—原因—方案—边界”的方式组织回答。这不是套模板而是让自己的知识在追问时不散架。2. 缓存面试题的核心不是“方案名”而是失效与一致性2.1 缓存穿透、击穿、雪崩先分清场景再给方案缓存相关题目里穿透、击穿、雪崩几乎是必问的“三兄弟”。很多人的问题是把三个概念搞混或者只记得对应方案却说不清楚为什么方案有效。先做一个简单的区分缓存穿透请求的数据在缓存和数据库里都不存在所以每次请求都会打到数据库。常见于恶意攻击或非法参数。缓存击穿某一个热点 key 在缓存失效的那一瞬间大量请求同时打到数据库。虽然缓存里其他 key 有数据这个热点 key 导致数据库压力骤增。缓存雪崩大量 key 在同一时间段失效或者 Redis 实例整体不可用导致请求全部落到数据库。这三个问题的共同点是它们都会把数据库暴露在超出预期的流量下。但解决方案不同问题典型方案需要额外注意缓存穿透对不存在的 key 也做空值缓存使用布隆过滤器拦截明显不存在的请求空值缓存要设置较短过期时间布隆过滤器有误判率缓存击穿热点 key 不过期使用互斥锁重建缓存提前做热点预热要控制锁粒度避免所有请求都阻塞在锁上缓存雪崩过期时间加随机值Redis 高可用服务降级和限流随机值要控制在合理范围高可用不是解决“数据库压力”的万能药这里想特别提一点很多人一听到缓存穿透就优先说布隆过滤器但实际工程里先做参数校验再对空结果做短时间缓存往往已经能挡住大部分问题。布隆过滤器适合“数据规模大、key 集合相对固定、可以容忍误判”的场景。面试时如果能主动讲出这个边界比只报方案名更有价值。对三个问题还有一个共同的排查顺序先确认请求是不是真的打到了数据库再确认缓存 key 的结构和过期策略最后确认 Redis 本身是否健康。不要一上来就改代码。2.2 缓存更新策略为什么 Cache Aside 是最常用的默认选择缓存更新策略是面试里容易被问到但很难答好的点。常见的有 Cache Aside、Read Through、Write Through、Write Back。如果你去背概念会发现它们各自有定义但放到真实业务里选型逻辑要清楚得多。Cache Aside 的思路是读的时候先读缓存读不到再读数据库并回填缓存写的时候先更新数据库再让缓存失效或更新缓存。这种方式之所以最常用是因为它实现简单逻辑清晰而且把缓存和数据库的耦合控制在了最小范围。它的问题在于缓存和数据库之间没有事务保证所以一定会存在一个短暂的不一致窗口。比如更新数据库成功后删除缓存失败旧缓存仍然可能被读到或者两个请求并发一个更新数据库一个旧数据回填也会导致缓存里出现旧值。为了降低这种风险实际工程里有几种常见做法删除缓存而不是更新缓存因为写数据库的代价通常比更新缓存更可控而且缓存数据经常是派生数据。对删除操作做重试比如引入消息队列或本地重试表。在极端追求一致性时可以考虑延迟双删也就是先删缓存再更新数据库短暂延迟后再次删缓存。但延迟双删会引入额外复杂度和时间窗口不建议随意使用。如果你能说出这些策略背后的动机面试官会意识到你不是只背了名字而是真的处理过缓存与数据库之间的一致性问题。2.3 缓存一致性线上最常见的三个排查方向缓存一致性题目很多候选人都等着答“最终一致性”这个人人都知道的概念。但面试官真正想听的通常是你遇到数据不一致时会从哪里开始查。结合线上经验数据不一致通常可以归为三个方向。第一个方向是“写数据库成功但缓存删除或更新失败”。这是最常见的情况。排查时可以看 Redis 的日志、应用删除缓存后的返回结果以及缓存 key 的过期时间判断是不是某一次删除操作被网络或超时影响了。第二个方向是“并发读写导致旧值覆盖新值”。比如请求 A 更新数据库为 1请求 B 读取到旧值 0然后把旧值写回缓存。这种情况即使删除缓存也可能因为回填顺序的问题产生不一致。常见的缓解手段是让缓存 value 带版本号或时间戳写入前做比对。第三个方向是“Redis 主从复制延迟”。如果读的是从库主库刚更新完数据从库还没同步到缓存或数据库读到旧数据的概率就会变大。排查时可以先看复制延迟指标再决定是否要让关键读请求走主库或者接受短暂延迟。缓存一致性没有银弹。面试时一个比较好的表达方式是先说清楚一致性问题为什么会存在再说你用什么机制降低概率和影响最后说明“绝对一致”在这个场景里需要付出什么代价。这样比一句“我们用最终一致性”要可信得多。3. Redis 分布式锁能写出来只是第一步关键在边界处理3.1 为什么需要分布式锁跟线程锁有什么不同分布式锁是面试里的高频追问题因为很多项目确实会遇到。先理解为什么需要它单机应用里可以用线程锁因为在同一个进程中锁的状态对所有线程可见但一旦应用拆成多个实例或者多个服务协作修改同一个资源本地锁就管不到其他机器上的线程了。这时候需要一个分布式协调机制让多个进程之间也能实现“同一时刻只有一个持有者”的约束。Redis 分布式锁之所以流行是因为 Redis 本身部署广泛、性能高、命令简单能用很小的成本做出一把锁。但要注意Redis 分布式锁不是万能的。它依赖 Redis 的可用性和网络分区行为所以它更适合那些“锁失效后会造成一定影响但可以接受极小概率风险”的场景比如秒杀扣减、任务调度、接口幂等。如果业务要求极端严格比如金融终态数据或强一致性场景就需要考虑 ZooKeeper、etcd 这类带强一致性协调能力的方案。在面试里能主动说出“分布式锁的强弱取决于它对异常情况的容忍度”往往比代码写得漂亮更打动人。3.2 从 SETNX 到 SET NX EX第一版锁如何避免常见错误很多教程会从SETNX讲起。SETNX是“SET if Not eXists”的缩写用来在 key 不存在时写入返回 1 表示获取锁成功。但它有一个经典问题在旧版本写法里SETNX和EXPIRE是两条独立命令如果锁刚设置成功应用崩溃或进程被打断过期时间没有设置上锁就会一直存在形成死锁。所以规范做法是用一条原子命令SET key value NX EX seconds。NX保证只有 key 不存在时才写入EX保证锁有过期时间两步合成一步避免原子性问题。但这里还有一个容易忽略的细节value 不能随便写。通常要放一个能识别锁持有者的唯一标识比如 UUID 或业务请求 ID。为什么需要因为释放锁的时候如果只是简单DEL key可能出现一种情况线程 A 持有锁锁过期后线程 B 获得锁A 任务执行完却删掉了 B 的锁导致 B 的临界区失去保护。更稳妥的释放方式是先比较 value确认是当前持有者再删除。这个过程要用 Lua 脚本保证原子性。一个常见的结构是if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end这段脚本的意思是读取当前锁的 value如果和自己放入的 value 一致才删除否则不做任何操作。面试时能写出这一步并且解释清楚为什么要用 Lua基本就通过了第一层追问。3.3 Redisson 和 Redlock面试追问的边界在哪第一版锁写出来之后面试官通常会继续追问锁的过期时间怎么设如果业务执行超过过期时间怎么办锁能可重入吗 Redis 主从切换时锁会不会丢这个时候可以引入 Redisson。Redisson 是一个 Java 客户端它内置了分布式锁实现通过“看门狗”机制自动续期能够减少“业务没跑完锁提前过期”的问题。它还支持可重入锁也就是说同一个线程可以多次获取同一把锁内部会用计数器维护状态。但是Redisson 也不是没有争议。面试里常被问到的 Redlock 算法思路是对多个独立的 Redis 节点依次尝试加锁只有大多数节点都加锁成功才认为获取锁成功。这个方案在设计上试图降低单个 Redis 节点故障带来的锁失效风险但它在网络分区、时钟跳跃等场景下仍有争议一些技术专家也提出过质疑。面试时不需要站队但需要能说清楚边界如果你的系统只有一个 Redis 主从集群Redisson 的可续期锁通常已经够用。如果追求更强的一致性就要接受更复杂的部署和更低的可用性。分布式锁解决的是并发互斥问题不能替代数据库事务、幂等设计和业务补偿。最后再补一句分布式锁的真正难点不是“加锁”而是“加锁之后系统变复杂了”。你要考虑锁的粒度、持有时间、异常释放、监控告警。能意识到这一层的候选人通常已经比单纯背命令的同学领先不少。4. Redis 集群从主从、哨兵到 Cluster背后是“可用性”和“分片”的取舍4.1 主从复制与哨兵高可用是怎么实现的Redis 单节点部署虽然简单但风险也明显实例挂了缓存和数据都不可用。所以生产环境里主从复制是第一步。主从复制的大致逻辑是一台主节点负责处理写请求一个或多个从节点通过异步复制同步数据。这样如果主节点出问题可以让从节点接管同时读多写少的场景也能通过读写分离分摊部分读压力。但单纯的主从复制不够因为主节点挂了之后需要有人决定“哪个从节点升级为主节点”。哨兵Sentinel就是干这个的。它会持续监控主从节点的状态在主节点不可达时发起故障转移选出新的主节点并通知客户端。这里有个关键点要记住Redis 的复制是异步的。这意味着主从切换时可能丢失极少量已经写入主节点但还没来得及同步的数据。所以故障转移无法做到零丢失。为了降低丢失风险生产上可以配置min-replicas-to-write和min-replicas-max-lag。意思是如果从节点数量不足或复制延迟太大主节点就拒绝写请求。这能减少数据丢失窗口但代价是牺牲可用性。面试时能说出这个取舍说明你真的理解高可用的代价。4.2 Redis Cluster 为什么用 16384 个槽位主从加哨兵解决了高可用但没有解决单分片容量和写瓶颈。Redis Cluster 引入了数据分片把数据分散到多个主节点上。Redis Cluster 使用的不是简单的一致性哈希而是哈希槽hash slot。整个键空间被分成 16384 个槽位每个 key 通过 CRC16 计算后对 16384 取模得到它属于哪个槽每个主节点负责一段槽位区间。比如三个主节点可以分别负责 0-5460、5461-10922、10923-16383。那为什么是 16384 而不是其他数字常见解释有几个角度集群节点之间需要传播槽位信息槽位数量过大会增加心跳包大小和网络开销。16384 个槽位对常规规模下的 redis cluster 节点数已经足够最多允许 1000 个主节点的设计目标下槽位数量依然能保持较好的请求分布。简化哈希结果的计算和传输。这种设计的好处是数据迁移变得可控。增加或减少节点时只需要迁移一部分槽位而不是像一致性哈希那样重新计算大量 key 的路由。面试时能说出“槽位是为了让分片和迁移更灵活”比单纯背数字要有用得多。4.3 集群常见故障脑裂、数据丢失、迁移窗口集群问题里面试官一般不会只问概念而是会在一个具体故障上追问。第一个高发问题是脑裂。当网络分区发生时原主节点和一部分从节点、哨兵可能失去了联系。哨兵可能把一个从节点提升为新主节点但原主节点在网络分区期间并没有真正宕机它可能还在接收写入。这样分区恢复后原主节点上的数据会和新主节点不一致只能通过某种方式丢弃部分数据。这个问题可以通过min-replicas-to-write和cluster-node-timeout等参数来缓解。核心是宁可拒绝部分写请求也不能让两个主节点同时接受写入。第二个高发问题是槽迁移期间的请求处理。Redis Cluster 在迁移槽位时客户端可能拿到MOVED或ASK响应。MOVED表示这个槽已经迁移到另一个节点客户端需要更新本地路由ASK表示槽正在迁移中需要临时去目标节点查询。如果客户端没有正确处理这两种响应就可能出现请求失败或路由混乱。第三个常见问题是从节点提升带来的数据延迟。主从复制延迟较大时主节点故障从节点提升后可能缺失最近写入的数据。这不是一种“异常”现象而是异步复制的基本特性。所以需要提前评估业务对数据丢失的敏感度决定是否要接受这种取舍。排查集群问题时推荐按这个顺序做cluster info查看集群状态。cluster nodes查看节点角色、槽位和连接状态。检查业务日志中是否出现MOVED、ASK、CLUSTERDOWN。检查主从节点的复制延迟和内存指标。再回到业务侧确认配置和客户端路由是否正常。不要一看到集群问题就想着重启。很多问题都是客户端路由、槽位分布或网络分区导致的重启并不能根治。5. 持久化、内存淘汰和性能排查拉开差距的往往是第三层5.1 RDB 与 AOF生产环境到底怎么选Redis 面试里RDB 和 AOF 的区别是基础题。但大家容易忽略的是真正难的不是记住“RDB 是快照AOF 是日志”而是根据场景做配置。RDB 会定期把内存数据保存成一份二进制快照恢复速度快适合做备份和全量恢复。缺点是两次快照之间的数据可能丢失。AOF 会记录每一条写命令按策略追加到日志文件数据丢失窗口更小但文件体积更大恢复速度相对慢。生产环境里的常见做法是两者结合用 RDB 做基础备份处理快速恢复用 AOF 做更细粒度的数据保护。Redis 也支持 AOF 重写可以在后台压缩日志文件避免 AOF 无限增长。还要注意一个细节appendfsync的配置。always表示每条写命令都刷盘安全但性能差everysec表示每秒刷一次盘性能和安全性比较均衡no由操作系统决定丢失风险更大。多数场景下everysec是更务实的默认选择。如果 Redis 只是当纯缓存不承担持久化职责配置可以更简单但如果用 Redis 保存分布式锁、限流计数、业务状态持久化配置就很重要。面试时可以主动说先想清楚这台 Redis 的角色再决定用哪种持久化组合。5.2 内存淘汰策略与过期机制不要混淆 LRU 和 TTL内存淘汰是另一个经常被误解的点。有人会把“key 过期”和“内存淘汰”混在一起但它们是完全不同的机制。key 过期是指你给某个 key 设置了 TTL时间到了之后 Redis 删除它。Redis 删除过期 key 通常采用惰性删除和定期删除结合的方式惰性删除是每次访问 key 时检查是否过期过期就删定期删除是后台周期性检查部分 key。所以一个已经过期的 key不会在你下一次访问之前立刻消失。内存淘汰是当 Redis 内存达到maxmemory上限时需要决定丢弃哪些数据。常见的策略主要有noeviction不淘汰新写入直接报错适合不能丢数据的场景。allkeys-lru在所有 key 中按最近最少使用淘汰。volatile-lru只在设置了过期时间的 key 中按 LRU 淘汰保留没有 TTL 的长期 key。allkeys-random随机淘汰适合访问模式比较均匀的场景。实际项目里如果 Redis 主要做缓存通常可以选allkeys-lru如果有一部分 key 不能丢至少也要给它们设置长 TTL并选择合理的 volatile 策略。面试时只要你能说出“淘汰策略是内存压力下的取舍而不是数据的必然行为”就已经超越了大多数人。5.3 线上 Redis 变慢从慢日志、bigkey、hotkey 开始排查性能排查是面试里最能拉开差距的环节。因为很多基础知识可以背但排查思路只能靠做过。线上 Redis 变慢的现象通常包括请求耗时上升、连接数异常、CPU 升高、偶尔超时。这时候不要急着重启或者扩容先按下述顺序排查。第一步看慢日志。SLOWLOG GET可以查看执行时间超过阈值的命令。如果看到大量KEYS *、SMEMBERS、HGETALL这类全量命令很可能就是它们阻塞了 Redis 单线程。第二步看 bigkey。Redis 是单线程模型一个 value 特别大的 key执行命令时会占用很长时间也会影响内存和网络。可以使用redis-cli --bigkeys扫描但要注意它本身也有性能开销建议在低峰期执行。找到 bigkey 后要评估拆分、压缩或用哈希结构替代。第三步看 hotkey。某个 key 被高频访问会导致 Redis 单节点负载严重不均。常见做法是给 hotkey 加后缀做本地缓存或者把请求分散到多个 key。但前提是业务能容忍一定的短暂不一致。第四步看系统层。内存碎片率过高、fork 阻塞、网络带宽饱和、大流量客户端连接都可能导致请求变慢。可以查INFO memory、INFO stats、INFO clients等指标。最终排查的结论多数时候不是“一条命令解决”而是多个因素叠加。写面试答案时如果能呈现这种链路思考比只回答“用缓存穿透的布隆过滤器”要有说服力得多。6. 从“背 85 问”到“讲清一个场景”三天学习计划与长期沉淀6.1 为什么刷题集不一定有效如何拆解题目很多同学看到“Redis 85 问”这类合集会陷入一种错觉只要把所有题目背完面试就没问题了。但前面的内容其实都在说明一个问题面试官要的不是复读机而是能把题目连接到实际场景的人。同样一道题比如“Redis 分布式锁的实现”你可以拆成几个层次来准备是什么分布式锁解决多实例并发互斥问题。为什么用 Redis因为部署广泛、性能高、命令简单。怎么做SET key value NX EX seconds加锁Lua 脚本释放锁。边界过期时间太短、业务执行时间不确定、主从切换锁丢失。替代方案Redisson、ZooKeeper、etcd 各自适合什么场景。用这个拆法一道题就不再是孤立的答案而是变成一组可推导的判断。面试时无论从哪个角度追问你都有足够的上下文去应对。对每一道高频题都建议做一次这样的拆解。你会发现很多题目看起来不同底层其实是同一个问题缓存和数据库的一致性、分布式系统的可用性、性能和准确性的平衡。6.2 一个可执行的 3 天学习计划示例标题里提到 3 天学会这个说法当然有点夸张。但如果你的目标是快速建立 Redis 面试的知识框架3 天时间确实可以做一轮有侧重的学习。我提供一个可以参考的安排时间学习重点建议动作第 1 天数据结构与缓存场景复习 string、hash、list、set、zset 的适用场景用 Docker 起一个 Redis 实例模拟缓存穿透、击穿、雪崩的代码场景第 2 天分布式锁与持久化用SET NX EX写一个加锁释放锁的小示例比较 RDB 和 AOF 的不同配置思考锁过期和误删问题第 3 天集群与性能排查搭建一主两从或一个三主三从的 Redis 集群模拟从节点故障观察故障转移执行一次慢日志和 bigkey 扫描这个计划的重点是“动手验证”。Redis 面试题里很多结论只有亲手跑过才会理解。比如你单独看“主从复制是异步的”这句话很难有真实感受但如果你在主节点写入数据后立刻杀掉主节点然后看从节点少了哪条数据印象会深很多。如果时间不足至少要把 3 天计划压缩成“一天跑通主流程”的版本启动 Redis、自己做一次缓存读写、写一个带过期时间的分布式锁、再启动一个从节点看复制效果。6.3 面试和工程里的最终判断标准最后想给你一个判断标准当你学完一轮 Redis 后能不能回答下面三个问题。第一适不适合。面对一个场景你能不能说出 Redis 适合什么不适合什么。比如“这个接口用 Redis 做缓存合理用 Redis 做持久化存储则要谨慎”。第二为什么。当你提出一个方案时能不能解释背后的原因。比如“用allkeys-lru是因为这里 Redis 是缓存丢弃旧数据比拒绝新写入更合理”。第三极端情况怎么办。如果 Redis 挂了你的业务会出现什么问题如果 key 过期早了一秒会影响什么这种“边界意识”是面试官最能感受到你经验的地方。长期来看真正有用的不是背下 85 道题而是每用过一次 Redis都记录下当时的选择、踩过的坑、排查过的异常。把工具的使用经历沉淀成自己的判断比任何“面试天花板”都更有说服力。Redis 仍然会继续出现在后端、运维、大数据的各类场景里。与其焦虑题目数量不如先把缓存、分布式锁、集群这几条主线里的“为什么”想透。面试问题会变但底层判断永远有价值。 Redis面试不靠背题：穿透、分布式锁、集群的底层逻辑
很多人准备 Redis 面试时第一步是找一份“x x 问”合集从数据结构背到集群原理背完觉得踏实了。但真到面试现场面试官只要多问一句“为什么”答案往往就撑不住了。比如你刚说完“缓存穿透用布隆过滤器”他紧接着问“布隆过滤器误判了怎么办”——如果你只记住了方案名这一层就接不上。Redis 面试真正考的不是你背过多少道题而是你能不能把一个工具的底层机制和真实业务场景里的取舍解释清楚。缓存、分布式锁、集群这些高频主题背后都是同一条逻辑你对 Redis 的理解能不能支撑你做工程判断。所以这篇文章不提供“速背版 85 问”而是把 Redis 面试里最常见的几大主线拆开讲清楚每个考点背后的设计原因、适用边界和常见坑点。如果你能把这几层想明白面对追问会远比背题轻松。1. Redis 面试到底在考什么不只看你知道更看你怎么用1.1 为什么 Redis 是后端和运维面试里的“常驻嘉宾”看一下各种岗位的搜索词会发现 Redis 不只在后端面试里出现Java、Linux、前端、大数据、运维方向都会提到它。原因不复杂Redis 几乎成了现代应用里最常见的一层公共组件。比如 Java 项目里有用它做会话共享的有拿它做接口幂等和分布式锁的Linux 运维场景会关注 Redis 安装、主从配置、持久化策略容器化部署里又要处理 Redis 主从和集群的编排。前端方向虽然不直接写 Redis但问到 token 缓存、接口缓存、登录态共享时也会绕到 Redis 上。这说明一个问题Redis 不是某个岗位的专用技能而是分布式系统协作中的公共设施。面试官考察 Redis往往不是想听你背命令而是想确认你能否在一个实际系统里根据数据特点、并发规模、一致性要求做出不夸张、不误用的选择。所以准备时最好的心态不是“把 Redis 所有知识点背完”而是“我能用 Redis 解决哪些问题解决到什么程度不能解决什么”。1.2 多数人的误区把 Redis 当“概念清单”背我见过三类比较典型的误区。第一类是把知识点背得很熟但不会连接。比如知道SETNX能实现分布式锁也知道过期时间要设置但被问到“为什么用 Lua 脚本释放锁”时只是机械地回答“保证原子性”却说不清原子性到底保护了什么。第二类是只记“标准答案”不记适用条件。比如一看到缓存穿透就条件反射说布隆过滤器。但布隆过滤器解决的是“大量请求打到不存在的 key”的问题它的代价是误判和额外内存如果业务里不存在这个场景方案再标准也是多余。第三类是分不清“学习方案”和“生产方案”。很多教程为了演示简单只写最核心的命令但生产环境里依赖版本、持久化策略、集群模式、网络分区、监控告警每一个都可能改变结论。面试是一个快速暴露这些问题的场景。因为追问的本质就是不断验证你的知识是“能用的理解”还是“背过的名词”。1.3 建立自己的 Redis 知识框架与其在几十个知识点里乱转不如先把知识组织成一张地图。我建议按五个模块来建立框架数据结构与命令string、hash、list、set、zset以及它们的底层编码和适用场景。缓存设计穿透、击穿、雪崩、一致性、淘汰策略、过期机制。分布式锁加锁、解锁、续期、防误删、可重入、失败场景。高可用与集群主从、哨兵、Cluster、数据迁移、脑裂。性能与持久化RDB、AOF、慢日志、bigkey、hotkey、网络瓶颈。每个模块不需要追求“大而全”而是围绕几个核心问题去深入。比如缓存模块的核心问题是“数据一致性怎么保证”分布式锁模块的核心问题是“极端情况下锁会不会失效”。带着问题去准备比从题到答案更有效。有了框架之后面对任何一道面试题你都可以先把它归位到某个模块再用“场景—原因—方案—边界”的方式组织回答。这不是套模板而是让自己的知识在追问时不散架。2. 缓存面试题的核心不是“方案名”而是失效与一致性2.1 缓存穿透、击穿、雪崩先分清场景再给方案缓存相关题目里穿透、击穿、雪崩几乎是必问的“三兄弟”。很多人的问题是把三个概念搞混或者只记得对应方案却说不清楚为什么方案有效。先做一个简单的区分缓存穿透请求的数据在缓存和数据库里都不存在所以每次请求都会打到数据库。常见于恶意攻击或非法参数。缓存击穿某一个热点 key 在缓存失效的那一瞬间大量请求同时打到数据库。虽然缓存里其他 key 有数据这个热点 key 导致数据库压力骤增。缓存雪崩大量 key 在同一时间段失效或者 Redis 实例整体不可用导致请求全部落到数据库。这三个问题的共同点是它们都会把数据库暴露在超出预期的流量下。但解决方案不同问题典型方案需要额外注意缓存穿透对不存在的 key 也做空值缓存使用布隆过滤器拦截明显不存在的请求空值缓存要设置较短过期时间布隆过滤器有误判率缓存击穿热点 key 不过期使用互斥锁重建缓存提前做热点预热要控制锁粒度避免所有请求都阻塞在锁上缓存雪崩过期时间加随机值Redis 高可用服务降级和限流随机值要控制在合理范围高可用不是解决“数据库压力”的万能药这里想特别提一点很多人一听到缓存穿透就优先说布隆过滤器但实际工程里先做参数校验再对空结果做短时间缓存往往已经能挡住大部分问题。布隆过滤器适合“数据规模大、key 集合相对固定、可以容忍误判”的场景。面试时如果能主动讲出这个边界比只报方案名更有价值。对三个问题还有一个共同的排查顺序先确认请求是不是真的打到了数据库再确认缓存 key 的结构和过期策略最后确认 Redis 本身是否健康。不要一上来就改代码。2.2 缓存更新策略为什么 Cache Aside 是最常用的默认选择缓存更新策略是面试里容易被问到但很难答好的点。常见的有 Cache Aside、Read Through、Write Through、Write Back。如果你去背概念会发现它们各自有定义但放到真实业务里选型逻辑要清楚得多。Cache Aside 的思路是读的时候先读缓存读不到再读数据库并回填缓存写的时候先更新数据库再让缓存失效或更新缓存。这种方式之所以最常用是因为它实现简单逻辑清晰而且把缓存和数据库的耦合控制在了最小范围。它的问题在于缓存和数据库之间没有事务保证所以一定会存在一个短暂的不一致窗口。比如更新数据库成功后删除缓存失败旧缓存仍然可能被读到或者两个请求并发一个更新数据库一个旧数据回填也会导致缓存里出现旧值。为了降低这种风险实际工程里有几种常见做法删除缓存而不是更新缓存因为写数据库的代价通常比更新缓存更可控而且缓存数据经常是派生数据。对删除操作做重试比如引入消息队列或本地重试表。在极端追求一致性时可以考虑延迟双删也就是先删缓存再更新数据库短暂延迟后再次删缓存。但延迟双删会引入额外复杂度和时间窗口不建议随意使用。如果你能说出这些策略背后的动机面试官会意识到你不是只背了名字而是真的处理过缓存与数据库之间的一致性问题。2.3 缓存一致性线上最常见的三个排查方向缓存一致性题目很多候选人都等着答“最终一致性”这个人人都知道的概念。但面试官真正想听的通常是你遇到数据不一致时会从哪里开始查。结合线上经验数据不一致通常可以归为三个方向。第一个方向是“写数据库成功但缓存删除或更新失败”。这是最常见的情况。排查时可以看 Redis 的日志、应用删除缓存后的返回结果以及缓存 key 的过期时间判断是不是某一次删除操作被网络或超时影响了。第二个方向是“并发读写导致旧值覆盖新值”。比如请求 A 更新数据库为 1请求 B 读取到旧值 0然后把旧值写回缓存。这种情况即使删除缓存也可能因为回填顺序的问题产生不一致。常见的缓解手段是让缓存 value 带版本号或时间戳写入前做比对。第三个方向是“Redis 主从复制延迟”。如果读的是从库主库刚更新完数据从库还没同步到缓存或数据库读到旧数据的概率就会变大。排查时可以先看复制延迟指标再决定是否要让关键读请求走主库或者接受短暂延迟。缓存一致性没有银弹。面试时一个比较好的表达方式是先说清楚一致性问题为什么会存在再说你用什么机制降低概率和影响最后说明“绝对一致”在这个场景里需要付出什么代价。这样比一句“我们用最终一致性”要可信得多。3. Redis 分布式锁能写出来只是第一步关键在边界处理3.1 为什么需要分布式锁跟线程锁有什么不同分布式锁是面试里的高频追问题因为很多项目确实会遇到。先理解为什么需要它单机应用里可以用线程锁因为在同一个进程中锁的状态对所有线程可见但一旦应用拆成多个实例或者多个服务协作修改同一个资源本地锁就管不到其他机器上的线程了。这时候需要一个分布式协调机制让多个进程之间也能实现“同一时刻只有一个持有者”的约束。Redis 分布式锁之所以流行是因为 Redis 本身部署广泛、性能高、命令简单能用很小的成本做出一把锁。但要注意Redis 分布式锁不是万能的。它依赖 Redis 的可用性和网络分区行为所以它更适合那些“锁失效后会造成一定影响但可以接受极小概率风险”的场景比如秒杀扣减、任务调度、接口幂等。如果业务要求极端严格比如金融终态数据或强一致性场景就需要考虑 ZooKeeper、etcd 这类带强一致性协调能力的方案。在面试里能主动说出“分布式锁的强弱取决于它对异常情况的容忍度”往往比代码写得漂亮更打动人。3.2 从 SETNX 到 SET NX EX第一版锁如何避免常见错误很多教程会从SETNX讲起。SETNX是“SET if Not eXists”的缩写用来在 key 不存在时写入返回 1 表示获取锁成功。但它有一个经典问题在旧版本写法里SETNX和EXPIRE是两条独立命令如果锁刚设置成功应用崩溃或进程被打断过期时间没有设置上锁就会一直存在形成死锁。所以规范做法是用一条原子命令SET key value NX EX seconds。NX保证只有 key 不存在时才写入EX保证锁有过期时间两步合成一步避免原子性问题。但这里还有一个容易忽略的细节value 不能随便写。通常要放一个能识别锁持有者的唯一标识比如 UUID 或业务请求 ID。为什么需要因为释放锁的时候如果只是简单DEL key可能出现一种情况线程 A 持有锁锁过期后线程 B 获得锁A 任务执行完却删掉了 B 的锁导致 B 的临界区失去保护。更稳妥的释放方式是先比较 value确认是当前持有者再删除。这个过程要用 Lua 脚本保证原子性。一个常见的结构是if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end这段脚本的意思是读取当前锁的 value如果和自己放入的 value 一致才删除否则不做任何操作。面试时能写出这一步并且解释清楚为什么要用 Lua基本就通过了第一层追问。3.3 Redisson 和 Redlock面试追问的边界在哪第一版锁写出来之后面试官通常会继续追问锁的过期时间怎么设如果业务执行超过过期时间怎么办锁能可重入吗 Redis 主从切换时锁会不会丢这个时候可以引入 Redisson。Redisson 是一个 Java 客户端它内置了分布式锁实现通过“看门狗”机制自动续期能够减少“业务没跑完锁提前过期”的问题。它还支持可重入锁也就是说同一个线程可以多次获取同一把锁内部会用计数器维护状态。但是Redisson 也不是没有争议。面试里常被问到的 Redlock 算法思路是对多个独立的 Redis 节点依次尝试加锁只有大多数节点都加锁成功才认为获取锁成功。这个方案在设计上试图降低单个 Redis 节点故障带来的锁失效风险但它在网络分区、时钟跳跃等场景下仍有争议一些技术专家也提出过质疑。面试时不需要站队但需要能说清楚边界如果你的系统只有一个 Redis 主从集群Redisson 的可续期锁通常已经够用。如果追求更强的一致性就要接受更复杂的部署和更低的可用性。分布式锁解决的是并发互斥问题不能替代数据库事务、幂等设计和业务补偿。最后再补一句分布式锁的真正难点不是“加锁”而是“加锁之后系统变复杂了”。你要考虑锁的粒度、持有时间、异常释放、监控告警。能意识到这一层的候选人通常已经比单纯背命令的同学领先不少。4. Redis 集群从主从、哨兵到 Cluster背后是“可用性”和“分片”的取舍4.1 主从复制与哨兵高可用是怎么实现的Redis 单节点部署虽然简单但风险也明显实例挂了缓存和数据都不可用。所以生产环境里主从复制是第一步。主从复制的大致逻辑是一台主节点负责处理写请求一个或多个从节点通过异步复制同步数据。这样如果主节点出问题可以让从节点接管同时读多写少的场景也能通过读写分离分摊部分读压力。但单纯的主从复制不够因为主节点挂了之后需要有人决定“哪个从节点升级为主节点”。哨兵Sentinel就是干这个的。它会持续监控主从节点的状态在主节点不可达时发起故障转移选出新的主节点并通知客户端。这里有个关键点要记住Redis 的复制是异步的。这意味着主从切换时可能丢失极少量已经写入主节点但还没来得及同步的数据。所以故障转移无法做到零丢失。为了降低丢失风险生产上可以配置min-replicas-to-write和min-replicas-max-lag。意思是如果从节点数量不足或复制延迟太大主节点就拒绝写请求。这能减少数据丢失窗口但代价是牺牲可用性。面试时能说出这个取舍说明你真的理解高可用的代价。4.2 Redis Cluster 为什么用 16384 个槽位主从加哨兵解决了高可用但没有解决单分片容量和写瓶颈。Redis Cluster 引入了数据分片把数据分散到多个主节点上。Redis Cluster 使用的不是简单的一致性哈希而是哈希槽hash slot。整个键空间被分成 16384 个槽位每个 key 通过 CRC16 计算后对 16384 取模得到它属于哪个槽每个主节点负责一段槽位区间。比如三个主节点可以分别负责 0-5460、5461-10922、10923-16383。那为什么是 16384 而不是其他数字常见解释有几个角度集群节点之间需要传播槽位信息槽位数量过大会增加心跳包大小和网络开销。16384 个槽位对常规规模下的 redis cluster 节点数已经足够最多允许 1000 个主节点的设计目标下槽位数量依然能保持较好的请求分布。简化哈希结果的计算和传输。这种设计的好处是数据迁移变得可控。增加或减少节点时只需要迁移一部分槽位而不是像一致性哈希那样重新计算大量 key 的路由。面试时能说出“槽位是为了让分片和迁移更灵活”比单纯背数字要有用得多。4.3 集群常见故障脑裂、数据丢失、迁移窗口集群问题里面试官一般不会只问概念而是会在一个具体故障上追问。第一个高发问题是脑裂。当网络分区发生时原主节点和一部分从节点、哨兵可能失去了联系。哨兵可能把一个从节点提升为新主节点但原主节点在网络分区期间并没有真正宕机它可能还在接收写入。这样分区恢复后原主节点上的数据会和新主节点不一致只能通过某种方式丢弃部分数据。这个问题可以通过min-replicas-to-write和cluster-node-timeout等参数来缓解。核心是宁可拒绝部分写请求也不能让两个主节点同时接受写入。第二个高发问题是槽迁移期间的请求处理。Redis Cluster 在迁移槽位时客户端可能拿到MOVED或ASK响应。MOVED表示这个槽已经迁移到另一个节点客户端需要更新本地路由ASK表示槽正在迁移中需要临时去目标节点查询。如果客户端没有正确处理这两种响应就可能出现请求失败或路由混乱。第三个常见问题是从节点提升带来的数据延迟。主从复制延迟较大时主节点故障从节点提升后可能缺失最近写入的数据。这不是一种“异常”现象而是异步复制的基本特性。所以需要提前评估业务对数据丢失的敏感度决定是否要接受这种取舍。排查集群问题时推荐按这个顺序做cluster info查看集群状态。cluster nodes查看节点角色、槽位和连接状态。检查业务日志中是否出现MOVED、ASK、CLUSTERDOWN。检查主从节点的复制延迟和内存指标。再回到业务侧确认配置和客户端路由是否正常。不要一看到集群问题就想着重启。很多问题都是客户端路由、槽位分布或网络分区导致的重启并不能根治。5. 持久化、内存淘汰和性能排查拉开差距的往往是第三层5.1 RDB 与 AOF生产环境到底怎么选Redis 面试里RDB 和 AOF 的区别是基础题。但大家容易忽略的是真正难的不是记住“RDB 是快照AOF 是日志”而是根据场景做配置。RDB 会定期把内存数据保存成一份二进制快照恢复速度快适合做备份和全量恢复。缺点是两次快照之间的数据可能丢失。AOF 会记录每一条写命令按策略追加到日志文件数据丢失窗口更小但文件体积更大恢复速度相对慢。生产环境里的常见做法是两者结合用 RDB 做基础备份处理快速恢复用 AOF 做更细粒度的数据保护。Redis 也支持 AOF 重写可以在后台压缩日志文件避免 AOF 无限增长。还要注意一个细节appendfsync的配置。always表示每条写命令都刷盘安全但性能差everysec表示每秒刷一次盘性能和安全性比较均衡no由操作系统决定丢失风险更大。多数场景下everysec是更务实的默认选择。如果 Redis 只是当纯缓存不承担持久化职责配置可以更简单但如果用 Redis 保存分布式锁、限流计数、业务状态持久化配置就很重要。面试时可以主动说先想清楚这台 Redis 的角色再决定用哪种持久化组合。5.2 内存淘汰策略与过期机制不要混淆 LRU 和 TTL内存淘汰是另一个经常被误解的点。有人会把“key 过期”和“内存淘汰”混在一起但它们是完全不同的机制。key 过期是指你给某个 key 设置了 TTL时间到了之后 Redis 删除它。Redis 删除过期 key 通常采用惰性删除和定期删除结合的方式惰性删除是每次访问 key 时检查是否过期过期就删定期删除是后台周期性检查部分 key。所以一个已经过期的 key不会在你下一次访问之前立刻消失。内存淘汰是当 Redis 内存达到maxmemory上限时需要决定丢弃哪些数据。常见的策略主要有noeviction不淘汰新写入直接报错适合不能丢数据的场景。allkeys-lru在所有 key 中按最近最少使用淘汰。volatile-lru只在设置了过期时间的 key 中按 LRU 淘汰保留没有 TTL 的长期 key。allkeys-random随机淘汰适合访问模式比较均匀的场景。实际项目里如果 Redis 主要做缓存通常可以选allkeys-lru如果有一部分 key 不能丢至少也要给它们设置长 TTL并选择合理的 volatile 策略。面试时只要你能说出“淘汰策略是内存压力下的取舍而不是数据的必然行为”就已经超越了大多数人。5.3 线上 Redis 变慢从慢日志、bigkey、hotkey 开始排查性能排查是面试里最能拉开差距的环节。因为很多基础知识可以背但排查思路只能靠做过。线上 Redis 变慢的现象通常包括请求耗时上升、连接数异常、CPU 升高、偶尔超时。这时候不要急着重启或者扩容先按下述顺序排查。第一步看慢日志。SLOWLOG GET可以查看执行时间超过阈值的命令。如果看到大量KEYS *、SMEMBERS、HGETALL这类全量命令很可能就是它们阻塞了 Redis 单线程。第二步看 bigkey。Redis 是单线程模型一个 value 特别大的 key执行命令时会占用很长时间也会影响内存和网络。可以使用redis-cli --bigkeys扫描但要注意它本身也有性能开销建议在低峰期执行。找到 bigkey 后要评估拆分、压缩或用哈希结构替代。第三步看 hotkey。某个 key 被高频访问会导致 Redis 单节点负载严重不均。常见做法是给 hotkey 加后缀做本地缓存或者把请求分散到多个 key。但前提是业务能容忍一定的短暂不一致。第四步看系统层。内存碎片率过高、fork 阻塞、网络带宽饱和、大流量客户端连接都可能导致请求变慢。可以查INFO memory、INFO stats、INFO clients等指标。最终排查的结论多数时候不是“一条命令解决”而是多个因素叠加。写面试答案时如果能呈现这种链路思考比只回答“用缓存穿透的布隆过滤器”要有说服力得多。6. 从“背 85 问”到“讲清一个场景”三天学习计划与长期沉淀6.1 为什么刷题集不一定有效如何拆解题目很多同学看到“Redis 85 问”这类合集会陷入一种错觉只要把所有题目背完面试就没问题了。但前面的内容其实都在说明一个问题面试官要的不是复读机而是能把题目连接到实际场景的人。同样一道题比如“Redis 分布式锁的实现”你可以拆成几个层次来准备是什么分布式锁解决多实例并发互斥问题。为什么用 Redis因为部署广泛、性能高、命令简单。怎么做SET key value NX EX seconds加锁Lua 脚本释放锁。边界过期时间太短、业务执行时间不确定、主从切换锁丢失。替代方案Redisson、ZooKeeper、etcd 各自适合什么场景。用这个拆法一道题就不再是孤立的答案而是变成一组可推导的判断。面试时无论从哪个角度追问你都有足够的上下文去应对。对每一道高频题都建议做一次这样的拆解。你会发现很多题目看起来不同底层其实是同一个问题缓存和数据库的一致性、分布式系统的可用性、性能和准确性的平衡。6.2 一个可执行的 3 天学习计划示例标题里提到 3 天学会这个说法当然有点夸张。但如果你的目标是快速建立 Redis 面试的知识框架3 天时间确实可以做一轮有侧重的学习。我提供一个可以参考的安排时间学习重点建议动作第 1 天数据结构与缓存场景复习 string、hash、list、set、zset 的适用场景用 Docker 起一个 Redis 实例模拟缓存穿透、击穿、雪崩的代码场景第 2 天分布式锁与持久化用SET NX EX写一个加锁释放锁的小示例比较 RDB 和 AOF 的不同配置思考锁过期和误删问题第 3 天集群与性能排查搭建一主两从或一个三主三从的 Redis 集群模拟从节点故障观察故障转移执行一次慢日志和 bigkey 扫描这个计划的重点是“动手验证”。Redis 面试题里很多结论只有亲手跑过才会理解。比如你单独看“主从复制是异步的”这句话很难有真实感受但如果你在主节点写入数据后立刻杀掉主节点然后看从节点少了哪条数据印象会深很多。如果时间不足至少要把 3 天计划压缩成“一天跑通主流程”的版本启动 Redis、自己做一次缓存读写、写一个带过期时间的分布式锁、再启动一个从节点看复制效果。6.3 面试和工程里的最终判断标准最后想给你一个判断标准当你学完一轮 Redis 后能不能回答下面三个问题。第一适不适合。面对一个场景你能不能说出 Redis 适合什么不适合什么。比如“这个接口用 Redis 做缓存合理用 Redis 做持久化存储则要谨慎”。第二为什么。当你提出一个方案时能不能解释背后的原因。比如“用allkeys-lru是因为这里 Redis 是缓存丢弃旧数据比拒绝新写入更合理”。第三极端情况怎么办。如果 Redis 挂了你的业务会出现什么问题如果 key 过期早了一秒会影响什么这种“边界意识”是面试官最能感受到你经验的地方。长期来看真正有用的不是背下 85 道题而是每用过一次 Redis都记录下当时的选择、踩过的坑、排查过的异常。把工具的使用经历沉淀成自己的判断比任何“面试天花板”都更有说服力。Redis 仍然会继续出现在后端、运维、大数据的各类场景里。与其焦虑题目数量不如先把缓存、分布式锁、集群这几条主线里的“为什么”想透。面试问题会变但底层判断永远有价值。