企业官网建设流程全解析

1. Redis面试考察什么：考点地图与应对策略

1.1 面试官到底在考察什么？

Redis 相关面试题几乎是后端岗位的必考项，这不奇怪。缓存是绝大多数业务系统的刚需，Redis 又是缓存选型里绕不开的那个。但说实话，很多人准备 Redis 面试题时容易走进一个误区——死记硬背答案。背几个面试题本身不难，难的是搞懂面试官问这些问题背后想验证什么。

我这几年面试过不少人，也在不少场合帮朋友模拟过面试。总结下来，面试官问 Redis 的问题，表面上看是在考知识点，本质上是在验证三件事：第一，你是否真的在项目里用过 Redis，而不是只在 Demo 里跑过几个命令；第二，你是否理解 Redis 的底层工作机制，而不是停留在 API 调用层面；第三，你遇到线上问题时，有没有一套完整的排查思路。这也是为什么面试题总是围绕那些“看似简单但能往深了追问”的点展开。

另外要明确一点：不同级别的岗位对 Redis 的考察深度完全不同。初级岗位可能问“Redis 有哪几种数据结构、各自的使用场景”，中高级岗位会问“缓存穿透怎么解决”“持久化怎么选型”，到了资深岗位，问的可能就是“集群扩容时槽位迁移怎么做”“如何设计多级缓存架构”这类偏架构设计的问题。准备面试之前，先对标一下自己应聘的级别，再决定投入多少精力去扣细节。

1.2 考点分级：从初级到高级的考察侧重点

我把 Redis 的面试考点按级别做了个拆解，这样复习的时候有方向感。这里也相当于给整篇文章画个地图，后面每个章节都会对应展开。

说白了，初级考“是什么”，中级考“怎么做”，高级考“为什么这么做以及不这么做会出什么问题”。这个分类不是绝对的，但大致符合绝大多数公司的面试设计。准备的时候，我建议按这个梯度去抽查自己：先保证每个基础概念能脱口而出，再画一遍每个机制的原理时序图，最后模拟一遍“线上 Redis 出问题了你怎么排查”的对话场景。

还有一个很多人忽略的点：面试官非常喜欢拿你项目里的实际场景来追问。你说你用 Redis 存了登录态，他会问你为什么不用 JWT；你说你做了缓存预热，他会问你预热失败怎么办、数据不一致怎么兜底。这些追问没有标准答案，但如果你平时踩过坑、有真实的对策，答出来的感觉是完全不一样的。这也是我写这篇文章时特别想传递的一个观点：面试题只是引子，背后考察的是真实经验。

2. 基础题型：数据结构与底层原理

2.1 五种基础类型的使用场景，别只会背官方文档

Redis 五种基础类型——String、Hash、List、Set、ZSet——是面试的第一道门槛。绝大多数人都能说出它们长什么样，但问到“你的项目里具体用了哪种、为什么选它”，很多人就含糊了。

String 是最常用的，缓存对象、计数器、分布式 ID 都能用。比如商品详情的缓存，把整个对象序列化成 JSON 存进 String，简单直接。但这里有个隐含考点：如果一个对象的字段经常要更新其中一个，String 方案就得整个取出来反序列化再塞回去，这时候 Hash 会更合适。Hash 支持对单个字段做 HGET、HSET，改动粒度更小，而且内存占用在字段数量不多时比 String 更有优势。所以面试里如果问你“用户信息缓存用什么存”，最好的回答不是背结论，而是说清楚“看更新频率和访问模式”。

List 的典型场景是消息队列、最新消息列表。用 LPUSH + BRPOP 实现简单的生产者消费者模式是 Redis 面试的常客，但这个方案有一个很值得说的缺陷：消息没有确认机制，消费者崩了消息就丢了；也没有重复消费控制。所以高级一点的回答会补一句“真正要求可靠性的场景，建议用专门的消息中间件，List 只适合做轻量级、允许少量丢失的任务队列”。这句话一出来，面试官就知道你踩过坑。

