主题 13Redis 原理与缓存

13.1这道题为什么必考

面试官问 Redis，不是想听「内存数据库、支持持久化、五种数据类型」。他想知道的是： 你有没有在真机上被它坑过。坑过的人，说话会带数字。

13.2单线程为什么还能跑 6 万 QPS

「单线程」这三个字最容易被误解成「只能一件一件干，所以慢」。它的真实含义是： 命令的执行是串行的，但连接的收发不是。验证方法很土但很硬—— 让一条命令睡 2 秒，看另一个连接还能不能动：

=== 单线程的证据 ===
连接 A 执行 DEBUG SLEEP 2（2028 ms 返回）
连接 B 在此期间 PING 花了 1978 ms  <-- 被堵住了

两个连接、两条完全无关的命令，B 却整整等了 1978 毫秒。这就是单线程： 执行命令的只有一个线程，A 在睡，谁都别想动。

那为什么它快？因为「快」不是靠并行算出来的，是靠把等待全省掉：

「一条慢命令拖死所有人」不是理论。下面这条 KEYS 在 20 万个 key 上跑了一次：

已写入 200000 个 key
KEYS u:*  返回 200000 个，耗时 441 ms
SCAN  count=1000  扫回 200000 个，200 批，耗时 654 ms（每批最多堵 3.3 ms）

总耗时 SCAN 反而更长（654ms > 441ms），但它把 441 毫秒的一次长阻塞 切成了 200 次 3.3 毫秒的短阻塞。对线上服务来说，前者是不可接受的尖刺， 后者用户根本感觉不到。这就是为什么生产环境禁 KEYS 而不禁 SCAN。

再来看真实吞吐（redis-benchmark -n 20000 -c 50，本机 Windows 单实例）：

13.3五种类型，其实只有几种编码

「五种数据类型」是对外的说法。对内，Redis 只认几种数据结构， 类型到结构之间是可以切换的——这才是面试真正想听的。

先看最简单的 string。同一个 SET，存进去的东西不一样，底层编码完全不同：

=== string 的三种编码 ===
set s:int 12345        int        encoding:int serializedlength:3
set s:emb hello        embstr     encoding:embstr serializedlength:6
set s:float 3.14       embstr
append 前 int -> append 后 raw，值=123456

三种编码的分工：

APPEND 那行值得多看一眼：12345 本来是 int， 追加一个字符之后就变成 raw 了。因为它不再是整数了，只能退回字符串。 反过来也成立，实测 INC 之后 raw 会变回 int：

set n2 100; append n2 0   -> raw  值 1000
incr n2                   -> int  值 1001

其余四种类型的编码，一次跑完：

=== list ===              （配置 list-max-listpack-size = -2，即每节点 8KB）
rpush 128 个       listpack     mem=927
rpush 500 个       listpack     mem=3531
rpush 5000 个      quicklist    ql_nodes:5  mem=35308

=== hash ===              （hash-max-listpack-entries = 512）
hset 512 个字段     listpack
hset 513 个字段     hashtable
value 64 字节 -> listpack ；再来 65 字节 -> hashtable

=== set ===
100 个整数          intset
513 个整数          hashtable
3 个字符串          listpack
1 个字符串+128 个整数  listpack
1 个字符串+129 个整数  hashtable

=== zset ===             （zset-max-listpack-entries = 128）
zadd 128 个        listpack    mem=1183
zadd 129 个        skiplist    mem=10607

整理成一张对照表：

13.4编码转换的几个临界点（含三个反教科书结论）

上一节的阈值不能只记结论，得知道卡在哪一字节。逐个逼近边界：

① hash：512 与 513 之间

511 个字段 -> listpack
512 个字段 -> listpack
513 个字段 -> hashtable

教科书常说 128，Redis 8 的默认值是 512。执行 CONFIG GET hash-max-listpack-entries 自己看一眼，别背。

② list：不是按元素个数，是按字节

默认 list-max-listpack-size = -2，负数的含义是「按大小算」，-2 对应 8KB。 用每个 5 字节的元素去逼近：

1637 个 = 8185 字节 -> listpack
1638 个 = 8190 字节 -> quicklist
1639 个 = 8195 字节 -> quicklist

边界卡在 8185 和 8190 之间——正好是 8192 减掉 listpack 头部那几字节。 所以「list 超过 128 个元素就转 quicklist」这个说法在默认配置下是错的： 你塞 1500 个短元素，它依然是一个 listpack。

