准备大厂Redis面试的那些事儿，边复习边写笔记分享经验

（引用来源：个人面试准备笔记与网络技术社区讨论汇总）

准备大厂Redis面试，感觉就像是要去征服一座高山，这座山风景绝佳，但山路崎岖，岔路很多，我当时的策略就是，不能光捧着书硬背，得一边学一边用自己的话把东西讲出来，写笔记就是个好方法，今天就分享一下我当时是怎么边复习边写笔记的,希望能给正在准备的你一点启发。

我首先明确了一个核心：大厂面试官不爱听死记硬背的概念，他们想听你理解后的东西，尤其是你遇到问题、解决问题的思路，所以我的笔记不是抄书,更像是自言自语式的问答和场景推演。

第一块笔记：从“是什么”深入到“为什么”

比如最基本的数据类型，光记String、List、Hash、Set、Zset这五种肯定不够，我的笔记里,每个类型旁边都会跟着几个问题和自己写的答案。

• String：笔记上除了写“最简单的KV”，我会加一句：“为啥简单场景都用它？因为底层实现简单（SDS），效率高，那它能存啥？不仅是字符串，数字、甚至序列化后的对象都可以，但要注意大小。” 然后我会自己问自己：“如果我要用String存一个用户对象（id,name,age），有什么优缺点？” 答案写下来：优点是简单，一次读写；缺点是更新某个字段（比如age）需要覆盖整个对象，网络传输量大，不如Hash高效,这样一下就把String和Hash的区别联系起来了。

• Zset（有序集合）：这是面试高频点，我不仅记了它是排序的Set，分数（score）排序，我更重点记了它的底层实现：“为啥Zset能这么快做范围查询？因为它用了跳表（SkipList）+哈希表，跳表负责排序和范围查询，哈希表负责单点查找（O(1)找到member对应的score）。” 然后我会画个丑丑的跳表示意图，旁边标注“为啥不用红黑树？因为跳表实现更简单，范围查询更方便，区间查询效率接近O(logN)。” 这个“为啥不用红黑树”就是面试官常问的。

（引用来源：《Redis设计与实现》及相关源码解析文章）

第二块笔记：把持久化机制当成故事来讲

RDB和AOF是必考的，但干巴巴说一个快照一个日志太苍白了,我的笔记里是这么组织的：

• 场景设定：假设我是Redis服务器，我的任务是不能丢数据,我有两种记忆方式。
• RDB（快照）：我把它比喻成“拍照片”，每隔一段时间，或者达到一定条件，我就咔嚓一声，把当前内存里的数据完整拍一张照片（dump.rdb文件）存到磁盘上。优点：照片文件小，恢复起来快（直接读入内存）。缺点：可能会丢数据（从上一次拍照到现在的记忆没了），我会在笔记里写下可能的问题：“如果设置每分钟拍一次照，但在第59秒服务器宕机了，会丢多久的数据？”——答案是最多丢59秒的数据。
• AOF（日志）：我把它比喻成“写日记”，我把每一次写操作命令都记到日记本（appendonly.aof文件）里。优点：数据更安全，最多丢一秒的数据（如果配置为每秒刷盘）。缺点：日记本会越来越厚（AOF文件大），恢复起来慢（得把所有的命令重新执行一遍）。
• 混合持久化：这就是故事的结局，取长补短，Redis 4.0后，我拍照（RDB）的时候，也会把拍照之后到现在的“日记”（AOF日志）一起存下来，恢复时，先快速加载照片，再重放一下照片之后的日记，又快又安全，我会在笔记里强调：“这是现在推荐的方案。”

第三块笔记：缓存问题——实战中的坑与解

这完全是场景驱动的笔记，我会列出几个经典难题,然后写下自己的解决方案。

1. 缓存穿透：有人一直查一个根本不存在的数据（比如不存在的用户ID），请求直接打到数据库，要把数据库打垮了。笔记解决方案：① 缓存空值，设置短过期时间。② 用布隆过滤器提前拦截，我会备注布隆过滤器的原理（一个很大的位数组+多个哈希函数，能判断“一定不存在”或“可能存在”），并注明它有误判率,但在这个场景下够用了。

   

2. 缓存击穿：一个热点key过期了，瞬间大量请求涌来击穿缓存，直接打向数据库。笔记解决方案：① 设置热点key永不过期。② 用互斥锁（分布式锁），只让一个请求去查数据库重建缓存，其他请求等待，我会简单画个流程图，表示请求到来->查缓存->不存在->尝试获取锁->获取成功则查库写入->释放锁；其他请求等待锁释放后直接读缓存。

3. 缓存雪崩：大量key在同一时间点过期，导致所有请求都打到DB。笔记解决方案：① 给过期时间加上随机值，打散过期时间。② 或者设置热点key永不过期。③ 也可以像击穿一样用加锁或队列来控制读数据库的线程数,但治本之策还是避免同时过期。

（引用来源：大量技术博客、论坛如掘金、Stack Overflow上的实战讨论）

第四块笔记：灵魂拷问——如何保证Redis高可用

主从复制、哨兵、集群，这部分我用了大量的框图，哪怕画得再丑,也要画。

• 主从复制：画一个Master，下面连几个Slave，旁边标注：数据异步同步，读扩展,但Master挂了需要人工干预。
• 哨兵（Sentinel）：在主从结构基础上，画几个哨兵小人在巡逻，标注它们的职责：监控、自动选主、通知客户端，笔记重点写：“哨兵解决了高可用问题，但它不是集群，容量有单机限制。”
• 集群（Cluster）：画一个由多个主从节点组成的网状图，标注核心：“数据分片（16384个槽位），每个节点存一部分数据，通过Gossip协议通信。” 我会问自己：“客户端怎么知道我要的数据在哪个节点？” 答案写下来：“客户端有缓存槽位映射信息，直接连接正确节点，如果节点返回MOVED错误，客户端会重定向。”

我的笔记里还有一个“实战案例”区，记录一些听来的或者自己设想的使用场景，如何用Redis实现秒杀扣减库存？”“如何用Redis实现排行榜？”用学到的知识去解决具体问题,印象特别深刻。

我的复习笔记就是：概念+自问自答+场景推演+丑图示意，这个过程强迫我不断思考“面试官可能会怎么问”，把零散的知识点串成解决问题的网络，希望我的这个“笨办法”能对你有点用。