Set 和 ZSet 的考点主要集中在去重、交集并集、排行榜。ZSet 的底层是跳表 + 哈希表，这个组合让它在“范围查询 + 随机访问”两方面都有不错的表现。面试中比较经典的题目是“怎么用 Redis 实现一个排行榜并支持按分数区间查询”，回答时从 ZADD 写入、ZRANGEBYSCORE 查询、ZREVRANGE 取前 N 名讲起，再提一句分数相同时用时间戳做二级排序字段，基本就是满分答案。

我个人面试别人时最喜欢追问一个细节：ZSet 的跳表为什么不用红黑树实现？这个考点很刁钻，但确实能区分出有没有真正研究过源码。参考答案是：跳表在范围查询场景下不需要像红黑树那样做复杂的旋转调整，实现更简单，而且 Redis 本身是单线程模型，跳表不需要考虑并发加锁问题，插入删除的均摊复杂度跟红黑树一样都是 O(logN)。

2.2 底层编码与数据结构：一个容易被追问到死的点

五种基础类型只是表象，Redis 内部根据数据规模、元素长度、值大小，会动态选择不同的底层编码方式。这个知识点在面经里不算高频，但一旦被追问，答不上来特别减分。

• String：小整数用 int 编码，其他情况用 embstr（短字符串）或 raw（长字符串）。embstr 和 raw 的区分阈值是 44 字节（Redis 3.2+ 是 44，之前是 39）。
• Hash：元素少且值小时用 listpack（Redis 7.0 之前是 ziplist），超过阈值转 hashtable。
• List：Redis 3.2 之后用 quicklist（ziplist 组成的双向链表），Redis 7.0 之后引入了 listpack 重构。
• Set：元素全是整数且数量少时用 intset，否则用 hashtable。
• ZSet：元素少时用 listpack（老版本是 ziplist），超过阈值（默认 128 个元素、每个元素 64 字节）后转 skiplist。

这些阈值本身不一定要背得一字不差，但面试时如果能主动讲出“Redis 会根据数据特征自动选择编码方式，以小换大，节省内存”，就能体现你读过源码或者至少深入了解过实现。我面过不少候选人，能提到 ziplist 的有一些，但能继续说清楚 ziplist 的缺陷（连锁更新问题）以及 Redis 7.0 用 listpack 替代 ziplist 的原因，就凤毛麟角了。

listpack 和 ziplist 的核心区别是：ziplist 的每个节点保存了前一个节点的长度，删除或插入节点时可能导致后续节点的 prevlen 字段需要扩容，引发连锁更新，最坏情况下时间复杂度退化到 O(N²)；listpack 每个节点只保存自己的长度，彻底避免了连锁更新问题。这个点值得好好消化，面试中讲出来非常加分。

2.3 快速回答技巧：把记忆变成理解

准备数据结构这块，我给一个很实用的建议：不要按“数据类型 → 支持的命令 → 使用场景”的顺序去背，而是反过来——先想场景，再想类型，最后想命令。比如你做一个电商秒杀系统，需要扣减库存，你自然会想到 String 的 DECR 命令配合 Lua 脚本保证原子性；你做关注列表，自然想到 Set 的 SADD/SREM/SMEMBERS；你做 feed 流的时间线，自然想到 ZSet 按时间戳排序。

这样建立起来的认知是“以问题为导向”的，面试官不管你从哪个角度问，你都能绕回到“我为什么选它”这个核心上。

还有一个小细节：说数据类型的时候，尽量别只说 Redis 是单线程所以命令都是原子的。这句话本身没错，但只说这一句显得太单薄。更好的表达是：“Redis 的网络模型是单线程 Reator 模型，命令的执行阶段天然串行，所以单个命令是原子的；但多个命令组合在一起不是原子的，需要 Lua 脚本或事务来保证。另外 Redis 6.0 引入了多线程 I/O，但命令执行仍然是单线程。”这段话说出来，面试官对你的评价会高一个档次。

3. 核心机制：持久化、主从与集群

3.1 RDB 与 AOF 的对比：别只背结论，要会选型

持久化是 Redis 面试里绕不开的主干道。RDB 和 AOF 的区别大多数人都能说个大概：RDB 是快照，AOF 是命令日志。但面试官关心的不是这个，而是“你的业务场景下，你会选择哪种，为什么”。