③ string：embstr 的上限和 key 的长度有关

教科书的标准答案是「44 字节以内用 embstr」。实测 Redis 8.10.3 上，41 字节就变 raw 了。 再换不同的 key 长度扫一遍，规律出来了：

key 长度 -> value 能内嵌的最大长度
  key=  1 字节 -> value 最多 40 字节
  key=  5 字节 -> value 最多 36 字节
  key= 10 字节 -> value 最多 31 字节
  key= 20 字节 -> value 最多 21 字节
  key= 30 字节 -> value 最多 11 字节
  key= 40 字节 -> value 最多  1 字节
  key= 60 字节 -> value 最多  0 字节

key 长度 + value 长度 ≈ 41，这是一条很整齐的直线。再看内存占用就更明白了：

value=40 embstr mem=64
value=41 raw    mem=65
value=44 raw    mem=68

64 这个数字是关键：jemalloc 的 64 字节档。Redis 8 把 key 也内嵌进了同一个对象 （源码里叫 kvobj，比 robj 多存了 kvBits 和 key 的 SDS）， 所以「对象头 + key + value」三者加起来必须塞进 64 字节的 arena—— key 多占一个字节，value 就少一个字节。

④ 转换是单向的

hash 从 513 个字段转成 hashtable 之后，把字段删回 1 个：

字段 513 个时 hashtable；删到 1 个字段后 hashtable

不会退回 listpack。因为转换是有成本的，Redis 不想在边界上反复横跳。 这也意味着一个「曾经很大」的 key，即使后来被清空，内存也不会自己还给你—— 大 key 清理后要 DEL 重建，不能指望它瘦回去。

13.5过期了，为什么不删

「给 key 设了 TTL，到点就没了」——这句话对，但只对了一半。到点只是「逻辑上过期」， 物理内存还在。用一个 20 万 key 的实验看清楚：先关掉定期删除，只留惰性删除。

=== 过期删除 ===
已关闭定期删除（DEBUG SET-ACTIVE-EXPIRE 0），只剩惰性删除
写入 200000 个带 10 秒 TTL 的 key：
  dbsize=200000  used_memory=17.6 MB  expired_keys=0
等待 12 秒...
12 秒后（全部已过期，但没人访问）：
  dbsize=200000  used_memory=16.5 MB  expired_keys=0
  随机抽 3 个 key 看 TTL： [-2, -2, -2]
  EXISTS e:5 连问 3 次： [0, 0, 0]
  之后 expired_keys=4  dbsize=199996

两个关键事实：

• TTL 全返回 -2（键已不存在），但 DBSIZE 还是 200000—— 过期时间到了 ≠ 内存被回收了；
• used_memory 只从 17.6 掉到 16.5 MB（掉的是 TTL 字典本身），数据体还在。

而且注意 expired_keys 从 0 跳到 4，dbsize 掉了 4 个—— 可我只显式访问了 e:5 一个 key。答案是：TTL 命令本身也会触发惰性删除， 我抽了 3 个 key 看 TTL，加上 EXISTS，一共 4 次。

把 1000 个过期 key 逐个 GET：

逐个 GET 1000 个 key（惰性删除，每个 key 被访问时才真正回收）：
  耗时 476.8 ms，expired_keys=1002  dbsize=198998

平均每个 0.48 ms——比正常 GET（0.5 ms 含网络）差不多，因为删除本身很快。 但如果这 1000 个 key 是 1000 个用户同时访问，那就变成了 1000 次「访问时才发现要删」的抖动。

打开定期删除，看它多久收拾残局：

重新打开定期删除，观察它多久清完：
  4.1 秒后 dbsize=0  expired_keys=200000  used_memory=0.8 MB
active-expire-effort = 1

4.1 秒清完 19.9 万个。定期删除不是「每秒扫全库」，而是随机抽样： 每次抽 20 个，如果过期比例超过 25% 就再来一轮。active-expire-effort（1–10） 控制每秒的工作量，调大清理更积极、但更吃 CPU。

装不下的时候：八种淘汰策略

=== 淘汰策略 ===
空库 used_memory = 1.12 MB
设置 maxmemory=20mb, policy=noeviction
写了 72313 个 200 字节的 key 后：OutOfMemoryError
  报错原文: command not allowed when used memory > 'maxmemory'.
  used_memory=20.0 MB  evicted_keys=0
