1. 这不是一本教科书，而是一份 Redis 实战手记
“深入理解Redis”——看到这六个字，很多人第一反应是：又一本讲数据结构、跳表原理、AOF重写机制的理论书？不。我今天要写的，是过去三年里，在多个高并发系统中把 Redis 从“能用”推到“稳用”“巧用”“反直觉地用”的真实记录。它不讲 Redis 是谁发明的，也不罗列所有命令手册，而是聚焦一个最朴素的问题：当流量突然翻三倍、缓存击穿在凌晨两点发生、主从同步延迟飙到 8 秒、内存碎片率突破 1.8——你手里的那台 Redis，到底在想什么？它还能信吗？
核心关键词就藏在这句话里：Redis 深度使用、内存管理、主从同步稳定性、缓存穿透/击穿/雪崩应对、RDB/AOF混合持久化策略、Redis 内存碎片诊断、客户端连接池误配置陷阱。这些词不是考试大纲，而是我在某电商大促压测现场、某金融风控系统告警群里、某内容平台首页加载超时日志中，亲手打捞出来的血泪标签。
适合谁读？如果你已经会SET key value和GET key，能配好redis.conf里的bind和port，但遇到OOM command not allowed when used memory > 'maxmemory'时仍要 Google 十分钟；如果你的监控面板上used_memory_rss和used_memory差了 2GB 却不知道该查什么；如果你改过maxmemory-policy却发现 LRU 淘汰根本没按预期工作——那么这篇就是为你写的。它不假设你是博士，但默认你愿意打开终端敲几行redis-cli --stat，也愿意看懂INFO memory输出里每一列的真实含义。
这不是“入门到放弃”，而是“用过之后，才真正开始理解”。
2. 为什么必须抛弃“单机玩具思维”：Redis 的真实运行环境拆解
2.1 Redis 不是孤岛，它是整个链路中最敏感的神经末梢
很多团队对 Redis 的认知还停留在“一个快的键值存储”。这种理解在 QPS < 500、key 数量 < 10 万、平均 value < 1KB 的小项目里确实够用。但一旦进入真实业务场景，Redis 就立刻暴露出它作为内存数据库+网络服务+单线程事件循环+多持久化机制复合体的全部复杂性。它的行为，从来不是由redis.conf里某一行配置单独决定的，而是由操作系统内存管理 + TCP 栈行为 + 客户端驱动实现 + 业务访问模式四者动态博弈的结果。
举个最典型的例子：我们曾在线上遇到一个现象——Redis 进程 RSS 内存（物理内存占用）持续上涨，但used_memory（Redis 自己统计的逻辑内存）却很平稳，差值长期维持在 1.2GB 左右。运维同学第一反应是“内存泄漏”，紧急回滚版本、升级补丁，折腾两天无果。最后用pstack抓进程栈，再结合cat /proc/<pid>/smaps | grep -A 10 "heap"，才发现是客户端 SDK 在连接池满后，反复创建新连接但未及时释放 socket 缓冲区，导致内核为每个连接分配了 64KB 的sk_buff堆空间，而 Redis 服务端本身对此毫无感知。Redis 的used_memory统计只覆盖自己 malloc 的内存，不包括内核为网络连接分配的缓冲区、mmap 映射的 RDB 文件页、甚至某些模块（如 Redis Modules）的私有堆——这些全算在used_memory_rss里。忽略这个基本事实，所有内存分析都是空中楼阁。
2.2 配置文件只是起点，真正的“配置”藏在 Linux 内核参数里
redis.conf里最常被修改的几项：maxmemory、maxmemory-policy、timeout、tcp-keepalive。但它们的有效性，极度依赖底层 OS 的配合。比如：
maxmemory 2g设定的是 Redis 自身可用的最大逻辑内存。但如果 Linux 的vm.overcommit_memory = 0（默认值），当 Redis 尝试malloc一块大内存用于 AOF rewrite 或 BGSAVE 时，内核可能因无法保证后续物理页分配而直接拒绝，导致 fork 失败、BGSAVE 中断、AOF 重写卡死。此时 Redis 日志只会报Can't save in background: fork: Cannot allocate memory，而free -h看内存明明还有 3G 空闲——这是典型的 overcommit 策略不匹配。tcp-keepalive 300要求 Redis 主动发送 TCP keepalive 探针。但这需要内核的net.ipv4.tcp_keepalive_time（默认 7200 秒）与之协同。如果内核值远大于 Redis 设置，探针根本不会发出；反之，若内核值过小，而中间网络设备（如云厂商 SLB）对 keepalive 包处理异常，反而会引发大量假连接断开。我们实测过，在某公有云环境下，将net.ipv4.tcp_keepalive_time从默认 7200 改为 600，并配合 Redis 的tcp-keepalive 300，可将空闲连接异常断开率从 12% 降至 0.3%。timeout 0（禁用超时）看似安全，但在长连接池场景下，若客户端因网络抖动或 GC 停顿未能及时发心跳，Redis 会一直保留该连接，最终耗尽maxclients。更稳妥的做法是：timeout 300（5 分钟），同时客户端 SDK 启用pingBeforeActivateConnection（连接复用前先 ping），形成双向保活。
提示：生产环境部署 Redis 前，必须固化以下内核参数（写入
/etc/sysctl.conf并sysctl -p）：vm.overcommit_memory = 1 net.core.somaxconn = 65535 net.core.netdev_max_backlog = 5000 net.ipv4.tcp_max_syn_backlog = 65535 net.ipv4.tcp_fin_timeout = 30 net.ipv4.tcp_tw_reuse = 1 fs.file-max = 1000000
2.3 单线程 ≠ 简单，它的“忙”和“闲”有严格定义
Redis 6.0 引入了多线程 I/O（io-threads），但核心命令执行、Lua 脚本、事务、持久化等仍是单线程。这个“单线程”模型的威力与脆弱性并存。关键在于理解它“忙”的时候在忙什么，“闲”的时候又在等什么。
“忙”的本质是事件循环（event loop）在处理：
- 网络 I/O 事件（accept 新连接、read 客户端请求、write 响应）
- 时间事件（定时任务：过期 key 清理、serverCron 每 100ms 执行的统计、AOF fsync）
- 文件事件（RDB save 完成、AOF rewrite 完成的子进程通知）
“闲”的本质是
epoll_wait（Linux）或kqueue（macOS）在等待事件就绪。此时 CPU 占用为 0，但 Redis 并非“挂起”，它随时准备响应下一个事件。
问题来了：如果某个 Lua 脚本执行了 500ms，会发生什么？整个事件循环被阻塞，所有新请求排队，latency监控飙升，INFO stats中的total_commands_processed增速变缓，instantaneous_ops_per_sec归零。此时redis-cli --latency测出的延迟不是网络延迟，而是脚本执行时间。我们曾定位到一个“获取用户勋章列表并按等级排序”的 Lua 脚本，因未限制返回数量，当用户拥有 2000+ 勋章时，table.sort耗时达 800ms。解决方案不是优化算法，而是在 Lua 脚本开头强制加redis.call('exists', KEYS[1])检查 key 存在性，并用#ARGV > 1000 and redis.error_reply('too many args')做参数校验——把错误拦截在执行前。
3. 内存：从used_memory到mem_allocator_stats的逐层穿透
3.1INFO memory八大关键字段实战解读
redis-cli INFO memory的输出有 20+ 行，但真正需要每天盯的，只有以下 8 项。其他字段要么是历史遗留（如mem_fragmentation_ratio的旧算法），要么是调试专用（如mem_clients_normal）。我们按重要性排序：
| 字段 | 含义 | 健康阈值 | 异常征兆 | 诊断命令 |
|---|---|---|---|---|
used_memory | Redis 自己 malloc 的总字节数（逻辑内存） | <maxmemory* 0.9 | 接近maxmemory触发淘汰，或持续增长无下降 | MEMORY USAGE key查单 key |
used_memory_rss | 进程实际占用的物理内存（RSS） | used_memory_rss / used_memory < 1.5 | > 1.8 说明存在严重内存碎片或外部内存占用 | cat /proc/<pid>/smaps | grep -i "heap|mmapped" |
mem_fragmentation_ratio | used_memory_rss / used_memory | 1.0 ~ 1.5 | > 1.8 且used_memory稳定 → 内存碎片；> 1.8 且used_memory上涨 → 外部内存占用 | INFO memory直接看 |
mem_allocator | 内存分配器（jemalloc/ libc/mimalloc） | jemalloc 5.2.1+ | libc分配器在大内存场景下碎片率极高 | redis-cli INFO memory | grep mem_allocator |
loading | 是否正在加载 RDB/AOF | 0 | 1 → 持久化文件加载中，期间只读 | INFO persistence |
rdb_changes_since_last_save | 自上次 SAVE/BGSAVE 后的变更数 | 0（SAVE 后）或稳定增长 | 突然归零 → 可能被外部SAVE命令中断 | INFO persistence |
aof_enabled | AOF 是否开启 | 1（生产必备） | 0 → 持久化仅靠 RDB，宕机丢失数据风险高 | CONFIG GET appendonly |
aof_rewrite_in_progress | 是否正在进行 AOF 重写 | 0 | 1 → 子进程在运行，注意fork开销 | INFO persistence |
重点说mem_fragmentation_ratio。很多人看到 1.8 就慌，立刻redis-cli CONFIG SET maxmemory-policy allkeys-lru试图“清内存”。这是典型误区。碎片率高 ≠ 内存不够，而是内存分配器无法找到连续大块内存来满足 Redis 的 malloc 请求。解决方案分三层：
- 短期止血：
redis-cli CONFIG SET maxmemory-policy volatile-lfu（优先淘汰带过期时间的 LFU key），避免触发 OOM； - 中期修复：重启 Redis（
SHUTDOWN SAVE），让 jemalloc 重新整理内存池； - 长期根治：升级到 Redis 7.0+，启用
activedefrag yes（主动内存碎片整理），并设置active-defrag-threshold-lower 10（碎片率 >10% 开始整理）、active-defrag-cycle-min 25（最低整理强度 25%）。
注意：
activedefrag是 CPU 密集型操作，务必在业务低峰期开启，并监控INFO stats中的active_defrag_running和defrag_hits。我们实测，在 32GB 内存实例上，开启后 CPU 使用率平均增加 8%，但mem_fragmentation_ratio从 2.1 稳定降至 1.2。
3.2MEMORY DOCTOR：Redis 内置的“老中医”诊断术
Redis 4.0+ 内置了MEMORY DOCTOR命令，它不是万能神药，但能快速定位 80% 的常见内存问题。执行redis-cli MEMORY DOCTOR，你会得到类似这样的报告：
Problem: The server is running with a non-zero amount of memory fragmentation. Solution: Restart the server to reduce memory fragmentation. Problem: The server is using more than 80% of its available memory. Solution: Use the 'maxmemory' configuration directive to limit the amount of memory used by Redis. Problem: The server is using more than 100MB of memory for client output buffers. Solution: Check clients that are consuming large amounts of memory, and consider disconnecting them or limiting their output buffer size.这份报告的价值在于：它把INFO memory的原始数字，翻译成了人话 + 可操作动作。但要注意它的局限性——它不分析业务逻辑。比如，它会告诉你 “client output buffers > 100MB”，但不会告诉你哪个客户端在SUBSCRIBE一个每秒发 1000 条消息的频道却消费极慢。这时你需要CLIENT LIST配合CLIENT UNBLOCK <id>。
我们总结了一套MEMORY DOCTOR后的三步排查法：
- 看结论：直接读
Solution行，按优先级执行； - 查根源：对
client output buffers高的问题，执行CLIENT LIST TYPE normal，按omem（output buffer memory）倒序，找出 top3； - 验效果：执行
MEMORY PURGE（Redis 6.2+）强制 jemalloc 归还内存给 OS，再看used_memory_rss是否下降。
3.3MEMORY STATS：比INFO memory更深一层的内存解剖
redis-cli MEMORY STATS输出的是内存分配器（jemalloc）的详细统计，共 20+ 项。对运维最有价值的只有 5 项：
peak_allocated：jemalloc 历史最高分配字节数。如果它远高于当前used_memory，说明曾经有过大对象（如大 list、big hash）被删除，但内存未被完全回收（jemalloc 的 arena 机制）。allocated：当前 jemalloc 分配的总字节数。应 ≈used_memory。若显著大于，说明 Redis 内部有未释放的临时对象（如SORT命令的中间结果）。active：jemalloc 当前活跃的字节数（已分配且正在使用）。active / allocated比值 < 0.7 说明内存利用率低，可能存在大量小对象碎片。metadata：jemalloc 自身元数据开销。正常应 < 50MB。若 > 100MB，说明分配器内部结构过于复杂（如大量小块分配），需考虑--enable-prof编译参数。resident：进程实际驻留物理内存（≈used_memory_rss）。resident / active> 1.5 是内存碎片的铁证。
我们曾用MEMORY STATS定位到一个诡异问题：allocated为 1.2GB，active为 800MB，resident却高达 2.1GB。metadata仅 12MB，排除分配器自身问题。最终通过jemalloc的prof功能（编译时加--enable-prof，运行时设MALLOC_CONF=prof:true,prof_prefix:jeprof.out）抓取 profile，发现是zset的跳表（skiplist）节点在频繁插入/删除时，jemalloc 为每个节点分配了 32 字节，但实际只用了 24 字节，8 字节浪费在对齐上。解决方案是：改用ziplist编码的 zset（zset-max-ziplist-entries 128），或直接用list+SORT替代简单排名场景。
4. 持久化：RDB、AOF、混合模式的取舍与避坑实录
4.1 RDB 的“快照幻觉”与三个致命盲区
RDB（Redis DataBase）是二进制快照，优势是恢复快、文件紧凑、适合备份。但它的“快”是建立在几个关键假设上的，一旦假设不成立，RDB 就会成为故障放大器。
盲区一：save命令的阻塞式陷阱SAVE是同步命令，会阻塞整个 Redis 事件循环，直到快照完成。在 10GB 数据集上，SAVE可能阻塞 3~5 秒。此时所有请求排队，latency监控爆红。绝对禁止在生产环境手动执行SAVE。正确姿势是：BGSAVE（后台 fork 子进程），或依赖save配置项（如save 900 1）自动触发。
盲区二：bgsave的 fork 开销被严重低估BGSAVE依赖fork()系统调用。fork的开销与 Redis 进程的虚拟内存大小（VMS）正相关，而非物理内存（RSS）。在copy-on-write机制下，子进程初始共享父进程所有内存页，但一旦父进程修改某页，内核需复制该页。因此，BGSAVE期间，若父进程写入频繁（如每秒 10w+ set），fork后的写操作会触发大量页复制，导致used_memory_rss瞬间翻倍，甚至 OOM。我们实测：32GB VMS 的 Redis，fork本身耗时 120ms，但随后 1 秒内used_memory_rss从 28GB 涨到 52GB。
解决方案只有两个：
- 降低
save触发频率：save 300 10000（5 分钟内 1w 次变更才触发），牺牲一点数据安全性换稳定性； - 启用
copy-on-write优化：Linux 4.0+ 内核支持CONFIG_MEMCG_KMEM，配合echo 1 > /proc/sys/vm/overcommit_memory，可显著减少 fork 后的页复制。
盲区三：RDB 文件的“时间戳错觉”dump.rdb文件的 mtime（修改时间）是BGSAVE完成的时间，但INFO persistence中的rdb_last_save_time才是 Redis 记录的准确时间。两者可能相差数秒（因文件系统 sync 延迟）。监控脚本若只检查文件 mtime，会误判 RDB 生成失败。所有 RDB 监控必须读取INFO persistence的rdb_last_bgsave_status（应为ok）和rdb_last_save_time。
4.2 AOF 的“实时幻觉”与 fsync 的三重地狱
AOF（Append Only File）通过记录每条写命令来实现持久化，号称“最多丢一秒数据”。但这个“一秒”，取决于appendfsync配置，而它背后是磁盘 I/O、内核缓冲区、文件系统日志的三重博弈。
appendfsync always：每条命令后fsync()。数据最安全，但性能最差（QPS 下降 50%+），且 SSD 寿命加速消耗。仅适用于金融级强一致性场景，且必须搭配no-appendfsync-on-rewrite yes（AOF 重写时不做 fsync），否则重写期间性能雪崩。appendfsync everysec（默认）：每秒一次fsync()。平衡点，但存在“最后一秒”丢失风险。更隐蔽的风险是：当内核缓冲区（page cache）满时，fsync()会阻塞，导致 Redis 主线程卡住。我们曾在线上观察到，everysec模式下，INFO stats的aof_delayed_fsync计数器每小时增长 200+，意味着每秒fsync()有 200 次被延迟执行。原因就是vm.dirty_ratio = 20（默认），当脏页占内存 20% 时，内核强制刷盘，与 Redis 的fsync()竞争 I/O。appendfsync no：由内核决定何时刷盘。性能最好，但宕机可能丢失数分钟数据。绝对禁止在生产环境使用。
我们的生产标准配置是：
appendonly yes appendfsync everysec no-appendfsync-on-rewrite yes auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb aof-load-truncated yes aof-use-rdb-preamble yes # Redis 7.0+ 启用混合格式其中aof-use-rdb-preamble yes是关键。它让 AOF 文件在重写后，前半部分是 RDB 格式（紧凑、加载快），后半部分是 AOF 命令（增量）。这样redis-server启动时，先用 RDB 快速加载基础数据，再用 AOF 补充最新变更，启动时间从 120 秒降至 25 秒（10GB 数据集）。
4.3 混合持久化（RDB-AOF）：不是简单叠加，而是精密编排
Redis 4.0 引入混合持久化，但很多人以为“开了就行”。实际上，它是一套需要精细调优的机制。
混合模式下，AOF 重写（BGREWRITEAOF）不再生成纯文本 AOF，而是生成一个以 RDB 格式开头、后接 AOF 命令的文件。其优势不仅是启动快，更在于RDB 部分天然规避了 AOF 的命令重放开销和潜在语法错误。
但陷阱在于aof-rewrite-incremental-fsync（默认 on）。此选项让 AOF 重写子进程在写入文件时，每 32MB 就执行一次fsync()。这本意是防止重写过程崩溃导致 AOF 文件损坏，但副作用是：重写期间，子进程的 I/O 与主线程的appendfsync竞争磁盘带宽，导致主线程fsync()延迟飙升。我们关闭它（CONFIG SET aof-rewrite-incremental-fsync no）后，aof_delayed_fsync计数器归零，INFO stats的aof_delayed_fsync从每小时 200+ 降至 0。
另一个关键是aof-load-truncated（默认 yes）。它允许 Redis 在加载被截断（truncated）的 AOF 文件时，自动忽略末尾损坏部分，继续加载前面有效内容。这在磁盘满、fsync失败等场景下，能避免整个 Redis 启动失败。但我们在线上发现，当aof-load-truncated yes且 AOF 文件末尾有非法命令时，Redis 会静默跳过，但INFO stats的aof_last_load_status仍显示ok，掩盖了数据不一致。因此，我们改为aof-load-truncated no，并在监控中增加对aof_last_load_status的告警（非ok时立即告警）。
5. 高可用基石：主从同步的七层真相与故障自愈实践
5.1INFO replication不是状态快照，而是同步流水线的实时仪表盘
redis-cli INFO replication的输出，表面是主从关系，实则是一个由 TCP 连接、缓冲区、偏移量、心跳组成的精密流水线。读懂它，才能预判故障。
关键字段解析：
role:master/role:slave：角色，但注意role:master的实例也可能同时是其他实例的 slave（级联架构）。connected_slaves:2：当前成功连接的 slave 数量。但connected_slaves为 2 不代表健康，需看slave0和slave1的state字段。master_replid/master_repl_offset：主节点的复制 ID 和当前偏移量。这是全局唯一标识，所有 slave 必须基于此同步。slave0:ip=10.0.1.10,port=6379,state=online,offset=123456789,lag=1：state=online仅表示 TCP 连接正常；offset是 slave 当前已同步到的偏移量；lag=1是 slave 上次收到主节点PING心跳后经过的秒数（非网络延迟！）。
最易被误解的是lag。lag=1不代表延迟 1 秒，而是“slave 在 1 秒前收到了主节点的心跳包”。真正的同步延迟，要看master_repl_offset - slaveX_offset。我们曾遇到lag=1但offset差值达 500w 的情况——原因是 slave 的client-output-buffer-limit slave 256mb 64mb 60设置过小，当主节点写入爆发时，slave 的 output buffer 溢出，被主节点强制断开连接，然后重连、全量同步，造成巨大延迟。
5.2 全量同步（PSYNC）的“黑洞时刻”与增量同步（PSYNC2）的救赎
Redis 2.8 引入 PSYNC，解决了旧版SYNC的全量同步风暴问题。但 PSYNC 仍有两大痛点：
PSYNC1 的“复制积压缓冲区”（replication backlog）大小固定：默认
repl-backlog-size 1mb。当主从网络抖动超过backlog容量，slave 无法进行部分重同步（partial resync），只能退化为全量同步（full resync），触发BGSAVE+fork+ 网络传输，CPU 和带宽双爆表。PSYNC1 的复制 ID（replid）在主节点重启后会变更：slave 无法用旧 replid 请求增量，只能全量同步。
Redis 4.0 的 PSYNC2 彻底解决：
replid2：主节点重启后，保留旧replid作为replid2，slave 可用replid2请求旧数据；repl-backlog-size可动态调整：CONFIG SET repl-backlog-size 100mb，确保 99.9% 的网络抖动都能被缓冲。
我们的线上配置：
repl-backlog-size 256mb repl-backlog-ttl 86400 # backlog 24 小时内有效 min-slaves-to-write 1 # 至少 1 个 slave 在线才接受写 min-slaves-max-lag 10 # slave lag > 10 秒则拒绝写（防脑裂）其中min-slaves-to-write和min-slaves-max-lag是防脑裂（split-brain）的关键。当主节点与多数 slave 失联，它会降级为只读，避免数据不一致。我们曾在线上模拟网络分区，主节点在min-slaves-to-write不满足时，INFO replication的role变为master，但INFO stats的rejected_connections开始增长，redis-cli SET test 1返回(error) NOAUTH Authentication required（实际是READONLY You can't write against a read only slave的伪装错误），这就是保护机制在生效。
5.3 从节点只读的“伪命题”与读写分离的终极方案
slave-read-only yes（默认）让从节点拒绝写命令，但这只是应用层防护。从节点的slave-read-only设置，无法阻止客户端通过redis-cli -h slave_ip -p 6379直连并执行CONFIG SET slave-read-only no。更危险的是，某些旧版客户端 SDK 会自动将SLAVEOF NO ONE命令发往从节点，将其提升为新主节点，导致集群分裂。
真正的读写分离，必须在客户端或代理层实现。我们采用Twemproxy（nutcracker）+ 自定义路由规则方案：
- Twemproxy 配置两个集群：
master_pool（只含主节点）和slave_pool（含所有从节点）； - 业务代码中，读请求走
slave_pool，写请求走master_pool； - Twemproxy 的
hash_tag: "{}"确保同一 key 总路由到同一后端，避免跨节点读取不一致。
此方案的优势是：读写分离逻辑与 Redis 无关，即使 Redis 版本升级、配置变更，只要 Twemproxy 配置不变，业务无感。我们实测，在 16 节点集群中，读请求 QPS 从单节点 8w 提升至集群 120w，写请求保持 8w 不变，slave节点的used_cpu_sys从 35% 降至 12%。
6. 缓存失效三剑客：穿透、击穿、雪崩的防御工事实录
6.1 缓存穿透：不是“击穿”，是“凿穿”——空值围栏与布隆过滤器的实战权衡
缓存穿透指查询一个数据库和缓存都不存在的 key（如恶意构造的-1、999999999），导致大量请求打到 DB。它的危害不是 QPS 高，而是无效请求占比高，DB 连接池被占满，拖垮整个服务。
经典方案是“空值缓存”：DB 查无结果，也在 Redis 里SET key "null" EX 60。但问题来了："null"字符串会被业务代码误用，且无法区分“真 null”和“缓存 null”。
我们的方案是双层空值标记：
- 业务层空值：DB 返回
null时，SET key "__NULL__" EX 60（用特殊字符串标记）； - 网关层布隆过滤器：在 API 网关（如 Kong）前置布隆过滤器，对所有
GET /user/{id}请求，先查布隆过滤器。若id不在布隆集中，直接404，不发往下游。
布隆过滤器的 key 是user:id，我们用guava库构建，expectedInsertions=1000w，fpp=0.01（1% 误判率），内存占用仅 12MB。实测线上，恶意请求拦截率 99.2%，DB 的Queries per second中SELECT * FROM user WHERE id = ?类型查询下降 78%。
注意：布隆过滤器的
fpp（false positive probability）不能设为 0，否则内存无限大。1% 误判率意味着 100 个真实存在的id，会有 1 个被误判为不存在，导致404。这对用户影响极小，且可通过前端重试或降级逻辑兜底。
6.2 缓存击穿：热点 key 的“定时炸弹”与互斥锁的三种实现
缓存击穿指一个极热的 key 过期瞬间，大量请求同时发现缓存失效，涌向 DB。它和穿透的区别是：key 是真实存在的，只是“恰好”在同一毫秒过期。
方案一：逻辑过期（Logical Expiration）
不依赖 Redis 的EXPIRE，而是在 value 中嵌入过期时间戳。例如：
{"data": "...", "expire_at": 1717027200000}业务代码读取后，先判断expire_at < System.currentTimeMillis()，若过期，则：
- 尝试
SETNX key_lock "1" EX 30获取锁； - 成功则异步刷新缓存，失败则直接返回旧值（容忍短暂不一致）。
方案二：Redisson 分布式锁
用RLock lock = redisson.getLock("lock:user:123");，lock.tryLock(0, 30, TimeUnit.SECONDS)。优势是自动续期，避免死锁。但引入了 Redisson 依赖，且锁粒度较粗。
方案三：本地缓存 + Redis 双检锁（Double-Check Lock）
在应用 JVM 内存中维护一个ConcurrentHashMap<String, Boolean>，记录哪些 key 正在重建。流程：
- 读 Redis，命中则返回；
- 未命中，查本地 map，若
map.get(key) == true，则Thread.sleep(10)后重试； - 若
map.get(key) == null，则map.put(key, true)，再异步重建缓存，完成后map.remove(key)。
我们最终选择方案一（逻辑过期），因为：
- 无额外依赖，纯 Redis 命令；
- 锁超时（30 秒）可精确控制，避免长任务阻塞；
SETNX命令原子性，无竞态条件。
6.3 缓存雪崩：不是“崩”，是“塌方”——过期时间的混沌工程
缓存雪崩指大量 key 在同一时间段集中过期，导致 DB 瞬时压力激增。它的根源往往是开发时写了EX 3600（1 小时），所有 key 都在