RDB 的优点很突出：文件紧凑、加载速度快、适合做备份和灾备。缺点也同样突出：快照周期之间如果宕机，这部分数据就丢了。AOF 的优点是数据安全性更高，可以通过 appendfsync 策略控制丢失窗口；缺点是文件体积大、恢复速度慢。现代 Redis 还提供了混合持久化——AOF 文件里先放一个 RDB 快照，再追加后续的增量命令，兼顾了加载速度和数据安全。这个方案在实际生产环境用得非常多，面试时主动提出来很加分。

但这里我要提醒一个容易踩的坑：不要背诵持久化配置参数，而要理解每个配置背后的代价。比如 appendfsync 有三个选项：always 每个命令都刷盘，性能最差但最安全；everysec 每秒刷一次，性能和数据安全比较均衡，也是默认配置；no 交给操作系统决定刷盘时机，性能最好但数据丢失窗口最大。实际生产里绝大多数场景选 everysec，但如果你做的是金融类强一致业务，必须接受 always 的性能损耗，或者在架构层面做其他兜底。

RDB 触发的时机也经常被追问，比如 save 900 1 代表什么——900 秒内至少有 1 次写操作就触发快照。但这里有个隐藏问题：RDB 生成期间如果又有大量写入，Redis 怎么办？这就引出 fork 子进程 + 写时复制（COW）机制：子进程做快照时，父进程继续处理请求，内存页被修改时才复制一份给子进程。所以理论上 RDB 快照不会阻塞主线程太久，但如果写入量大，内存占用可能短暂翻倍。这个细节能解释“为什么 Redis 内存不能配置得太满”，面试官如果问到这里，说明他想考察你对底层机制的理解。

3.2 主从复制与哨兵：数据一致性的关键细节

主从复制是 Redis 高可用的基础。全量复制（RDB 文件同步）和增量复制（repl_backlog 缓冲区同步）这两个概念要掌握清楚，但面试中追问最多的是几个容易混淆的细节。

第一个细节：增量复制的核心是复制积压缓冲区（repl_backlog）。主节点维护一个环形缓冲区，从节点向主节点发送自己已复制的偏移量，主节点根据偏移量判断能否在缓冲区内找到这段历史。如果从节点断连太久，偏移量已经不在缓冲区内了，那就只能触发全量复制。所以面试时可以说“增量复制能不能成功，取决于 repl_backlog 的大小和断连时长”。

第二个细节：主从延迟。Redis 主从复制是异步的，主节点执行完写命令后立刻返回，从节点的同步是后续异步完成的。这意味着从节点上的数据总是有一定延迟。面试官最喜欢问“主从延迟导致数据不一致怎么办”，参考答案方向有：强制要求强一致的场景不读从节点；对一致性要求高的写操作等从节点确认（WAIT 命令，但会牺牲性能）；或者从架构上做拆分。

哨兵机制的核心是监控、选主、通知。这里有一个高频追问：“哨兵是怎么判断主节点挂了？”答案不只是“ping 超时”，而是主观下线和客观下线的两阶段判断。单个哨兵认为主节点不可达，是主观下线；多个哨兵（超过 quorum 数）都认为不可达，才是客观下线，然后触发故障转移。选主用的协议是 Raft 算法的简化版，这点能说出来绝对加分。

另一个容易忽略的点是脑裂问题。网络分区可能导致原来的主节点和哨兵失联，哨兵选出了新主节点；此时旧主节点恢复网络后，如果客户端还在往旧主节点写入，数据就会在故障转移后丢失。解法是调整两个参数：min-replicas-to-write（主节点至少要有多少个从节点才能接受写入）和 min-replicas-max-lag（从节点最大延迟）。限制主节点在最坏情况下的写入，是牺牲可用性换取数据安全的手段。这个知识点几乎年年出现在高级岗位的面试里，值得重点消化。

3.3 Cluster 集群：从“知道”到“能讲清楚”