切成 allkeys-lru，继续写 5 万个...
  dbsize=73545  evicted_keys=48867  used_memory=20.0 MB

同一个 20MB 上限，两种策略的差别是报错还是活下来：

13.6穿透：数据库被打穿的那一层

先把三个词分清楚，这是最容易被问倒的地方：

穿透最典型的场景：接口按 id 查用户，攻击者拿 id=999999 一直刷。 每次缓存都不命中，每次都打到库。实测（数据库每次 20ms）：

=== 缓存穿透：查一个不存在的 id ===
--- A. 串行 200 次（模拟爬虫一个个刷）---
  不缓存空值：回源 200 次，耗时  4171 ms
  缓存空值  ：回源   1 次，耗时    46 ms  占位值='__NULL__' TTL=60s
--- B. 并发 200 个同时打（空值缓存挡不住）---
  缓存空值 + 200 并发：回源 200 次  <-- 同一瞬间都 miss，占位值还没写进去

这两行是全章最重要的对照组。「缓存空值」把 200 次打到 1 次， 但它挡不住「同一瞬间的 200 个请求」——因为在第一个请求把 __NULL__ 写进去之前， 其余 199 个都已经判定「缓存没有」了。

要挡并发，得在缓存前面再加一层，让「不存在」这件事不用查库就能判断。 布隆过滤器就是干这个的（这里用 bitmap 手写，生产用 RedisBloom 模块或 Guava）：

=== 布隆过滤器（bitmap 手写：20000 位，3 个哈希）===
放入 1000 个真实 id：置位 2768 / 20000 个 bit（13.8%）
拿 10000 个不存在的 id 去查：误判 29 个，误判率 0.29%
  也就是说 10000 次攻击只有 29 次会打到数据库，其余 99%+ 在 Redis 这层被挡掉

这个 0.29% 不是撞运气，可以用公式算出来：

p ≈ (1 - e^(-k·n/m))^k
  = (1 - e^(-3×1000/20000))^3
  = (1 - 0.8607)^3
  = 0.0027  = 0.27%

实测 0.29%，理论 0.27%，差的那点来自哈希分布不均。面试时把 m、n、k 三个字母和这个公式写出来， 比说「布隆过滤器能防止穿透」强十倍。

13.7击穿：一个热点 key 过期，200 个请求一起回源

穿透是「数据不存在」，击穿是「数据存在，但那一瞬间缓存没了」。差别在于回源的那一下非常贵—— 比如一个 100ms 的复杂查询。200 个并发同时来，三种写法各跑一遍，看回源次数和延迟分布：

=== 缓存击穿：热点 key 刚过期，200 个并发同时来（DB 每次 100ms）===
A 无保护        回源 200 次 | p50 101.2 ms | p99  109.0 ms | 最慢  122.4 ms
B 互斥锁        回源   1 次 | p50  18.3 ms | p99  145.6 ms | 最慢  182.8 ms
C 逻辑过期      回源   1 次 | p50   7.1 ms | p99   16.5 ms | 最慢   19.0 ms

这三行值得逐列读：

• A 无保护：200 个请求全部打到库，200 次 × 100ms 的数据库压力。 更糟的是它没报错——只是数据库 CPU 突然 100%，然后整个系统雪崩。
• B 互斥锁：回源降到 1 次，但 p99 145.6 ms 比 A 还差。 因为 199 个线程在自旋等锁，谁抢到谁才 18ms 返回，排在最后的要等完整一轮。 「加锁保护数据库」的代价是把延迟转嫁给了用户。
• C 逻辑过期：回源也是 1 次，但 p99 只有 16.5 ms，比 B 好 8.8 倍。 因为它谁都不等——所有请求立刻拿到旧值，只有一个后台线程去重建。

写法上的差别只有一句：B 把「等」放在请求线程里，C 把「等」放到了后台线程里。

C 逻辑过期的关键三步：
1) 不设 TTL，把过期时间写进 value：{"data": ..., "exp": 1762...}
2) 读到的 exp 已过期 -> 尝试拿 rebuild 锁
3) 拿到锁的线程【另起一个线程】重建，自己立刻返回旧值

13.8雪崩与一致性：脏数据是怎么产生的

雪崩（大批 key 同时失效 / Redis 挂了）的策略很清楚：TTL 加随机抖动、 多级缓存、限流降级、集群高可用。这些说出来就行，不好实测。

