我先说个前提这篇文章不是给你背答案的。Redis 在面试里被问到的频率基本和 JVM、MySQL 并列为“后端三幻神”。我自己面过不少人也被人面过Redis 这块从“数据类型”一直追问到“集群脑裂”从“缓存穿透”一路追问到“分布式锁失效”每一层都能卡掉一批人。这套《Redis 16卷》就是我把这些年高频出现、容易翻车的考点重新梳理了一遍每一卷都尽量拆到“为什么”这个层面而不是只告诉你“是什么”。适合谁看准备 Java/后端岗位面试的应届生和初中级开发以及想系统查漏补缺、准备跳槽的朋友。里面会涉及一些命令示例和线上实践的坑你要是还没用过 Redis建议先装一个玩玩光看是记不住的。1. 数据结构面试第一关也是翻车重灾区这一块几乎所有面试官都会问但大多数人只背了个名字。String、List、Hash、Set、ZSet 谁都会说可底层编码、适用边界、为什么选这种结构才是拉开差距的地方。1.1 五大基础类型不能只会说名字String 是最常用的但面试官一追问“底层是什么”很多人就开始含糊了。Redis 的 String 底层是 SDSSimple Dynamic String不是 C 语言的 char*。SDS 有三个关键点长度获取是 O(1)因为结构体里存了 len二进制安全能存图片、序列化对象这类带\0的数据内存分配有预分配和惰性释放的机制减少系统调用次数。这三点展开说就是一道完整的加分题。List 的底层在 Redis 3.2 之后是 QuickList把多个 ZipList 用双向指针串起来。老版本是 LinkedList ZipList 的组合。面试问到这个你最好能说清楚 ZipList 是连续内存块、省内存但插入改造成本高QuickList 是在节省内存和读写性能之间取的折中。另外 List 经常被用来做消息队列但注意它只是简单的消息列表没有 ack 机制消费者挂了消息就丢了这点可以主动提出来显得你有真实项目经验。Hash 底层有两种编码ZipList 和 Hashtable。当字段少、值短时用 ZipList 省内存超过阈值默认 512 个字段或某个值长度超过 64 字节就转成 Hashtable。Set 底层是 IntSet 或 Hashtable当所有元素都是整数且数量少时用 IntSet用二分查找内存极省。ZSet 更复杂底层是 ZipList 跳表 字典的配合当数据量大时用跳表加字典字典存 member 到 score 的映射跳表按 score 排序。能把这个组合讲清楚的基本就能过这关了。1.2 三种特殊类型面试中的加分项也是挖坑项Bitmap、HyperLogLog、Geo 这三个常被忽略但面试官偶尔会拿来试试你知识面。Bitmap 本质上是 String 的位操作用于记录大量布尔状态比如用户签到。1 亿用户的一天签到用 Bitmap 只要 12.5MB 左右。命令是 SETBIT/GETBIT/BITCOUNT还能用 BITOP 做集合运算。HyperLogLog 用于基数统计比如统计页面 UV。标准误差 0.81%但内存固定只要 12KB不管你有多少数据量。原理是伯努利过程估算用哈希后低位连续零的个数来估算随机数规模。不用把原理背得特别深但至少要知道“用很小的内存近似统计不重复元素有误差适合非精确场景”。Geo 是用 ZSet 实现的经纬度会被转成 52 位整数作为 score 存进去支持附近的人查询。这个考点相对冷门但一旦问到能说出“Geo 本质是 ZSet”就是亮点。1.3 SDS 为什么是 Redis 的“亲儿子”很多人背了 SDS 的三个优点就结束了其实面试官更想听你理解“为什么 Redis 作者不直接用 C 字符串”。C 字符串求长度要遍历O(n)SDS 直接读 lenO(1)。C 字符串不能存二进制遇到\0就截断SDS 用 len 判断结尾二进制安全。C 字符串拼接要手动分配内存一旦忘记就可能内存溢出SDS 在 API 内部做了扩容检查并且空间预分配会多申请一些内存减少频繁 realloc。我印象很深有一次面试我答到“空间预分配”面试官直接追问“预分配多少”。这里有个细节修改后字符串长度小于 1MB预分配等于现在的 len大于等于 1MB预分配 1MB 固定增量。能说出这个说明你不是只看了概念是真读过源码或笔记。1.4 跳表为什么能笑到最后ZSet 的排序用跳表而不是红黑树这几乎是必问的。跳表本质上是有序链表加了多级索引查找时可以跳过大量节点时间复杂度 O(logN)。它和红黑树的对比关键点有三个实现简单、范围查询友好、支持灵活调整索引层数。红黑树范围查询要从最小节点开始中序遍历跳表可以从任一节点正序或倒序遍历代码也好写得多。Redis 作者甚至说过“我不想用红黑树跳表更简单且性能足够”。ZSet 还有一个冷门考点为什么 ZSet 既是字典又是跳表字典存 member→score用于 O(1) 查某个 member 的分值跳表按 score 排序用于范围查询。两者配合增删改时要同步维护这也是 ZSet 写入成本高于普通结构的原因。2. 持久化、过期与淘汰面试官最爱连环问Redis 是内存数据库但数据要落盘否则一重启全没了。持久化这块RDB 和 AOF 的基本区别不难难的是“Redis 默认怎么配”、“混合持久化怎么理解”、“AOF rewrite 做过没有”。过期策略和内存淘汰策略也高频出现这块答得好说明你对线上稳定性有概念。2.1 RDB 与 AOF两种持久化的底层对比RDB 是某个时间点的全量快照生成 dump.rdb 文件。优点文件紧凑恢复最快适合做备份和灾备。缺点是按时点触发比如 900 秒内 1 次修改、300 秒内 10 次修改、60 秒内 10000 次修改两次快照之间宕机数据会丢一大截。AOF 是追加写命令日志默认每秒刷盘appendfsync everysec最多丢 1 秒数据比 RDB 可靠得多。但 AOF 文件会越写越大所以需要 rewrite 机制。AOF rewrite 不是“对原文件进行压缩”而是基于当前内存里的数据重新生成一组最少的写命令来代表当前状态。比如一个 key 被 set 了 100 次rewrite 后就只剩一次 set 命令。面试进阶点RDB 和 AOF 能同时用吗能。Redis 重启时会先加载 AOF如果开关打开因为 AOF 数据更完整。4.x 之后还支持混合持久化把 RDB 快照和 AOF 增量命令合在一个文件里兼具两者的启动速度和数据可靠性。生产环境我一般建议开启混合持久化并同时保留 RDB 文件用于定期备份。2.2 过期的三类删除策略为什么选了这两类Redis 的过期删除采取“惰性删除 定期删除”结合。惰性删除每次读取 key 时检查是否过期过期就删并返回空。定期删除每隔一段时间默认 100ms随机抽取一些设置了过期时间的 key检查是否过期删除其中过期的如果抽样中过期比例超过 25%继续抽直至比例低于 25% 或耗时超限。为什么不搞“定时删除”因为每个 key 建一个定时器太废资源高并发下撑不住。惰性删除的缺点是有些 key 过期了但一直没被访问就会一直占内存所以要靠定期删除兜底。这个“兜底”思路面试官特别爱听。还有个小细节从节点默认不主动删除过期 key主节点删了之后会向从节点发 DEL 命令。如果你在主节点发现 key 没了从节点库里还能查到一直到主从同步 DEL这是正常现象不是 bug。2.3 内存淘汰8 种策略到底怎么选Redis 达到 maxmemory 之后会根据 maxmemory-policy 决定淘汰逻辑。默认是 noeviction不淘汰直接报错生产上通常改成 allkeys-lru 或 volatile-lru。完整 8 种策略策略作用范围淘汰依据noeviction全部不淘汰写入报错allkeys-lru全部 key按 LRU 近似算法淘汰allkeys-lfu全部 key按访问频率淘汰4.0allkeys-random全部 key随机淘汰volatile-lru设置了过期时间的 key按 LRU 淘汰volatile-lfu设置了过期时间的 key按 LFU 淘汰volatile-random设置了过期时间的 key随机淘汰volatile-ttl设置了过期时间的 key淘汰剩余 TTL 最短的这里有一个经典问题LRU 和 LFU 有什么区别实际怎么选。LRU 是最近最少使用基于访问时间LFU 是最近最不频繁使用基于访问频率。举个例子某个 key 昨天被大量访问今天没被访问如果是 LRU它容易被淘汰如果是 LFU因为历史频率高它可能被保留。热点业务我倾向 LFU普通缓存用 allkeys-lru 就够。另一个注意点Redis 的 LRU 是近似实现不是严格 LRU它在内存池中随机采样 5 个 key可配置 maxmemory-samples去淘汰最久没访问的那个所以并不保证全局最优。3. 缓存三大难题与分布式锁背下来不等于会用这部分是面试重灾区中的重灾区。缓存穿透、击穿、雪崩几乎每次必问分布式锁更是从“怎么加锁”能追问到“锁失效了怎么办”。我见过很多候选人能背出“布隆过滤器”、“互斥锁”、“随机过期时间”这些关键词但一问到具体实现细节就卡住。这一块必须在纸上把逻辑推演一遍。3.1 缓存穿透、击穿、雪崩三个听起来像却完全不同的场景缓存穿透请求的数据在缓存和数据库都不存在每次请求都打到数据库。比如查一个不存在的用户 ID缓存没数据数据库也没有就穿透了。解决思路有四层接口层做参数校验非法 ID 直接拒绝缓存空值并设置短过期时间使用布隆过滤器把存在的 ID 提前放进去不存在的直接拦截如果数据量不大可以用 Redis 的 Bitmap 做黑白名单。缓存击穿某个热点 key 刚好过期大量请求同时打过来全部落到数据库。注意它和穿透的区别——击穿是“有”但“过期了”穿透是“根本没有”。解决方式互斥锁只让一个线程去查库并回填缓存其它线程等待适合一致性要求高的场景逻辑过期把过期时间放在 value 里读到时发现逻辑过期就返回旧值并异步更新适合一致性要求低、但性能要求高的场景。缓存雪崩大面积 key 在同一时间过期或 Redis 实例宕机导致大量请求打到数据库。解决方式过期时间加随机值比如在基础过期时间上加 1~300 秒避免同时失效多级缓存比如 Redis 上层加一层本地缓存Caffeine/GuavaRedis 高可用主从哨兵或集群避免单点。3.2 分布式锁从 SETNX 到 Redisson再到 Redlock 的争论最基础的分布式锁是 SET key value NX EX seconds。NX 保证只有 key 不存在时才能设置成功EX 设置过期时间防止死锁。但注意value 必须是唯一标识比如 UUID释放锁时要先比较 value 再删且比较和删除要用 Lua 脚本保证原子性。很多人忽略这个直接DEL key就可能把别人刚获取的锁给删了。正确释放锁的 Luaif redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end紧接着面试官会问“锁过期了但业务还没执行完怎么办”。标准答案是用 Redisson 的看门狗机制。Redisson 在获取锁之后会启动一个后台定时任务默认每 10 秒锁的默认 leaseTime 是 30 秒续期一次把锁重新设置成 30 秒。业务没跑完锁就一直续业务跑完手动释放锁并取消续期任务。看门狗这个叫法很形象锁就像一条狗主人每 10 秒喂一次主人没了狗就饿死锁就过期释放。如果你能主动提到“看门狗”面试官大概率会往深处问Redlock 是什么Redis 集群模式下分布式锁还能用吗。Redis 作者提出 Redlock思想是向多个独立 Redis 节点依次加锁超过半数成功才算加锁成功。但这个方案在业内争议非常大有个叫 Martin Kleppmann 的分布式系统专家专门写文章批评过核心问题在于 GC pauseJava 垃圾回收停顿可能导致锁在持有者不知情的情况下“看起来还存在”而另一个节点又抢到锁两把锁同时存在破坏互斥性。所以我在面试时通常这么答单机 Redis Redisson 足够覆盖大多数业务追求严格互斥需要 Redlock 或引入 ZooKeeper/etcd但这会引入新的复杂性和性能开销业务上要谨慎评估。这个回答表现出你懂实际取舍不会盲目背 Redis 官方方案。3.3 缓存一致性先更新数据库还是先删缓存最推荐的方案是 Cache Aside Pattern读的时候先读缓存读不到就读数据库再回填缓存写的时候先更新数据库再删除缓存。为什么是“删缓存”而不是“更新缓存”因为更新缓存可能产生脏数据。假设两个线程并发写先写的后到把后写的值覆盖了缓存而数据库是最新的先写的值缓存就旧了。删缓存则不同下次读请求发现缓存 miss会从数据库拉最新值回填天然自愈。但这个模式也有窗口期线程 A 更新数据库线程 B 读缓存发现 miss读数据库拿到旧值并回填线程 A 再删缓存。此时缓存里已经又是旧值了。业界常见的解决方式是“延迟双删”先删缓存再更新数据库过几百毫秒再删一次缓存。第一次删除是为了让读请求读库回填最新值第二次删除是为了清掉中间那段时间可能被写回缓存的旧值。注意延迟时间要大于一次业务读的时间通常取 500ms 到 1s但这不是绝对精确的方案只能降低概率。我个人在项目里更常用的是“先更新数据库删除缓存配合消息队列或 binlog 订阅做最终一致性”。比如用 Canal 监听 MySQL binlog一旦有数据变更就发消息由消费者删除对应缓存。这样即使删除缓存失败也能靠消息重试补偿。面试时说出这套组合已经超过大多数只背了“双删”的人。4. 高可用架构主从、哨兵、集群你方唱罢我登场单机 Redis 永远不是终点。面试官问主从复制、哨兵、Cluster是想知道你懂不懂“Redis 怎么撑住大规模线上流量”而不只是会用单机。这个模块内容多且杂我分成三个部分讲清楚。4.1 主从复制全量同步和增量同步的完整链路主从复制分两个阶段全量同步 增量同步。全量同步发生在从节点第一次连接主节点或主从之间的数据差距太大导致无法增量同步时。流程是从节点发送 PSYNC 命令带上主节点 IDreplid和偏移量offset主节点收到后如果判断需要全量则开始生成 RDB 快照并发送给从节点同时在缓冲区记录生成快照后的写命令从节点清空旧数据加载 RDB再接收缓冲区里的增量写命令最终追平主节点。主节点还可能在 RDB 生成期间缓存写命令这部分就是增量同步的基础。增量同步的核心是复制偏移量和环形缓冲区。主节点处理每条写命令都会增加自己的 offset并写入 backlog 缓冲区默认 1MB。从节点带着自己的 offset 向主节点请求同步主节点把 backlog 中比从节点 offset 更新的命令发给从节点如果 offset 已经不在 backlog 里了就从全量重新同步。这个“追不上就全量”的取舍很重要面试时点出来说明你理解为什么主从之间断连太久会触发全量同步而不是一直走增量。实操中的坑默认 repl-backlog-size 是 1MB如果主从断连期间写入量大backlog 很容易被覆盖导致从节点重连后直接全量同步。高写入主从环境下把 backlog 调大比如 64MB~256MB是常见优化。另一个常见坑是主节点 fork 生成 RDB 时可能阻塞需要确保可用内存足够且在业务低峰期触发全量。4.2 哨兵从主观下线到故障转移哨兵Sentinel是一个独立部署的进程用于监控主从节点的健康状态。它本身是多个实例组成一个小集群避免单点。核心流程分三步第一主观下线。单个哨兵发现某个节点在 down-after-milliseconds 时间内没有心跳响应就标记为主观下线。第二客观下线。只有当一个哨兵判定主观下线后它会向其他哨兵询问当超过 quorum 数量的哨兵都认为该主节点下线了才真正判定为客观下线。第三故障转移。哨兵集群通过内部投票选举一个 leader 哨兵这个选民用 Raft 算法由 leader 从从节点中挑选一个新的主节点并执行SLAVEOF no one让该从节点升级为主节点然后把新主节点信息广播给所有从节点和客户端。这里面试官经常会问新主节点怎么选优先级从高到低是配置文件里的 replica-priority 值越小越优先复制偏移量越大越优先数据越新runid 越小越优先兜底随机。另一个常见问题为什么需要多个哨兵因为单哨兵可能因为网络抖动误判主节点下线导致不必要的切换。多个哨兵投票能降低误判概率但 quorum 值要合理配置太大会导致真正故障时无法达成一致太小又可能误切换。4.3 Cluster 集群16384 个槽位和 CRC16 算法Redis Cluster 用分片的方式把数据分散到多个主节点上每个主节点负责一部分哈希槽slot总计 16384 个槽位。写入时客户端对 key 计算 CRC16 后对 16384 取模得出该 key 落在哪个槽进而路由到对应节点。这里有个细节客户端需要知道哈希槽和节点的映射表所以客户端在收到 MOVED 错误时需要重定向到正确节点。一个最常被追问的细节为什么槽位数是 16384而不是 65536Redis 作者在 GitHub 上有过解释。节点之间通过心跳包交换槽位信息心跳包大小有限制槽位数越大槽位信息在心跳包中占的字节就越多16384 个槽位用 2KB 的 bitmap 就能表示65536 需要 8KB网络开销更大。另外集群主节点数量一般不会超过 1000 个16384 个槽位已经足够分了。Cluster 的容灾是主从模式每个主节点至少挂一个从节点。当主节点挂了其从节点会被提升为主节点。如果主节点和它的所有从节点都挂了该分片的数据就不可用了。这也是为什么生产环境主节点要分布在不同的物理机器上避免一个机房断电导致整个 Redis 集群不可用。5. 性能调优与线上排查八股文的最终落点面试官在前面几轮问八股文到最后往往会转向“你线上怎么排查问题”。这个时候你再背“缓存穿透是…”就不够看了得拿出真实操作经验来。这一块我把 Redis 变慢、大 key、热 key、慢查询这些高频问题做个系统梳理。5.1 Big Key 和 Hot Key两个看似简单却反复出事的家伙Big Key 指某个 key 的 value 特别大比如一个 List 里有几百万条数据一个 Hash 有几十万个字段。危害非常直接单条命令耗时高阻塞 Redis网络传输占用高导致其他命令排队删除时可能引起长时间阻塞比如DEL一个几百万元素的 ListRedis 会卡住很久。排查命令redis-cli --bigkeys这个命令会遍历所有 key并对不同类型做不同统计String 看 value 长度Set/List/Hash/ZSet 看元素个数。但注意--bigkeys只给出每种类型里最大的几个 key不是全量排行更精确的可以用DEBUG OBJECT key看 key 的 serializedlength或者在客户端定期扫描统计。还有一个冷门工具是redis-cli --memkeys4.0 之后可以统计 key 的内存占用。Hot Key 指某个 key 被超高频率访问。比如秒杀商品、热搜词都集中在同一个 key 上导致单分片 CPU 飙高。排查工具redis-cli --hotkeys需要开启 LFU 淘汰策略、monitor 命令观察实时命令、或通过代理层统计。解决方向本地缓存 Redis 两级缓存对热 key 加随机后缀拆分成多个 key分散读写压力如果热 key 还有写操作还可以用读写分离把读压力分散到从节点。5.2 慢查询和阻塞命令Redis 变慢的常见原因Redis 是单线程模型指命令执行线程一个命令执行耗时过长所有后续命令都会排队等待这就是“变慢”的根源。用SLOWLOG GET可以查看慢命令重点排查耗时超过 100ms 的命令。常见阻塞点有三个复杂命令比如KEYS *、SMEMBERS大集合、SORT、ZRANGEBYSCORE大范围查询这类命令算法复杂度高生产环境要换用 SCAN 或分页大 key 的删除和过期比如DEL大集合、大量 key 集中过期纯属释放内存引发的阻塞解决方式是分批删除或用UNLINK4.0异步删除fork 阻塞RDB 持久化和 AOF rewrite 都需要 fork 子进程fork 过程会阻塞主进程内存越大阻塞越明显。一个印象很深的线上案例是某服务高峰期每两小时一次 RDBfork 耗时就 300ms直接导致一批请求超时。后来我们把 RDB 方式调整到业务低峰触发才解决。5.3 Redis 变慢的几个配置级坑Redis 变慢的问题第一反应不要总想着是命令问题也可能是配置和系统层面的问题。内存碎片率高INFO memory里 mem_fragmentation_ratio 过高时内存碎片会导致内存量和耗时不正常。解决方案是开启activedefrag yes或在低峰期重启节点、执行CONFIG SET activedefrag yes。还有vm.overcommit_memory设置成 1这个参数影响 fork 是否能成功分配内存。transparent_hugepage建议关闭它会让 Redis 在 fork 时性能下降。这种系统层参数你在面试时能说出来会显得非常有实战经验。swap 也是一个坑。如果 Redis 内存被系统交换到磁盘读写性能会断崖式下降。排查方法看/proc/redis_pid/smaps里的 Swap 字段。如果出现 swap说明物理内存不足已经到瓶颈了。6. 高频连环炮与避坑清单面试现场模拟最后这部分我根据真实面试提问习惯整理出几个高频连环炮并给出答法要点和避坑清单。这部分价值在“预演”你最好能自己把每个问题口头复述一遍。6.1 我见过最狠的一套连续追问面试官“你们项目里 Redis 怎么用的”候选人“做缓存、分布式锁还存一些热点数据。”面试官“那缓存和数据库的一致性怎么保证”候选人“先更新数据库再删缓存。”面试官“删缓存失败了呢”候选人“重试或者消息队列补偿。”面试官“删缓存成功了但读请求已经把旧值回填到缓存里了怎么办”能撑到这一层的人就已经不多了。最佳回答路径是先承认这是缓存一致性里最典型的竞态问题然后给出“延迟双删”的思路重点说明延迟时间的选择逻辑最后补一句“如果业务对一致性要求很高就不该只用缓存 数据库而是考虑同步更新或借助 binlog 订阅”。这比“我们用双删保底”要高级得多。另一套连环炮是关于分布式锁的“你用 Redis 做分布式锁锁过期了但业务没执行完怎么办”“看门狗续期。”“看门狗是怎么实现的”“Redisson 在加锁后启动一个定时任务每 10 秒续期一次。”“如果主节点挂了锁还没复制到从节点请求又打到从节点了怎么办丢锁了怎么办”这个问题非常现实答案是Redis 主从切换导致的锁丢失在极端场景下无法完全避免要么接受这个概率要么上 Redlock/etcd/ZooKeeper 提升一致性要么在业务层面做幂等兜底。面试官问到这里其实不在考察你“会不会用 Redlock”而是考察你有没有“在真实场景里权衡过一致性成本”。6.2 Redis 面试避坑清单这些坑我见人踩过无数次背概念时只答名字不给细节。比如“ZSet 是跳表实现的”却没有解释为什么是跳表或者跳表和字典是怎么配合的。把 Redis 说成“多线程模型”。Redis 6.0 引入多线程主要是为了网络 IO 处理核心命令执行仍是单线程。说“多线程”会被盯上。把缓存穿透和缓存击穿搞混。穿透是查不存在的数据击穿是热点 key 过期雪崩是大面积 key 同时过期。这三个定义如果说不清基本凉了。分布式锁直接DELkey不知道要先比较 value 再删。这一个细节足以暴露是否真的写过代码。把 RDB 和 AOF 说反。RDB 是快照AOF 是命令日志RDB 恢复快但可能丢数据多AOF 恢复慢但丢数据少。在主从环境下回答持久化策略时忽略了从节点的配置。生产环境一般从节点也要开备份但根据需求也可以关掉避免磁盘压力。说到 Cluster 时不知道 MOVED 和 ASK 重定向的区别。MOVED 是槽位已经永久迁移到另一个节点ASK 是槽位正在迁移只是临时请求去别的节点查一次。能说出这个区别的候选人非常少。6.3 一个我压箱底的实战技巧SCAN 命令替代 KEYS这是我觉得最实用的一条线上千万别说KEYS *。这个命令会遍历所有 key单线程直接卡死整个 Redis轻则上百毫秒重则秒级。正确做法是SCAN cursor [MATCH pattern] [COUNT count]它一次返回一批 key 和下一个游标可以分多次遍历完所有 key。但注意 SCAN 不保证每次返回固定数量COUNT 只是提示不是精确限制。这个点面试提到或者在项目里落地都很有说服力。另外排查大 key 也别用DEL用UNLINK。UNLINK 是异步删除主线程发起后立即返回由后台线程慢慢释放内存。但也要注意 UNLINK 只处理 value 节点如果 key 对应的内存特别大它依然会让后台线程耗时只是不会阻塞主线程。删除大 key 的正确姿势是能用 UNLINK 就用不能用就分批删比如 Hash 的 HSCAN HDEL千万别一次性 DEL。拿我自己举例最早一次线上事故就是误用KEYS cache:*清理过期缓存导致 Redis 瞬间阻塞了 5 秒数据库瞬间被打爆幸好是低峰期扩容后抢救回来。后来我把所有清理逻辑都改成 SCAN并且在代码层面禁用了 KEYS 命令通过 rename-command 配置。这种事踩过一次你就知道为什么大家这么强调命令复杂度了。7. 背诵之外Redis 值得你多走一步面试八股文能帮你过面试但 Redis 真正的价值在工作里。我强烈建议你在准备面试期间顺手做三件事装一个 Redis 6.x 或 7.x把常用命令手敲一遍用 Redis 的 Docker 镜像搭一个主从 哨兵环境自己触发一次故障转移用redis-cli --stat观察线上 Redis 的实时命令统计学会读 INFO 的关键指标。这三件事做完你对 Redis 的理解会比单纯背八股文高一个档次。最后分享一个小技巧面试时如果要讲缓存雪崩不要只说“过期时间加随机值”。加随机值本质上只是打散过期时间避免同时失效真正抗雪崩需要多级缓存和限流降级的配合。你把这个层次讲出来面试官会觉得你不是背答案是真的处理过流量冲击的人。
Redis 面试核心知识点全梳理：从数据结构到高可用架构
我先说个前提这篇文章不是给你背答案的。Redis 在面试里被问到的频率基本和 JVM、MySQL 并列为“后端三幻神”。我自己面过不少人也被人面过Redis 这块从“数据类型”一直追问到“集群脑裂”从“缓存穿透”一路追问到“分布式锁失效”每一层都能卡掉一批人。这套《Redis 16卷》就是我把这些年高频出现、容易翻车的考点重新梳理了一遍每一卷都尽量拆到“为什么”这个层面而不是只告诉你“是什么”。适合谁看准备 Java/后端岗位面试的应届生和初中级开发以及想系统查漏补缺、准备跳槽的朋友。里面会涉及一些命令示例和线上实践的坑你要是还没用过 Redis建议先装一个玩玩光看是记不住的。1. 数据结构面试第一关也是翻车重灾区这一块几乎所有面试官都会问但大多数人只背了个名字。String、List、Hash、Set、ZSet 谁都会说可底层编码、适用边界、为什么选这种结构才是拉开差距的地方。1.1 五大基础类型不能只会说名字String 是最常用的但面试官一追问“底层是什么”很多人就开始含糊了。Redis 的 String 底层是 SDSSimple Dynamic String不是 C 语言的 char*。SDS 有三个关键点长度获取是 O(1)因为结构体里存了 len二进制安全能存图片、序列化对象这类带\0的数据内存分配有预分配和惰性释放的机制减少系统调用次数。这三点展开说就是一道完整的加分题。List 的底层在 Redis 3.2 之后是 QuickList把多个 ZipList 用双向指针串起来。老版本是 LinkedList ZipList 的组合。面试问到这个你最好能说清楚 ZipList 是连续内存块、省内存但插入改造成本高QuickList 是在节省内存和读写性能之间取的折中。另外 List 经常被用来做消息队列但注意它只是简单的消息列表没有 ack 机制消费者挂了消息就丢了这点可以主动提出来显得你有真实项目经验。Hash 底层有两种编码ZipList 和 Hashtable。当字段少、值短时用 ZipList 省内存超过阈值默认 512 个字段或某个值长度超过 64 字节就转成 Hashtable。Set 底层是 IntSet 或 Hashtable当所有元素都是整数且数量少时用 IntSet用二分查找内存极省。ZSet 更复杂底层是 ZipList 跳表 字典的配合当数据量大时用跳表加字典字典存 member 到 score 的映射跳表按 score 排序。能把这个组合讲清楚的基本就能过这关了。1.2 三种特殊类型面试中的加分项也是挖坑项Bitmap、HyperLogLog、Geo 这三个常被忽略但面试官偶尔会拿来试试你知识面。Bitmap 本质上是 String 的位操作用于记录大量布尔状态比如用户签到。1 亿用户的一天签到用 Bitmap 只要 12.5MB 左右。命令是 SETBIT/GETBIT/BITCOUNT还能用 BITOP 做集合运算。HyperLogLog 用于基数统计比如统计页面 UV。标准误差 0.81%但内存固定只要 12KB不管你有多少数据量。原理是伯努利过程估算用哈希后低位连续零的个数来估算随机数规模。不用把原理背得特别深但至少要知道“用很小的内存近似统计不重复元素有误差适合非精确场景”。Geo 是用 ZSet 实现的经纬度会被转成 52 位整数作为 score 存进去支持附近的人查询。这个考点相对冷门但一旦问到能说出“Geo 本质是 ZSet”就是亮点。1.3 SDS 为什么是 Redis 的“亲儿子”很多人背了 SDS 的三个优点就结束了其实面试官更想听你理解“为什么 Redis 作者不直接用 C 字符串”。C 字符串求长度要遍历O(n)SDS 直接读 lenO(1)。C 字符串不能存二进制遇到\0就截断SDS 用 len 判断结尾二进制安全。C 字符串拼接要手动分配内存一旦忘记就可能内存溢出SDS 在 API 内部做了扩容检查并且空间预分配会多申请一些内存减少频繁 realloc。我印象很深有一次面试我答到“空间预分配”面试官直接追问“预分配多少”。这里有个细节修改后字符串长度小于 1MB预分配等于现在的 len大于等于 1MB预分配 1MB 固定增量。能说出这个说明你不是只看了概念是真读过源码或笔记。1.4 跳表为什么能笑到最后ZSet 的排序用跳表而不是红黑树这几乎是必问的。跳表本质上是有序链表加了多级索引查找时可以跳过大量节点时间复杂度 O(logN)。它和红黑树的对比关键点有三个实现简单、范围查询友好、支持灵活调整索引层数。红黑树范围查询要从最小节点开始中序遍历跳表可以从任一节点正序或倒序遍历代码也好写得多。Redis 作者甚至说过“我不想用红黑树跳表更简单且性能足够”。ZSet 还有一个冷门考点为什么 ZSet 既是字典又是跳表字典存 member→score用于 O(1) 查某个 member 的分值跳表按 score 排序用于范围查询。两者配合增删改时要同步维护这也是 ZSet 写入成本高于普通结构的原因。2. 持久化、过期与淘汰面试官最爱连环问Redis 是内存数据库但数据要落盘否则一重启全没了。持久化这块RDB 和 AOF 的基本区别不难难的是“Redis 默认怎么配”、“混合持久化怎么理解”、“AOF rewrite 做过没有”。过期策略和内存淘汰策略也高频出现这块答得好说明你对线上稳定性有概念。2.1 RDB 与 AOF两种持久化的底层对比RDB 是某个时间点的全量快照生成 dump.rdb 文件。优点文件紧凑恢复最快适合做备份和灾备。缺点是按时点触发比如 900 秒内 1 次修改、300 秒内 10 次修改、60 秒内 10000 次修改两次快照之间宕机数据会丢一大截。AOF 是追加写命令日志默认每秒刷盘appendfsync everysec最多丢 1 秒数据比 RDB 可靠得多。但 AOF 文件会越写越大所以需要 rewrite 机制。AOF rewrite 不是“对原文件进行压缩”而是基于当前内存里的数据重新生成一组最少的写命令来代表当前状态。比如一个 key 被 set 了 100 次rewrite 后就只剩一次 set 命令。面试进阶点RDB 和 AOF 能同时用吗能。Redis 重启时会先加载 AOF如果开关打开因为 AOF 数据更完整。4.x 之后还支持混合持久化把 RDB 快照和 AOF 增量命令合在一个文件里兼具两者的启动速度和数据可靠性。生产环境我一般建议开启混合持久化并同时保留 RDB 文件用于定期备份。2.2 过期的三类删除策略为什么选了这两类Redis 的过期删除采取“惰性删除 定期删除”结合。惰性删除每次读取 key 时检查是否过期过期就删并返回空。定期删除每隔一段时间默认 100ms随机抽取一些设置了过期时间的 key检查是否过期删除其中过期的如果抽样中过期比例超过 25%继续抽直至比例低于 25% 或耗时超限。为什么不搞“定时删除”因为每个 key 建一个定时器太废资源高并发下撑不住。惰性删除的缺点是有些 key 过期了但一直没被访问就会一直占内存所以要靠定期删除兜底。这个“兜底”思路面试官特别爱听。还有个小细节从节点默认不主动删除过期 key主节点删了之后会向从节点发 DEL 命令。如果你在主节点发现 key 没了从节点库里还能查到一直到主从同步 DEL这是正常现象不是 bug。2.3 内存淘汰8 种策略到底怎么选Redis 达到 maxmemory 之后会根据 maxmemory-policy 决定淘汰逻辑。默认是 noeviction不淘汰直接报错生产上通常改成 allkeys-lru 或 volatile-lru。完整 8 种策略策略作用范围淘汰依据noeviction全部不淘汰写入报错allkeys-lru全部 key按 LRU 近似算法淘汰allkeys-lfu全部 key按访问频率淘汰4.0allkeys-random全部 key随机淘汰volatile-lru设置了过期时间的 key按 LRU 淘汰volatile-lfu设置了过期时间的 key按 LFU 淘汰volatile-random设置了过期时间的 key随机淘汰volatile-ttl设置了过期时间的 key淘汰剩余 TTL 最短的这里有一个经典问题LRU 和 LFU 有什么区别实际怎么选。LRU 是最近最少使用基于访问时间LFU 是最近最不频繁使用基于访问频率。举个例子某个 key 昨天被大量访问今天没被访问如果是 LRU它容易被淘汰如果是 LFU因为历史频率高它可能被保留。热点业务我倾向 LFU普通缓存用 allkeys-lru 就够。另一个注意点Redis 的 LRU 是近似实现不是严格 LRU它在内存池中随机采样 5 个 key可配置 maxmemory-samples去淘汰最久没访问的那个所以并不保证全局最优。3. 缓存三大难题与分布式锁背下来不等于会用这部分是面试重灾区中的重灾区。缓存穿透、击穿、雪崩几乎每次必问分布式锁更是从“怎么加锁”能追问到“锁失效了怎么办”。我见过很多候选人能背出“布隆过滤器”、“互斥锁”、“随机过期时间”这些关键词但一问到具体实现细节就卡住。这一块必须在纸上把逻辑推演一遍。3.1 缓存穿透、击穿、雪崩三个听起来像却完全不同的场景缓存穿透请求的数据在缓存和数据库都不存在每次请求都打到数据库。比如查一个不存在的用户 ID缓存没数据数据库也没有就穿透了。解决思路有四层接口层做参数校验非法 ID 直接拒绝缓存空值并设置短过期时间使用布隆过滤器把存在的 ID 提前放进去不存在的直接拦截如果数据量不大可以用 Redis 的 Bitmap 做黑白名单。缓存击穿某个热点 key 刚好过期大量请求同时打过来全部落到数据库。注意它和穿透的区别——击穿是“有”但“过期了”穿透是“根本没有”。解决方式互斥锁只让一个线程去查库并回填缓存其它线程等待适合一致性要求高的场景逻辑过期把过期时间放在 value 里读到时发现逻辑过期就返回旧值并异步更新适合一致性要求低、但性能要求高的场景。缓存雪崩大面积 key 在同一时间过期或 Redis 实例宕机导致大量请求打到数据库。解决方式过期时间加随机值比如在基础过期时间上加 1~300 秒避免同时失效多级缓存比如 Redis 上层加一层本地缓存Caffeine/GuavaRedis 高可用主从哨兵或集群避免单点。3.2 分布式锁从 SETNX 到 Redisson再到 Redlock 的争论最基础的分布式锁是 SET key value NX EX seconds。NX 保证只有 key 不存在时才能设置成功EX 设置过期时间防止死锁。但注意value 必须是唯一标识比如 UUID释放锁时要先比较 value 再删且比较和删除要用 Lua 脚本保证原子性。很多人忽略这个直接DEL key就可能把别人刚获取的锁给删了。正确释放锁的 Luaif redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end紧接着面试官会问“锁过期了但业务还没执行完怎么办”。标准答案是用 Redisson 的看门狗机制。Redisson 在获取锁之后会启动一个后台定时任务默认每 10 秒锁的默认 leaseTime 是 30 秒续期一次把锁重新设置成 30 秒。业务没跑完锁就一直续业务跑完手动释放锁并取消续期任务。看门狗这个叫法很形象锁就像一条狗主人每 10 秒喂一次主人没了狗就饿死锁就过期释放。如果你能主动提到“看门狗”面试官大概率会往深处问Redlock 是什么Redis 集群模式下分布式锁还能用吗。Redis 作者提出 Redlock思想是向多个独立 Redis 节点依次加锁超过半数成功才算加锁成功。但这个方案在业内争议非常大有个叫 Martin Kleppmann 的分布式系统专家专门写文章批评过核心问题在于 GC pauseJava 垃圾回收停顿可能导致锁在持有者不知情的情况下“看起来还存在”而另一个节点又抢到锁两把锁同时存在破坏互斥性。所以我在面试时通常这么答单机 Redis Redisson 足够覆盖大多数业务追求严格互斥需要 Redlock 或引入 ZooKeeper/etcd但这会引入新的复杂性和性能开销业务上要谨慎评估。这个回答表现出你懂实际取舍不会盲目背 Redis 官方方案。3.3 缓存一致性先更新数据库还是先删缓存最推荐的方案是 Cache Aside Pattern读的时候先读缓存读不到就读数据库再回填缓存写的时候先更新数据库再删除缓存。为什么是“删缓存”而不是“更新缓存”因为更新缓存可能产生脏数据。假设两个线程并发写先写的后到把后写的值覆盖了缓存而数据库是最新的先写的值缓存就旧了。删缓存则不同下次读请求发现缓存 miss会从数据库拉最新值回填天然自愈。但这个模式也有窗口期线程 A 更新数据库线程 B 读缓存发现 miss读数据库拿到旧值并回填线程 A 再删缓存。此时缓存里已经又是旧值了。业界常见的解决方式是“延迟双删”先删缓存再更新数据库过几百毫秒再删一次缓存。第一次删除是为了让读请求读库回填最新值第二次删除是为了清掉中间那段时间可能被写回缓存的旧值。注意延迟时间要大于一次业务读的时间通常取 500ms 到 1s但这不是绝对精确的方案只能降低概率。我个人在项目里更常用的是“先更新数据库删除缓存配合消息队列或 binlog 订阅做最终一致性”。比如用 Canal 监听 MySQL binlog一旦有数据变更就发消息由消费者删除对应缓存。这样即使删除缓存失败也能靠消息重试补偿。面试时说出这套组合已经超过大多数只背了“双删”的人。4. 高可用架构主从、哨兵、集群你方唱罢我登场单机 Redis 永远不是终点。面试官问主从复制、哨兵、Cluster是想知道你懂不懂“Redis 怎么撑住大规模线上流量”而不只是会用单机。这个模块内容多且杂我分成三个部分讲清楚。4.1 主从复制全量同步和增量同步的完整链路主从复制分两个阶段全量同步 增量同步。全量同步发生在从节点第一次连接主节点或主从之间的数据差距太大导致无法增量同步时。流程是从节点发送 PSYNC 命令带上主节点 IDreplid和偏移量offset主节点收到后如果判断需要全量则开始生成 RDB 快照并发送给从节点同时在缓冲区记录生成快照后的写命令从节点清空旧数据加载 RDB再接收缓冲区里的增量写命令最终追平主节点。主节点还可能在 RDB 生成期间缓存写命令这部分就是增量同步的基础。增量同步的核心是复制偏移量和环形缓冲区。主节点处理每条写命令都会增加自己的 offset并写入 backlog 缓冲区默认 1MB。从节点带着自己的 offset 向主节点请求同步主节点把 backlog 中比从节点 offset 更新的命令发给从节点如果 offset 已经不在 backlog 里了就从全量重新同步。这个“追不上就全量”的取舍很重要面试时点出来说明你理解为什么主从之间断连太久会触发全量同步而不是一直走增量。实操中的坑默认 repl-backlog-size 是 1MB如果主从断连期间写入量大backlog 很容易被覆盖导致从节点重连后直接全量同步。高写入主从环境下把 backlog 调大比如 64MB~256MB是常见优化。另一个常见坑是主节点 fork 生成 RDB 时可能阻塞需要确保可用内存足够且在业务低峰期触发全量。4.2 哨兵从主观下线到故障转移哨兵Sentinel是一个独立部署的进程用于监控主从节点的健康状态。它本身是多个实例组成一个小集群避免单点。核心流程分三步第一主观下线。单个哨兵发现某个节点在 down-after-milliseconds 时间内没有心跳响应就标记为主观下线。第二客观下线。只有当一个哨兵判定主观下线后它会向其他哨兵询问当超过 quorum 数量的哨兵都认为该主节点下线了才真正判定为客观下线。第三故障转移。哨兵集群通过内部投票选举一个 leader 哨兵这个选民用 Raft 算法由 leader 从从节点中挑选一个新的主节点并执行SLAVEOF no one让该从节点升级为主节点然后把新主节点信息广播给所有从节点和客户端。这里面试官经常会问新主节点怎么选优先级从高到低是配置文件里的 replica-priority 值越小越优先复制偏移量越大越优先数据越新runid 越小越优先兜底随机。另一个常见问题为什么需要多个哨兵因为单哨兵可能因为网络抖动误判主节点下线导致不必要的切换。多个哨兵投票能降低误判概率但 quorum 值要合理配置太大会导致真正故障时无法达成一致太小又可能误切换。4.3 Cluster 集群16384 个槽位和 CRC16 算法Redis Cluster 用分片的方式把数据分散到多个主节点上每个主节点负责一部分哈希槽slot总计 16384 个槽位。写入时客户端对 key 计算 CRC16 后对 16384 取模得出该 key 落在哪个槽进而路由到对应节点。这里有个细节客户端需要知道哈希槽和节点的映射表所以客户端在收到 MOVED 错误时需要重定向到正确节点。一个最常被追问的细节为什么槽位数是 16384而不是 65536Redis 作者在 GitHub 上有过解释。节点之间通过心跳包交换槽位信息心跳包大小有限制槽位数越大槽位信息在心跳包中占的字节就越多16384 个槽位用 2KB 的 bitmap 就能表示65536 需要 8KB网络开销更大。另外集群主节点数量一般不会超过 1000 个16384 个槽位已经足够分了。Cluster 的容灾是主从模式每个主节点至少挂一个从节点。当主节点挂了其从节点会被提升为主节点。如果主节点和它的所有从节点都挂了该分片的数据就不可用了。这也是为什么生产环境主节点要分布在不同的物理机器上避免一个机房断电导致整个 Redis 集群不可用。5. 性能调优与线上排查八股文的最终落点面试官在前面几轮问八股文到最后往往会转向“你线上怎么排查问题”。这个时候你再背“缓存穿透是…”就不够看了得拿出真实操作经验来。这一块我把 Redis 变慢、大 key、热 key、慢查询这些高频问题做个系统梳理。5.1 Big Key 和 Hot Key两个看似简单却反复出事的家伙Big Key 指某个 key 的 value 特别大比如一个 List 里有几百万条数据一个 Hash 有几十万个字段。危害非常直接单条命令耗时高阻塞 Redis网络传输占用高导致其他命令排队删除时可能引起长时间阻塞比如DEL一个几百万元素的 ListRedis 会卡住很久。排查命令redis-cli --bigkeys这个命令会遍历所有 key并对不同类型做不同统计String 看 value 长度Set/List/Hash/ZSet 看元素个数。但注意--bigkeys只给出每种类型里最大的几个 key不是全量排行更精确的可以用DEBUG OBJECT key看 key 的 serializedlength或者在客户端定期扫描统计。还有一个冷门工具是redis-cli --memkeys4.0 之后可以统计 key 的内存占用。Hot Key 指某个 key 被超高频率访问。比如秒杀商品、热搜词都集中在同一个 key 上导致单分片 CPU 飙高。排查工具redis-cli --hotkeys需要开启 LFU 淘汰策略、monitor 命令观察实时命令、或通过代理层统计。解决方向本地缓存 Redis 两级缓存对热 key 加随机后缀拆分成多个 key分散读写压力如果热 key 还有写操作还可以用读写分离把读压力分散到从节点。5.2 慢查询和阻塞命令Redis 变慢的常见原因Redis 是单线程模型指命令执行线程一个命令执行耗时过长所有后续命令都会排队等待这就是“变慢”的根源。用SLOWLOG GET可以查看慢命令重点排查耗时超过 100ms 的命令。常见阻塞点有三个复杂命令比如KEYS *、SMEMBERS大集合、SORT、ZRANGEBYSCORE大范围查询这类命令算法复杂度高生产环境要换用 SCAN 或分页大 key 的删除和过期比如DEL大集合、大量 key 集中过期纯属释放内存引发的阻塞解决方式是分批删除或用UNLINK4.0异步删除fork 阻塞RDB 持久化和 AOF rewrite 都需要 fork 子进程fork 过程会阻塞主进程内存越大阻塞越明显。一个印象很深的线上案例是某服务高峰期每两小时一次 RDBfork 耗时就 300ms直接导致一批请求超时。后来我们把 RDB 方式调整到业务低峰触发才解决。5.3 Redis 变慢的几个配置级坑Redis 变慢的问题第一反应不要总想着是命令问题也可能是配置和系统层面的问题。内存碎片率高INFO memory里 mem_fragmentation_ratio 过高时内存碎片会导致内存量和耗时不正常。解决方案是开启activedefrag yes或在低峰期重启节点、执行CONFIG SET activedefrag yes。还有vm.overcommit_memory设置成 1这个参数影响 fork 是否能成功分配内存。transparent_hugepage建议关闭它会让 Redis 在 fork 时性能下降。这种系统层参数你在面试时能说出来会显得非常有实战经验。swap 也是一个坑。如果 Redis 内存被系统交换到磁盘读写性能会断崖式下降。排查方法看/proc/redis_pid/smaps里的 Swap 字段。如果出现 swap说明物理内存不足已经到瓶颈了。6. 高频连环炮与避坑清单面试现场模拟最后这部分我根据真实面试提问习惯整理出几个高频连环炮并给出答法要点和避坑清单。这部分价值在“预演”你最好能自己把每个问题口头复述一遍。6.1 我见过最狠的一套连续追问面试官“你们项目里 Redis 怎么用的”候选人“做缓存、分布式锁还存一些热点数据。”面试官“那缓存和数据库的一致性怎么保证”候选人“先更新数据库再删缓存。”面试官“删缓存失败了呢”候选人“重试或者消息队列补偿。”面试官“删缓存成功了但读请求已经把旧值回填到缓存里了怎么办”能撑到这一层的人就已经不多了。最佳回答路径是先承认这是缓存一致性里最典型的竞态问题然后给出“延迟双删”的思路重点说明延迟时间的选择逻辑最后补一句“如果业务对一致性要求很高就不该只用缓存 数据库而是考虑同步更新或借助 binlog 订阅”。这比“我们用双删保底”要高级得多。另一套连环炮是关于分布式锁的“你用 Redis 做分布式锁锁过期了但业务没执行完怎么办”“看门狗续期。”“看门狗是怎么实现的”“Redisson 在加锁后启动一个定时任务每 10 秒续期一次。”“如果主节点挂了锁还没复制到从节点请求又打到从节点了怎么办丢锁了怎么办”这个问题非常现实答案是Redis 主从切换导致的锁丢失在极端场景下无法完全避免要么接受这个概率要么上 Redlock/etcd/ZooKeeper 提升一致性要么在业务层面做幂等兜底。面试官问到这里其实不在考察你“会不会用 Redlock”而是考察你有没有“在真实场景里权衡过一致性成本”。6.2 Redis 面试避坑清单这些坑我见人踩过无数次背概念时只答名字不给细节。比如“ZSet 是跳表实现的”却没有解释为什么是跳表或者跳表和字典是怎么配合的。把 Redis 说成“多线程模型”。Redis 6.0 引入多线程主要是为了网络 IO 处理核心命令执行仍是单线程。说“多线程”会被盯上。把缓存穿透和缓存击穿搞混。穿透是查不存在的数据击穿是热点 key 过期雪崩是大面积 key 同时过期。这三个定义如果说不清基本凉了。分布式锁直接DELkey不知道要先比较 value 再删。这一个细节足以暴露是否真的写过代码。把 RDB 和 AOF 说反。RDB 是快照AOF 是命令日志RDB 恢复快但可能丢数据多AOF 恢复慢但丢数据少。在主从环境下回答持久化策略时忽略了从节点的配置。生产环境一般从节点也要开备份但根据需求也可以关掉避免磁盘压力。说到 Cluster 时不知道 MOVED 和 ASK 重定向的区别。MOVED 是槽位已经永久迁移到另一个节点ASK 是槽位正在迁移只是临时请求去别的节点查一次。能说出这个区别的候选人非常少。6.3 一个我压箱底的实战技巧SCAN 命令替代 KEYS这是我觉得最实用的一条线上千万别说KEYS *。这个命令会遍历所有 key单线程直接卡死整个 Redis轻则上百毫秒重则秒级。正确做法是SCAN cursor [MATCH pattern] [COUNT count]它一次返回一批 key 和下一个游标可以分多次遍历完所有 key。但注意 SCAN 不保证每次返回固定数量COUNT 只是提示不是精确限制。这个点面试提到或者在项目里落地都很有说服力。另外排查大 key 也别用DEL用UNLINK。UNLINK 是异步删除主线程发起后立即返回由后台线程慢慢释放内存。但也要注意 UNLINK 只处理 value 节点如果 key 对应的内存特别大它依然会让后台线程耗时只是不会阻塞主线程。删除大 key 的正确姿势是能用 UNLINK 就用不能用就分批删比如 Hash 的 HSCAN HDEL千万别一次性 DEL。拿我自己举例最早一次线上事故就是误用KEYS cache:*清理过期缓存导致 Redis 瞬间阻塞了 5 秒数据库瞬间被打爆幸好是低峰期扩容后抢救回来。后来我把所有清理逻辑都改成 SCAN并且在代码层面禁用了 KEYS 命令通过 rename-command 配置。这种事踩过一次你就知道为什么大家这么强调命令复杂度了。7. 背诵之外Redis 值得你多走一步面试八股文能帮你过面试但 Redis 真正的价值在工作里。我强烈建议你在准备面试期间顺手做三件事装一个 Redis 6.x 或 7.x把常用命令手敲一遍用 Redis 的 Docker 镜像搭一个主从 哨兵环境自己触发一次故障转移用redis-cli --stat观察线上 Redis 的实时命令统计学会读 INFO 的关键指标。这三件事做完你对 Redis 的理解会比单纯背八股文高一个档次。最后分享一个小技巧面试时如果要讲缓存雪崩不要只说“过期时间加随机值”。加随机值本质上只是打散过期时间避免同时失效真正抗雪崩需要多级缓存和限流降级的配合。你把这个层次讲出来面试官会觉得你不是背答案是真的处理过流量冲击的人。