如果你应聘的不是纯初级岗位，Redis Cluster 大概率会被问到。很多人的理解停留在“Redis 集群就是把数据分片存到多台机器上”，这远远不够。Cluster 的核心是 16384 个哈希槽，每个节点负责一部分槽位，key 通过 CRC16 算法计算后再对 16384 取模，决定落到哪个槽。这里有一个很容易被追问的细节：CRC16 算法算出来的值是 16 位，范围 0~65535，为什么取模的基数是 16384 而不是 65536？参考答案是：16384 个槽位在心跳包中用 2KB 的位图就能完整描述，消息更紧凑；而且槽位数量远大于集群节点数，迁移和负载均衡的粒度足够细。这个细节能说出来，说明你确实研究过设计文档。

Cluster 的另一个考点是数据迁移（resharding）。扩容、缩容都需要迁移槽位，迁移过程中 key 的访问要么去旧节点要么去新节点，Redis 的做法是让两个节点都临时保存这份数据，迁移完成后才从旧节点删除。这个过程对客户端是基本透明的，但会有一个 ASK 重定向和 MOVED 重定向的区别。MOVED 是告诉客户端“这个槽已经永久迁移到别的节点了，以后直接去那边”；ASK 是“槽还在迁移中，这次先帮你去目标节点查一次”。这两个词是面试中的高频考点，不要搞混。

Cluster 模式下还有一个问题值得准备：为什么 Cluster 模式不建议用多 key 操作。因为多个 key 可能分散在不同节点上，跨节点的多 key 操作需要额外协调，性能开销大。解决办法是使用 hash tag，例如 {user123}:profile 和 {user123}:orders，让包含相同花括号内容的 key 落在同一个槽位。这个知识不复杂，但能体现你对 Cluster 使用限制的理解。

4. 高频面试题：缓存三大问题与数据一致性

4.1 缓存穿透、击穿、雪崩：万变不离其宗的三件套

这三大问题是 Redis 面试的“必考三兄弟”，几乎每场面试都会遇到。很多人能背出概念和解决方案，但面试官真正想听到的是你如何在具体场景中做选择。

缓存穿透：查询一个不存在的数据，请求直接打到数据库。如果恶意攻击者反复用不存在的 key 发起请求，数据库压力会非常大。常规解法有三种：缓存空值（给不存在的 key 也缓存一个空值并设置较短的过期时间）、布隆过滤器（在缓存前面加一层 Bloom Filter，快速判断 key 是否可能存在）、参数校验（拦截明显非法的请求）。这里我想多说一句：布隆过滤器有误判率，适合“一定不存在”的拦截，但“可能存在”还是要放行到缓存/数据库去查。面试时能把误判率这个 trade-off 讲清楚，比单纯背方案高级得多。

缓存击穿：某个热点 key 突然过期，大量并发请求同时打到数据库。此处的关键字是“单个 key 过期”。解法集中在互斥锁和逻辑过期两种方案上。互斥锁的思路是：当缓存中没有数据时，让一个线程去重建缓存，其他线程等待或降级；逻辑过期的思路是：缓存中存储的数据带一个逻辑过期时间，实际不设置物理过期时间，后台异步线程发现过期后主动刷新。这两个方案各有优劣：互斥锁会让请求等待，存在阻塞风险；逻辑过期实现复杂，且短时间内返回的可能是旧数据。

缓存雪崩：大量 key 同时过期，导致数据库瞬间压力骤增。和击穿的区别是“多个 key 同时失效”。常规解法是给过期时间加一个随机偏移量，或者设计上错开过期时间；有条件的团队还可以用多级缓存做兜底。我个人在实际项目中验证过一个思路：把热点数据分成多个批次，每批次设置不同的过期时间，并配合定时任务主动预热。这样即使某一批过期，数据库压力也只是原来的一部分，不会瞬间击穿。

这三个概念最容易答串，我建议准备的时候用“一个 key 没有/两个以上 key 同时没有/一个热点 key 没有”来快速区分，面试前默念一遍，别紧张说混了。

4.2 缓存与数据库的一致性：先更新库还是先删缓存？