但「缓存和数据库谁先动」这个问题，是可以一行一行跑出来的。三组实验， 唯一的变量是「第二次删除发生在什么时候」：

=== 缓存一致性：先动缓存还是先动库 ===
--- 1. 先 DEL 缓存，再 UPDATE 库 ---
  写完并回写后           库=v2  缓存=v1  脏
--- 2. 先 UPDATE 库，再 DEL 缓存 ---
  写完并回写后           库=v2  缓存=v1  脏
--- 3. 延迟双删：DEL -> UPDATE -> 睡 300ms -> 再 DEL ---
  回写之后             库=v2  缓存=v1  脏
  第二次删之后           库=v2  缓存=None  干净

三个场景的时间线是这样的（读请求查库要 200ms，写请求 30ms 后就动手）：

t=0     读请求：GET 未命中 -> 发 SQL，拿到快照 v1（还在路上）
t=30    写请求：改库 -> v2，然后删缓存（此时缓存本来就是空的）
t=200   读请求：把手里那张 200ms 前的快照 v1 写进缓存
        -> 缓存 v1，库 v2，脏

场景 2 是重点：很多人以为「先更新库、再删缓存」就万无一失， 但上面这条时间线里，删除发生在回写之前，照样脏。这不是理论推演， 是把 sleep 的位置摆好之后必然复现的。

场景 3 的解决办法是再删一次，且这次要晚于读请求的回写：

t=200   读请求回写完（缓存 v1）
t=330   第二次 DEL -> 把 v1 擦掉
        -> 下次读重新查库，拿到 v2，干净

13.9分布式锁的四个坑

上面击穿那一节的互斥锁，其实就是一把分布式锁。它的四个坑，一次跑完：

=== 分布式锁 ===
1) SET NX PX 的原子性
   A: SET lock uuidA NX PX 3000 -> True
   B: SET lock uuidB NX PX 3000 -> None
   B 拿不到锁，值仍是 uuidA
2) 不会校验 value 就 DEL，会删掉别人的锁
   A 的锁 TTL = 2974 ms，等它自己过期...
   B 此时 SET NX 抢到锁 -> True value = uuidB
   A 的业务跑完了，直接 DEL lock（不校验）-> 1
   结果 B 的锁被删了，lock 还存在吗？ 0
3) Lua 校验后删除
   A 用 Lua 删（value 不匹配）-> 0 （0 = 没删）
   B 用 Lua 删（value 匹配）  -> 1 （1 = 删掉了）
4) 锁过期但业务没跑完 -> 两个客户端同时持锁
   A 拿到锁（500ms 过期），业务要跑 1200ms
   600ms 时 B 尝试加锁 -> True
   A 还在跑，但锁已经是 B 的了

四个坑对应四行代码：

第 3 条的正确写法（实测有效）：

if redis.call('get', KEYS[1]) == ARGV[1] then
  return redis.call('del', KEYS[1])
else
  return 0
end

13.10持久化：RDB 与 AOF 的真实代价

RDB 是快照，AOF 是日志——这句谁都会说。真正有信息量的是代价：

=== 持久化 ===
启动参数: --save "" --appendonly no（两者都关，纯内存）
写入 200000 个 key（约 22.9 MB）
BGSAVE 完成：493 ms，dump.rdb = 4.09 MB，status=ok
运行时 CONFIG SET appendonly yes -> aof_enabled=1
  appendfsync=always    3000 次 SET 耗时   1972 ms  (1521 次/秒)
  appendfsync=everysec  3000 次 SET 耗时    418 ms  (7172 次/秒)
  appendfsync=no        3000 次 SET 耗时    443 ms  (6777 次/秒)

换 redis-benchmark 压出来（-n 20000 -c 50）更直观：

两个值得记住的数字：

• always 只有基线的 41%：因为每条命令都要等一次磁盘 fsync。
• everysec 和 no 几乎没差别（55096 vs 56818）。 这一点反直觉：no 并不比 everysec 快，因为后者是后台线程每秒刷一次， 不阻塞主线程。所以生产上没必要为了性能选 no—— 白白放弃「最多丢 1 秒」的保证，换不来什么。

RDB 那边：22.9 MB 数据 → 4.09 MB 文件，压缩比 5.6 倍，耗时 493 ms。 但真正危险的时刻不是这 493ms，而是 fork 的那一下：

13.11速记卡与自查

把这一章压成五张卡，面试前扫一遍就行。

动手清单与自查表