面试官问我Redis，我背了八股文，他却问我“为什么缓存会雪崩”
那天的面试，我做了充分准备。Redis的数据结构、持久化、集群，全背得滚瓜烂熟。我甚至能在30秒内默写出一整套缓存穿透的“经典三连”。
面试官推了推眼镜，面带微笑，问了一个很常规的问题：“先聊聊Redis的数据结构吧。”
我心中一喜，这题我熟。我脱口而出：“Redis有五种基本数据类型：String、List、Hash、Set、ZSet，此外还有HyperLogLog、Geo、Bitmap等高级数据结构。”
他点了点头，然后追问：“如果让你自己实现一个ZSet，你打算用什么底层结构？”
我愣了一下。跳表？哈希表？我背过“ZSet底层使用压缩列表或跳表+哈希表”，但要我自己实现……我脑子里只剩下模糊的“跳表节点有层级，能二分查找”的碎片。
他又问：“那布隆过滤器解决缓存穿透，你清楚它的原理和误判率吗？知道为什么它说‘有不一定有，没有一定没有’吗？”
我张了张嘴，最终只挤出了一句：“它用多个哈希函数……应该跟位数组有关吧。”
面试官笑容不变，但我知道，这场面试已经开始偏离我背好的剧本了。
接下来的问题，一个比一个“要命”：
“缓存雪崩、缓存穿透、缓存击穿，听起来差不多，但它们到底有什么区别？实际生产环境里，你最怕遇到哪一种？”
“Redis的RDB和AOF，你说你都懂，那如果主库突然宕机，用哪种恢复得更快？混合持久化是怎么回事？”
“Redis的过期键删除策略，你说是定期删除加惰性删除，那在内存快满的时候，它会怎么选择淘汰哪些键？LRU和LFU到底有什么不同？”
“Redis集群模式下，如果一个节点挂了，整个集群还能正常服务吗？数据会不会丢？”
“你用Redis做过分布式锁，那SETNX加锁释放锁有什么问题？Redlock方案真的万无一失吗？”
“最后再问你一个基础的，为什么Redis这么快？除了内存操作，IO多路复用和单线程模型到底起了什么作用？”
我这才发现，自己所谓的“精通Redis”，不过是把一个个名词记下来，却从未真正理解它们为什么存在、在什么场景下会出问题、以及用怎样的思路去设计解决方案。
面试官大概看穿了我的窘迫，他合上电脑，温和地说了句：“背八股文能帮你过简历筛选，但真正让你站稳脚跟的，是你对这个技术底层逻辑的理解。我们招的不是搜索引擎，是能解决问题的人。”
那天我走出大楼，脑子里反复回放着他问的每一个问题。我决心不再只做一个“Redis关键词复读机”。下面这七道灵魂追问，就是我后来重新学习Redis时，一笔一笔记下的答案。
一、Redis底层数据结构：不止是五种类型
我们常说的String、List、Hash、Set、ZSet，只是对外的“抽象形态”。真正的底层实现，离不开这些结构：
简单动态字符串（SDS）：String的底层，除了存字符，还能存二进制数据，并且记录了长度和剩余空间，避免了C字符串的缓冲区溢出和频繁重分配。
双向链表：List的底层之一，插入快，但内存不连续。
压缩列表（ziplist）：一块连续内存，用变长编码存数据，省内存，但增删可能引起连锁更新。
哈希表：Hash和Set都可以用它实现，渐进式rehash避免一次性阻塞。
跳表（skiplist）：ZSet的核心，多层链表结构，查询平均O(log N)，比平衡树实现简单。
整数集合（intset）：当Set元素全是整数且数量较少时，底层用这个紧凑结构。
面试官让你实现ZSet，是想看你会不会在跳表、红黑树、压缩列表之间做权衡。你需要想到：数据量小的时候，用压缩列表可以省内存；数据量大了，为了快速查找和范围查询，需要引入跳表；同时还需要一个哈希表来根据成员快速找到分数。
布隆过滤器更是一个绝佳的例子。它本质上是一个长位数组加多个哈希函数。插入时，把每个哈希函数算出的位置都标为1；查询时，只要有一个位置为0，元素就一定不存在；如果全是1，大概率存在，但可能有哈希冲突造成的误判。你知道了这个原理，自然就能答出“它节省空间，但有误判率，且不能删除元素”。
二、缓存三兄弟：穿透、击穿、雪崩，别再傻傻分不清
缓存穿透：请求的数据既不在缓存也不在数据库，比如用不存在的用户ID不断刷接口。攻击者利用这点，能让请求全部落到数据库上。
防御思路：布隆过滤器快速过滤掉不存在的key；或者即使数据库没查到，也往缓存里写个空值，设置短过期时间。
缓存击穿：某个热点key在过期的瞬间，大量并发请求同时穿过缓存去查数据库。就好像盾牌上一个点被击穿了一样。
解法：互斥锁，只让一个线程去加载数据，其他等待；或者“永不过期”策略，物理不过期，由后台任务异步刷新。
缓存雪崩：某一时刻大量缓存key同时过期，或者缓存服务器整体宕机，导致请求全部压到数据库，系统崩溃。
解法：给过期时间加上随机值，避免集体到期；使用集群或哨兵模式保证缓存高可用；对数据库访问做限流和降级。
这三者之所以容易混淆，是因为它们都描述了“缓存失效导致数据库压力过大”的场景，但失效的原因和位置不同。你如果能清晰地区分“单个key失效”“热点key失效”和“大面积key失效”，就能在面试中展现出真实的系统思考。
三、持久化：RDB和AOF，不只是两种模式
Redis的数据都在内存里，断电会丢。所以它提供了RDB快照和AOF日志。
RDB：隔一段时间把整个内存数据保存到磁盘，是一个二进制压缩文件。恢复速度极快，但可能丢失最后一次快照之后的数据。
AOF：记录每个写操作命令，追加到文件末尾。数据安全性高，但文件体积大，重启恢复时要重新执行所有命令，速度慢。
混合持久化（Redis 4.0+）：AOF重写时，用RDB格式写入当前数据，再追加重写期间的增量AOF命令。这算是一种兼顾恢复速度和数据安全的“折中智慧”。
面试官问“宕机后谁恢复得快”，其实是想确认你是否理解两者的恢复逻辑：RDB直接加载数据，AOF要一条条重放命令。如果你负责核心交易系统，丢一秒数据都可能出事故，那大概率会选AOF配合混合持久化。
四、内存淘汰与过期删除：不要让Redis变成“垃圾场”
Redis作为一个内存数据库，必须精打细算。
过期键删除策略：Redis采用的是“惰性删除+定期删除”的组合拳。访问key时检查是否过期，这是惰性删除，省CPU但可能有大量过期键没被访问而赖着不走；所以又加上了定期删除——每隔一段时间随机抽查一批key，清除其中过期的。这种折中方案平衡了CPU和内存。
内存淘汰策略：当内存使用达到maxmemory上限时，Redis会根据配置的策略淘汰键：
noeviction：不淘汰，直接报错。
allkeys-lru：在所有键中用LRU算法淘汰。
volatile-lru：只在设置了过期时间的键中用LRU。
allkeys-lfu / volatile-lfu：Redis 4.0引入的LFU算法，淘汰最不常用的。
volatile-ttl：淘汰最快要过期的。
面试官可能会让你解释LRU和LFU的区别。LRU关注“最近一次使用距今多久”，LFU关注“使用频率有多高”。一个被访问过一次但再也没用过的key，在LRU下可能排在最后，但在LFU下会因频率低而被优先淘汰。这是热点数据保护和偶发性数据访问的权衡。
五、高可用：主从、哨兵、集群，层层递进
单机Redis扛不住高并发和大容量，于是有了一整套进化路线。
主从复制：从节点同步主节点的数据，实现读写分离，分担读压力。但主节点挂了不能自动切主。
哨兵模式：哨兵节点监控主从状态，当主节点下线，自动选举一个从节点升级为主。实现了自动故障转移，但数据容量仍然受单机限制。
Cluster集群：将数据按哈希槽分散到多个主节点，每个主节点还可以挂从节点。解决了水平扩展问题。集群内部通过Gossip协议通信，当某个节点故障，集群会尝试选举新的主节点。
“节点挂了集群还能工作吗？”这要分情况。如果挂的是从节点，或者主节点挂掉但还有从节点可以顶上去，集群在有故障转移能力的情况下依然可用；但如果一个哈希槽的所有主从节点都挂了，那这部分数据就彻底不可用了。
六、分布式锁：从SETNX到Redlock，每一步都踩坑
用Redis实现分布式锁是最常见的面试题之一。最简单的方式是用 SET key value NX EX 10 来加锁，用 Lua 脚本保证判断和删除的原子性。
但单机Redis有单点故障风险。于是引入了Redlock算法：在多个相互独立的Redis主节点上依次尝试加锁，当在大多数节点上加锁成功且总耗时小于锁的有效期时，才算获得锁。
然而，Redlock也饱受争议。分布式系统专家Martin Kleppmann指出，Redlock假设节点间时钟是一致的，而实际环境中时钟漂移可能导致锁失效；另外，GC暂停也可能使锁超时未被释放。所以，在对一致性要求极高的金融场景，更多人选择基于ZooKeeper或etcd的锁。
面试官想听的，是你对“为什么SETNX不够”“Lua脚本干什么用”“Redlock的假设和局限”的思考过程。
七、Redis为什么快？单线程的“纯粹”与IO多路复用的魔法
这个问题几乎是必考题。Redis官方宣称单线程也能支撑每秒数十万请求，秘诀有三：
纯内存操作：大部分操作都在内存中完成，没有磁盘IO的拖累。
单线程模型：避免了多线程的上下文切换和锁竞争，也不用考虑数据结构的并发安全，代码简洁高效。注意，Redis 6.0引入了多线程处理网络读写，但核心命令执行依然是单线程。
IO多路复用：基于epoll/kqueue等系统调用，一个线程可以同时监听多个客户端连接，有请求时才读取处理，空闲时就去干别的。这和Nginx、Node.js的思路如出一辙。
你如果能顺势谈一下“为什么Redis单线程还能处理大键值的阻塞问题”，比如KEYS命令会阻塞，应该用SCAN渐进式遍历，或者大键值删除时用UNLINK异步回收，面试官对你的评价会立刻上升一个档次。
走出那场面试之后，我给自己定了一条规矩：每学一个技术，都要问自己三次“为什么”——
它为什么存在？它为什么这样设计？它在什么情况下会出问题？
Redis也好，任何技术也好，面试官从来不是考你的记忆力。他们想看到的，是你面对一个系统时，能像工程师一样拆解风险、评估方案、权衡利弊的能力。
下一次，当你再被问到“缓存穿透怎么解决”，不要只回答“布隆过滤器”四个字。试着说出布隆过滤器的位数组是怎么回事，哈希函数的个数如何影响误判率，以及为什么它不适合删除。你会发现，面试官的眼神，从那一刻开始，已经变了。
你在面试中被问到过哪些让你“卡壳”的Redis问题？或者你对哪一块的底层原理最感兴趣？评论区聊聊，我们一起把那些“背完就忘”的八股文，变成真正属于自己的知识。