这是一道典型的“没有标准答案但必须能自圆其说”的题。面试官就是想看你在不一致窗口、失败重试、并发竞态这几个维度上有没有深入思考过。

先说结论，业界讨论最多的方案是Cache Aside（旁路缓存）模式：读的时候先读缓存，读不到再读数据库，并把数据写入缓存；写的时候先更新数据库，再删除缓存。为什么是“删除缓存”而不是“更新缓存”？因为更新缓存存在一个经典问题：如果两个线程并发写，后写的线程可能先完成数据库更新，导致缓存中的值被旧值覆盖。而删除缓存则没有这个问题——即使并发删除了两次，下次读取时缓存 miss，会从数据库拉取最新值。

但 Cache Aside 也不是完美的。先更新数据库、再删缓存，如果删缓存失败，缓存里还是旧数据。解法是引入重试机制，比如把删除操作发到消息队列里异步重试，或者订阅数据库的 binlog，通过 Canal 之类的中间件异步删除缓存。这个方向在大型项目中很常见，面试时能说出来是加分项。

还有一个变种：先删缓存，再更新数据库。这个方案在并发场景下更容易出问题。比如线程 A 删缓存，线程 B 读缓存 miss 后从数据库读到了旧值并写回缓存，接着线程 A 才更新数据库，结果缓存里是旧数据，而且下一次可能缓存还没过期就一直是旧数据。解法是设置比较短的过期时间做兜底，或者用延迟双删（更新数据库后再延迟几毫秒删一次缓存）。延迟双删的“延迟时间去多少”是个经验值，面试里可以诚实说“这个时间取决于业务读写的耗时，需要压测验证”，比硬背一个数字更真实。

4.3 分布式锁：能答到 Redisson 才算完整

分布式锁是 Redis 面试中和缓存三大问题并列的高频考点。最原始的实现是 SETNX + EXPIRE 两条命令，但这里有个经典的坑：如果 SETNX 成功之后、设置过期时间之前进程崩了，锁就永远不释放。所以现在的正确做法是用一条命令 SET key value NX EX 10 或 SET key value NX PX 10000，保证加锁和设置超时的原子性。

接下来容易被追问的就是“释放锁时怎么避免删掉别人的锁”。正确做法是加锁时设置一个唯一标识（比如 UUID + 线程 ID），释放锁时先 GET 对比、再 DEL，但这三步不是原子的，所以要用 Lua 脚本来保证原子性。这个细节我在面试里问过很多人，能答上来的确实不多。

再往深了走就是 Redisson 的实现。Redisson 提供的可重入锁底层其实是 Redis 的 Hash 结构，key 是锁名称，field 是线程标识，value 是重入次数。看门狗机制会在锁的有效期快结束但业务还没执行完时，自动把过期时间续期。这个机制是 Redisson 相比原生实现最核心的竞争力。

最后还有一个绕不开的话题：RedLock 算法。Redis 作者提出在多个 Redis 节点上分别加锁，要求多数节点加锁成功才算获取锁成功。但这个方案在学术界和工程界都有不少争议，最核心的批评是它依赖时钟同步，且在某些故障场景下安全性和可用性无法同时保证。面试时如果你能辩证地说“RedLock 不是银弹，多数场景下单机/主从 + Redisson 就够用，极端强一致场景应考虑 ZooKeeper/etcd 实现的锁”，面试官会刮目相看。

5. 性能排查：Big Key、热点 Key 与内存优化

5.1 Big Key 的排查与处理：这是线上事故重灾区

Big Key 是 Redis 运维中最常见的问题之一。一个 String 类型的 value 有几 MB，或者一个 List/Hash 里有几十万条元素，这在业务上可能不算什么，但对 Redis 来说就是性能隐患。为什么？因为 Redis 单线程模型下，处理一个巨型的 key 需要的时间远超普通 key，会阻塞后续所有命令；而且 Big Key 的删除也可能造成阻塞（比如 DEL 一个几十万元素的 List）。

排查 Big Key 的手段主要有两个：使用 redis-cli --bigkeys 命令扫描整个实例，它会按类型分类统计大的 key；或者用 SCAN 命令自己遍历，在每个 key 执行 STRLEN / LLEN / HLEN 等命令获取大小。这里要注意：--bigkeys 在线上压榨性能，尽量在低峰期执行，而且它默认只输出每种类型最大的 key，如果你想统计所有超过阈值的大 key，需要自己写脚本。

处理 Big Key 的思路可以分为切分、压缩、迁移三个方向。把一个大 key 拆成多个小 key（比如用哈希分片）是最常见的方式；如果 value 本身是 JSON 这类可压缩数据，可以考虑在业务层做压缩再存入 Redis；如果确实无法拆，可以用配置中心或限流策略控制对这个 key 的访问。

面试时如果能讲一个你真实遇到的 Big Key 案例，不管是排行榜数据膨胀还是用户关注列表无上限增长，都会让你的回答非常有说服力。

5.2 热点 Key 的识别与应对：架构层面如何兜底

热点 Key 是双十一这类高并发场景下的常见考题。某个商品详情页的 key 被大量请求读取，单台 Redis 的网卡、CPU 都可能被打满。识别热点 Key 的办法通常有四种：在客户端做统计（比如封装 Jedis/Redisson 的客户端，统计每个 key 的访问次数）；在代理层做统计；对访问日志离线分析；或者利用 Redis 4.0+ 的 LFU 淘汰策略做排查。

应对热点 Key 的经典思路是本地缓存 + 分布式缓存的多级模式。把热点 key 的数据在应用节点的本地内存里缓存一份，TTL 设置到几十秒，这样绝大部分请求根本不会打到 Redis。但这带来了数据一致性的问题，所以通常还要配合一个版本号或者更新时间戳，让本地缓存定时刷新。另一种思路是热点 Key 复制，把同一个热点 key 分散成多个副本 key（比如 info:1, info:2, ...），读取时随机选一个，让流量分散到不同节点。

这里有一个老生常谈又非常实用的建议：在监控系统里对热点 key 的访问量做实时告警。你可以用 Redis 的 monitor 命令做短时采样，也可以用现成的监控采集组件。出现热点 key 不奇怪，奇怪的是你们团队没有发现它的手段。面试官问热点 Key，很多时候是想考察你团队的监控意识和应急响应能力。

5.3 内存淘汰策略：从 maxmemory 到 LRU/LFU 的细节

Redis 内存淘汰策略在面试里出现的频率不算特别高，但一旦问到配置项，很多人就答不全面。maxmemory-policy 有八种取值，可以归类成三组：不淘汰（noeviction，默认策略）、只淘汰过期数据（volatile-lru、volatile-lfu、volatile-random、volatile-ttl）、全空间淘汰（allkeys-lru、allkeys-lfu、allkeys-random）。

很多项目把 maxmemory-policy 设成 allkeys-lru 就完事了，但这里隐藏着一个知识点：Redis 默认的 LRU 是近似 LRU，并不是严格的 LRU。因为严格 LRU 需要记录每个 key 的访问历史，内存代价太高。Redis 采用的是采样 + 淘汰池的近似方案：在待淘汰的 key 池中，取最近访问时间最久远的 key 淘汰。LFU（Least Frequently Used）同样也是近似实现，它用 Morris 计数器做访问频率的衰减统计，避免一个 key 因为历史访问频率太高而永远不被淘汰。

面试中回答内存淘汰策略时，我的建议是不要只报菜名，而是结合业务场景给出选型依据。比如你的缓存数据是商品信息，访问热度差异极大，用 allkeys-lfu 可能更合理；如果是验证码这类一次性数据，本身设置了 TTL，volatile-ttl 就够了；如果数据不能丢，那就得设置 noeviction，宁可报错也不要静默淘汰。

6. 面试实战心得与避坑清单

6.1 面试回答的节奏：先结论后细节

准备 Redis 面试题的最后一步，不是再多背几个知识点，而是练习怎么把知道的东西有条理地讲出来。我见过太多候选人，问一个问题能滔滔不绝讲十分钟，但面试官根本抓不到重点。这里我给一个亲测有效的方法：先给出结论和场景，再展开细节。

比如面试官问“Redis 为什么快”，不要一上来就讲 I/O 多路复用、单线程模型、纯内存操作。先用一句话概括“因为它把数据放在内存里，用高效的单线程事件循环避免了锁竞争和上下文切换，并且其精心设计的数据结构让操作效率更高”，然后再分点展开。这种“总-分”结构在面试中永远比“想到哪说到哪”更受欢迎。

还有一点很重要：不要装懂。Redis 的知识面非常广，面试官问到一个你没接触过的细节非常正常。这时候最差的回答是“这个我了解一点”然后开始乱编。比较好的处理方式是坦率地说“这个点我平时接触不多，但我可以尝试从原理上推导一下”。能从原理推导本身就是能力的体现，比硬编一个错误答案好得多。

6.2 高频错误回答：这几句话千万别说

我汇总几个在面试里反复听到的典型错误回答，这些都是很容易踩的坑：

第一，“Redis 是单线程的，所以它很快”。这句话只对了一半。Redis 6.0 之后引入了多线程 I/O，网络读写可以并行，命令执行仍然是单线程。如果你只说单线程，面试官一定会追问“为什么单线程还比多线程的 Memcached 快”，答不上来就尴尬了。

第二，“缓存穿透就加布隆过滤器”。这句话本质没错，但布隆过滤器解决的是“key 不存在”的场景，如果你的穿透来源是恶意构造大量不同的 key，布隆过滤器确实有效；但如果来源是缓存刚过期导致的大量 miss，那其实是击穿/雪崩，不是穿透。把三个问题混为一谈是面试官非常反感的。

第三，“我用 Redis 做分布式锁，用 SETNX 加锁就够了”。这句话在面试官耳朵里等于告诉你“我没踩过锁相关的高并发坑”。至少要补充唯一标识、过期时间、Lua 脚本释放、看门狗续期这些要素，才能证明你真的在生产环境里用过。

第四，回答持久化问题时只字不提混合持久化。现代 Redis 默认开启 aof-use-rdb-preamble，很多人不知道，这个问题在现代面试中已经算送分题了。

6.3 加分表现：怎么把普通答案变精彩

Redis 面试题不仅考察知识量，还考察工程判断力。同样一个问题，两个候选人的答案可能信息量差不多，但表现力差很多。我说几个我实际观察到的加分表现：

主动用“我们线上遇到过”“之前压测发现”这类真实经验开头。比如面试官问缓存雪崩，你可以在给完解决方案后补一句“之前我们遇到过一个凌晨瞬时流量很高的场景，后来在缓存过期时间上加了随机值，效果非常明显”。真实性是编不出来的，经验会让你的答案自带说服力。

把方案放进成本收益的框架里讲。Redis 的每个机制都有 trade-off，面试官最怕听到“最优解”三个字。没有什么最优解，只有这个业务容不容易接受不一致窗口、接不接受缓存丢失、允不允许请求阻塞。答完一个方案主动说出它的适用边界和代价，是非常高级的回答方式。

对底层细节有好奇心。比如讲到 List 的阻塞命令 BRPOP，如果你能顺带说一句“BRPOP 的实现是当列表为空时，把客户端挂到一个等待队列上，等生产者 LPUSH 后通过 ready 机制唤醒”，面试官对你的评价会完全不同。

写在最后

我见过太多人把 Redis 面试准备当成背诵练习，这是一个很大的误区。面试官问 Redis，其实问的是你有没有真正处理过缓存相关问题，有没有系统思考过数据一致性、高可用、性能瓶颈背后的原理。本文梳理的这些考点基本覆盖了市面上 90% 以上的 Redis 面试题方向，但每个话题往深里挖都还有大量细节。

我个人准备面试时有个习惯：对每个核心考点，用自己的话写一段“如果别人问我，我会怎么讲”的稿子，然后反复删减到两分钟以内。这个练习逼着我不断提炼重点，也让我在面试现场回答问题时不至于东拉西扯。建议你拿到这篇文章后，也选几个最薄弱的章节，按这个方法练一练。面试不是考试，是交流，你能把一个问题讲明白、讲透彻，面试官自然能感受到你的水平。