Redis 学习总纲：零基础到资深专家的完整教学大纲
2026/8/24大约 28 分钟
Redis 系列 · 学习路线 · 总纲第 0 篇
本文是 Redis 领域的完整教学大纲：先定义「学成什么样算资深」，再把整个领域拆成可以逐个吃掉的小单元。本目录原有的 10 篇早期系列（01~10，Redis 7 基准）是本大纲部分单元的现成材料，本大纲以 Redis 8.10（2026 年当前最新稳定版）为基准重新规划全线。
开头：为什么 Redis 特别需要一份大纲？
因为 Redis 是那种「两天就能上手，两年都摸不到底」的中间件：
- 第一天你就学会了
SET/GET，觉得不过如此； - 第一个月你踩了缓存雪崩，回头才发现「过期策略」「淘汰策略」「持久化」是三码事；
- 第一你年读集群文档，发现故障转移依赖主从复制，主从复制依赖 repl_backlog，repl_backlog 又牵出单线程事件循环和 fork/COW——每个机制下面还有机制；
- 好不容易机制懂完了，Redis 8 又把 Search、JSON、Vector Sets 全并进了核心，许可证还从 BSD 改到 RSAL/SSPL 再改回 AGPLv3，同事问你「我们该用 Redis 还是 Valkey」，你答不上来。
没有路线图的学习是这样的：看缓存穿透文章 → 顺带看到布隆过滤器 → 去研究位数组实现 → 又被概率结构绕进 HyperLogLog → 每篇干货文都指向三篇更深的干货文，学了一年还是一堆碎片，串不成一个系统。
这份大纲要做的事就一件：把这张互相咬合的知识网压成一条单向的链——每个单元只依赖前面的单元，学完一个，就扎实一个。这是西蒙学习法在 Redis 领域的落地。
一、学成什么样，才算「资深」？
先立靶子。学完本大纲，你应具备五项能力：
| # | 能力 | 具体表现 |
|---|---|---|
| 1 | 讲得清 | Redis 为什么快、数据什么时候可能丢、集群如何自愈——每个机制都能讲出它的取舍（牺牲了什么换来了什么） |
| 2 | 选得对 | 缓存、锁、计数器、排行榜、消息、向量检索——给定业务场景能选对数据结构与架构形态，并说出落选方案差在哪 |
| 3 | 写得出 | 用 Java + Redis 写出生产级代码：缓存装配、分布式锁、秒杀扣库存、延迟队列、相似搜索 |
| 4 | 读得懂 | Redis 源码能追到「文件/函数级」调用链：一条 SET 从网络字节到落盘的完整路径知道断点打在哪 |
| 5 | 修得了 | 大 key 卡顿、热 key 打爆分片、主从频繁全量同步、缓存雪崩——线上故障能定位、能修复、能预防 |
注意「资深」的定义里没有「背会所有命令」——命令有 300+，查文档就行；判断力才是资深的分水岭。
二、西蒙学习法在本领域的四个落法
西蒙学习法的核心：把领域拆碎成小单元，连续地、单点聚焦地逐个吃掉，每个单元立刻获得反馈。对应到本大纲：
- 拆碎：下面每个知识单元控制在 0.5 ~ 2 天内可完成。绝不出现「学集群」这种大块头，只有「亲手触发一次槽迁移并观察 ASK 重定向」这种小块。
- 单点聚焦：一次只学一个单元。学淘汰策略的时候不要顺手去翻 fork 原理——忍住，它排在下一个阶段。
- 及时反馈：每个单元都配动手实验和吃透的标准。实验跑不通 = 没学会，不进下一单元。
- 连续推进：每天 1.5 ~ 2 小时，每周 5 ~ 6 天，连续推进约 16 周。中断两周以上，从当前阶段的第一个单元重头来。
学习环境清单（开工前一次备齐）
| 工具 | 版本建议 | 用途 |
|---|---|---|
| Redis | 8.10.x（2026-08 当前最新稳定版 8.10.1，GitHub Releases 核验） | 全程主体；镜像 redis:8.10 |
| WSL2 + Docker | Ubuntu 发行版 | 单机、主从、哨兵、Cluster 全部实验环境 |
| JDK + Spring Boot | 17 + 3.x | 客户端接入与综合实战 |
| Jedis / Lettuce / Redisson | 最新稳定版（均已支持 Redis 8 与 RESP3） | 阶段 5 客户端三巨头对比 |
| Redis Insight | 最新版 | GUI 观察数据与慢查询 |
| redis-benchmark | Redis 自带 | 各阶段性能实验 |
版本说明：Redis 自 8.0（2025-05）起改为 AGPLv3 / RSALv2 / SSPLv1 三许可（重新回归开源），并把原 Redis Stack 的 Search、JSON、TimeSeries、Bloom 等模块并入核心；此后进入半年一版的节奏（8.2 → 8.4 → 8.6 → 8.8 → 8.10）。本系列以 8.10 为基准；网上大量资料基于 6.x/7.x，遇到结论冲突时以官方最新文档为准。
三、知识全景图
九个阶段 + 一个毕业设计，总周期约 16 周：
| 阶段 | 主题 | 回答的核心问题 | 周期 |
|---|---|---|---|
| 0 | 地基：把 Redis 用起来 | 它到底比 MySQL 快在哪？五种基础类型各解决什么问题？ | 1.5 周 |
| 1 | 单机内核：为什么快 | 单线程怎么做到十万 QPS？内存里的数据结构长什么样？ | 2.5 周 |
| 2 | 持久化：怎么不丢 | RDB、AOF、混合持久化各自的代价窗口在哪？ | 1 周 |
| 3 | 高可用：主从与哨兵 | 数据怎么复制？主挂了谁说了算？ | 1.5 周 |
| 4 | 水平扩展：Cluster | 一台装不下怎么分？分了之后请求怎么路由？ | 2 周 |
| 5 | 工程化：客户端与原子性 | Java 怎么用好它？锁、事务、脚本、消息怎么选？ | 2 周 |
| 6 | 缓存工程：生产一线 | 穿透、击穿、雪崩、一致性——缓存用错的四种经典死法 | 1.5 周 |
| 7 | 现代 Redis：8.x 新世界 | JSON、Search、Vector Sets、许可证——它变成了什么？ | 1.5 周 |
| 8 | 性能与运维 | 慢在哪、看什么指标、怎么备份与扩容 | 1 周 |
| 9 | 毕业：综合实战 | 一个系统把所有知识串起来 | 1 周 |
顺序设计的三个关键决定，先说透，免得学到一半怀疑路线：
- 内核原理（阶段 1）排在持久化和高可用之前：因为 RDB 的 fork/COW、复制的 repl_backlog、Cluster 的故障转移，全都长在「单线程事件循环 + 内存数据结构」这块地基上。先懂地基，后面每个机制只需要学「新增的部分」。
- Cluster（阶段 4）排在哨兵（阶段 3）之后：Cluster 的故障转移就是「内嵌在节点里的哨兵 + 主从复制」，不懂阶段 3 就读不懂阶段 4 的选举日志。
- 缓存工程（阶段 6）排在所有机制之后：穿透/击穿/雪崩/一致性是「业务用法 × 底层机制」的交叉问题——不懂淘汰策略解释不了雪崩，不懂复制解释不了延迟双删。两边都得先会，这里才能一次讲透。
四、阶段 0：地基——先把 Redis 用起来（第 1 周 ~ 第 2 周前半）
为什么有这个阶段：Redis 的本质是「内存里的数据结构服务器」，不是「更快的 MySQL」。先建立这个认知，后面每个特性才知道它为什么存在。同时把环境搭好，后续所有阶段都在这套环境上叠加。
| 单元 | 回答的核心问题 | 动手实验 | 吃透的标准 |
|---|---|---|---|
| 0.1 为什么会有 Redis | MySQL 查询慢在磁盘和 B+ 树的哪一步？把数据放内存为什么就快了？ | 写一个 Spring Boot + MySQL 的「商品详情」接口，用 JMeter 压出 QPS 基线，再对比纯内存 Map 版本 | 能说清「Redis 是数据结构服务器，MySQL 是磁盘表格引擎」，而不是「Redis = 快的 MySQL」 |
| 0.2 安装与 CLI 基本功 | redis-server 怎么跑？redis-cli 有哪些生存技能？ | WSL Docker 启动 redis:8.10；redis-cli 完成 ping/set/get/DBSIZE/INFO server，学会 HELP @string 查命令 | 不查资料完成：连接、切换 db、查命令用法、看版本 |
| 0.3 String 与 Hash | 缓存一个对象，整体存还是按字段存？ | 用 SET(JSON 字符串) 和 HSET(逐字段) 两种方式缓存同一商品，对比改一个字段的操作 | 说清 String 简单高效 vs Hash 字段级读写的取舍 |
| 0.4 List / Set / ZSet | 最新列表、去重、排序各用什么？ | 用 ZSet 实现阅读量排行榜（ZINCRBY + ZREVRANGE） | 给「点赞数、粉丝集合、最新动态流」三个场景选型并说理由 |
| 0.5 过期与 key 管理 | TTL 怎么设置怎么生效？key 一多怎么安全地找？ | EXPIRE/PERSIST/TTL 全套实验；对比 KEYS * 与 SCAN 在百万 key 下的表现 | 说清过期删除「惰性 + 定期」两种策略的现象；解释为什么生产禁用 KEYS |
| 0.6 Java 接入 | Spring Boot 怎么连 Redis？ | spring-data-redis（Lettuce 底座）实现「查缓存 → 未命中查库 → 回填」接口 | 接口跑通，且能用 redis-cli 看到回填的 key 与 TTL |
阶段验收：不查文档，独立写出一个「带随机过期时间的用户信息缓存」接口，并口述每个 key 选了什么类型、为什么。
五、阶段 1：单机内核——Redis 为什么快（第 2 周后半 ~ 第 4 周）
重点攻坚阶段。为什么它值得 2.5 周：后续所有阶段（持久化、复制、集群、缓存问题）的解释都停在这一层。
| 单元 | 回答的核心问题 | 动手实验 | 吃透的标准 |
|---|---|---|---|
| 1.1 单线程与事件循环 | 命令执行为什么是单线程？IO 多路复用（epoll）怎么让单线程不闲着？ | 灌入百万 key 后执行 KEYS *，同时另一个连接测 GET 延迟，观察「一条慢命令阻塞一切」 | 能解释「单线程指命令执行；快靠纯内存 + 非阻塞 IO + 无锁」，并说出单线程的代价 |
| 1.2 RESP 协议 | 客户端和服务端之间说的什么话？RESP2 与 RESP3 差在哪？ | 用 nc/telnet 手写 RESP 报文完成一次 SET/GET | 能手写一条 *3\r\n$3\r\nSET... 格式的命令并读懂回复 |
| 1.3 SDS | Redis 为什么不用 C 的 char*？ | 查 SDS 源码结构体（sds.h），对比 strlen O(1)、二进制安全、空间预分配 | 说出 C 字符串的三个缺陷及 SDS 的对应解法 |
| 1.4 dict 与渐进式 rehash | Redis 的 hash 表扩容为什么不卡顿？两张某时刻的表怎么共存？ | DEBUG HTSTATS（或 OBJECT ENCODING）观察扩容前后状态 | 能画出渐进 rehash 期间「读、写、定时迁移」各走哪张表 |
| 1.5 listpack / quicklist / skiplist | List、ZSet 底层到底长什么样？ziplist 为什么被 listpack 取代？ | 对 List、ZSet 分别 OBJECT ENCODING，改变元素数量观察编码切换 | 说清「小数据用连续内存（省内存），大数据用链式/跳表（省时间）」的统一设计哲学 |
| 1.6 对象系统与编码阈值 | redisObject 怎么串起类型与底层结构？阈值在哪配？ | 修改 hash-max-listpack-entries 等参数，观察编码切换点 | 拿到任何 key 能查出类型、编码、refcount，并解释为什么是这个编码 |
| 1.7 内存淘汰策略 | 内存满了怎么办？8 种策略各适合什么场景？ | 配置 maxmemory 64mb，灌数据到满，对比 allkeys-lru / volatile-lru / allkeys-lfu 的淘汰结果 | 能为「纯缓存实例」和「既缓存又存数据实例」选出正确策略并解释 lfu 的实现（ Morris 计数） |
| 1.8 IO threads | 8.x 的多线程用在哪了？为什么命令执行还是单线程？ | 开关 io-threads 前后用 redis-benchmark 对比大 value 场景吞吐 | 说清「多线程只做网络读写与协议解析，命令执行仍是单线程」的设计原因 |
阶段验收：脱稿画出一条 SET name tom 从客户端发出到写入 dict 的完整路径（RESP 解析 → 命令表查找 → 单线程执行 → SDS/dict 写入 → 回复），并回答：这一步做完，数据丢了吗？（引出阶段 2）
六、阶段 2：持久化——内存数据怎么不丢（第 5 周）
为什么有这个阶段：阶段 1 验收题的答案必然引出「还没落盘，会丢」。持久化就是回答「用多重的性能代价，换多小的丢失窗口」。
| 单元 | 回答的核心问题 | 动手实验 | 吃透的标准 |
|---|---|---|---|
| 2.1 RDB 快照 | bgsave 的 fork + 写时复制（COW）怎么在不停服务下拍快照？ | bgsave 期间高并发写入，观察 INFO stats 的 latest_fork_usec 与子进程内存增长 | 能解释「fork 为什么可能卡主进程」「COW 为什么极端写场景内存翻倍」 |
| 2.2 AOF 日志 | 写后日志为什么比写前日志快？三种 fsync 策略的丢失窗口各多大？ | 分别配 always / everysec / no，写入后 kill -9 重启，统计各丢失多少条 | 说清「everysec 是默认值」背后性能与安全的平衡点 |
| 2.3 AOF 重写 | 日志越写越大怎么办？bgrewriteaof 期间新写入会不会丢？ | 持续写入时触发 BGREWRITEAOF，观察重写期间 aof_rewrite_buf 的作用 | 能画出「主进程写 aof_buf + 子进程写新 AOF + 重写缓冲补差」三线并行图 |
| 2.4 混合持久化 | aof-use-rdb-preamble（默认 yes）混合了什么？ | 对比纯 AOF 与混合模式重启恢复同一数据集的耗时与文件大小 | 说清「全量用 RDB 格式 + 增量用 AOF 格式」为什么兼得两者优点 |
| 2.5 恢复与选型 | RDB 和 AOF 同时存在时听谁的？生产怎么配？ | 综合实验：模拟断电（不同 fsync 配置）→ 重启 → 对账丢失窗口，写成一张结论表 | 给「纯缓存」「缓存+计数」「轻量存储」三种实例各给出一套持久化配置建议 |
阶段验收：一张「写入 → fsync → fork → 重启」全场景推演表，任何「数据丢了 N 秒」的线上工单都能对号入座定位配置问题。
七、阶段 3：高可用——主从复制与哨兵（第 6 周 ~ 第 7 周前半）
为什么有这个阶段：单机有两死穴——机器挂了服务就断、内存上限就是上限。复制解决前者（多副本），哨兵解决「挂了以后谁顶上」。
| 单元 | 回答的核心问题 | 动手实验 | 吃透的标准 |
|---|---|---|---|
| 3.1 全量复制 | 首次同步的 PSYNC 全量流程长什么样？ | Docker 起 1 主 2 从，抓 INFO replication 观察主从握手与 RDB 传输 | 能复述「建立连接 → PSYNC -1 → 全量 RDB → 命令传播」四步 |
| 3.2 增量复制 | 断线重连为什么不用再全量？replid 与 offset 怎么配合？ | 从节点断网写入超过 repl-backlog-size 再重连，观察退化为全量；调小 backlog 复现 | 说清「offset 还在 backlog 里 → 部分重同步；被覆盖 → 全量」，以及 backlog 该配多大 |
| 3.3 读写分离的风险 | 读从库为什么可能读到旧数据？主从库什么时候会不一致？ | 写主读从，立刻读观察延迟；讨论「先写后读」业务该怎么路由 | 能给出「写后立即读」场景的三种解法（读主、等待、客户端记录版本） |
| 3.4 哨兵的四个任务 | 监控、通知、选主、配置分发怎么环环相扣？quorum 和 majority 各管什么？ | 起 3 哨兵 + 1 主 2 从，读 sentinel 日志理解 sdown → odown 的判定升级 | 说清「quorum 判客观下线，majority 选出执行者」两道闸门的作用 |
| 3.5 故障转移实操 | 主挂了之后的完整时间线？新主怎么选（优先级/offset/runid）？ | redis-cli shutdown 杀主，逐秒记录：sdown → odown → 选举 → 切换 → 客户端恢复 | 能画出时间线并标注每一步发生在哨兵还是节点上 |
| 3.6 脑裂与防护 | 旧主被隔离后还在接收写入，重连时这些写入怎么办？ | 用 iptables 隔离主节点模拟网络分区，观察旧主写入在重连后丢失 | 说清 min-replicas-to-write / min-replicas-max-lag 如何用「写门槛」兜底 |
阶段验收：画出「一次完整故障转移」的时序图（含客户端视角），并回答：哨兵架构下，哪个时间窗口内的写入注定丢失？
八、阶段 4：水平扩展——Cluster（第 7 周后半 ~ 第 9 周）
为什么有这个阶段：哨兵解决了「高可用」但没解决「容量」——写能力和内存仍被单机锁死。Cluster 用分片同时解决两个问题，代价是使用限制。
| 单元 | 回答的核心问题 | 动手实验 | 吃透的标准 |
|---|---|---|---|
| 4.1 为什么要分片 | 单机的三堵墙（内存/写 QPS/网卡）各撞在哪？客户端分片、代理、原生 Cluster 三种方案怎么选？ | 对比三种方案的架构图与故障域 | 能说清每种方案「谁负责路由、谁负责高可用」 |
| 4.2 槽与路由 | 为什么是 16384 个槽？CRC16 % 16384 怎么算？hash tag {} 什么时候用？ | CLUSTER KEYSLOT 验证 key 归属；用 {user1000}.follow 把相关 key 控制到同槽 | 说清槽是「数据与节点之间的间接层」，以及它给扩缩容带来的好处 |
| 4.3 MOVED 与 ASK | 客户端收到两种重定向各意味着什么？smart client 优在哪？ | 普通客户端打到错误节点看 MOVED；redis-cli -c 自动跟随 | 说清 MOVED（槽已迁走，更新槽表）与 ASK（迁移中，只是这一次去问）的区别 |
| 4.4 Gossip 与总线 | 节点间怎么互相探活？cluster bus 的 +10000 端口传什么？ | CLUSTER NODES 观察节点表收敛；tcpdump/bus 抓 PING/PONG（选做） | 能说清 Gossip「最终收敛、去中心化」与它带来的判定延迟 |
| 4.5 故障检测与转移 | pfail 怎么升级成 fail？从节点选举为什么需要多数派？ | 杀掉一个主节点，逐秒记录半数 pfail → fail → 选举 → 槽接管的时间线 | 能对比「Cluster 内置故障转移」与阶段 3 哨兵流程的异同 |
| 4.6 扩缩容实操 | 加节点后数据怎么搬家？迁移中间状态谁来兜底？ | 用 redis-cli --cluster resard 把槽迁给新节点，迁移期间持续读写观察 ASK | 能列出 reshard 的大致步骤（目标授权 → 逐 key 迁移 → 槽指派更新） |
| 4.7 Cluster 的限制 | 为什么 mset 跨槽会报错？事务/Lua/多键操作怎么受影响？ | 复现 CROSSSLOT 错误；用 hash tag 解决后再讨论副作用 | 能给出「多键操作在 Cluster 下的三条出路」 |
| 4.8 架构选型 | 哨兵 + 主从 vs Cluster，各自的天花板与复杂度？ | — | 一张决策表：数据量、写 QPS、多键需求、运维能力四个维度 |
阶段验收：6 节点 Cluster（3 主 3 从）从零搭起，完成一次 reshard 与一次主节点故障切换，全程时间线留档。
九、阶段 5：工程化——客户端、原子性与锁（第 10 ~ 11 周）
为什么有这个阶段：前面都在懂服务端；生产代码的效率和正确性一半取决于客户端怎么用。这一阶段把「会操作」升级成「会工程化使用」。
| 单元 | 回答的核心问题 | 动手实验 | 吃透的标准 |
|---|---|---|---|
| 5.1 客户端三巨头 | Jedis、Lettuce、Redisson 各自的连接模型与定位？ | 同一接口分别用三者实现，观察线程安全性与连接数差异 | 说清 Jedis 阻塞直连 / Lettuce Netty 单连接共享 / Redisson 分布式对象的三种定位 |
| 5.2 Pipeline | 逐条往返 vs 打包发送差多远？ | 1 万条写入：逐条 vs pipeline 分批，对比耗时 | 能用 RTT 解释差距量级，并说出 pipeline 与事务的区别 |
| 5.3 Lua 脚本 | 「判断 + 修改」怎么不被别的客户端插队？EVAL 的原子性从哪来？ | 用 Lua 写「库存预扣：>=1 才扣」，并发 100 线程验证不超卖 | 说清脚本原子性 = 单线程执行期间不插入其他命令；知道脚本的坑（集群下 key 必须同槽） |
| 5.4 MULTI/EXEC 弱事务 | Redis 事务为什么不回滚？入队错误 vs 执行错误各什么表现？ | 复现「入队时报错整体失败」与「执行时报错仅该条失败」两种现象 | 说清它和数据库事务的本质区别，及 WATCH 乐观锁怎么用 |
| 5.5 Function（7.0+） | 函数比 Lua 脚本好在哪？FUNCTION LOAD 怎么管理？ | 把 5.3 的 Lua 改写成 Function 注册复用 | 说清「服务端持久化、可版本管理的脚本库」解决了 EVAL 的哪些痛点 |
| 5.6 分布式锁 | SET NX EX 有什么坑？看门狗解决什么？Redlock 为什么有争议？ | 手写锁 → 复现「业务超时锁自动释放被误删」→ 换 Redisson 看门狗；读 Kleppmann 与 antirez 的论战原文 | 能独立说清 Redlock 争议双方论点（时钟假设 vs 网络延迟），并给出务实结论 |
| 5.7 Pub/Sub 与 Stream | 广播为什么可能丢消息？Stream 消费组怎么保证至少一次？ | Pub/Sub 断订验证丢失；Stream 消费组 XACK/XPENDING/XAUTOCLAIM 全流程 | 说清「fire-and-forget vs 可持久化消费组」的分野，及 Stream 延迟队列玩法 |
| 5.8 Spring Cache 装配 | 注解缓存的注解语义和 TTL 策略怎么定？ | @Cacheable/@CacheEvict 装配商品缓存，自定义 TTL | 能解释注解失效的常见坑（自调用、key 拼写） |
阶段验收：写一个并发安全的「秒杀预扣库存」服务（Lua + Redisson 锁二选一都要写过），压测不超卖、不少卖。
十、阶段 6：缓存工程——生产一线的四种经典死法（第 12 周 ~ 第 13 周前半）
为什么有这个阶段：生产环境 90% 的 Redis 故障不是 Redis 坏了，而是用错了。这四个问题每个都是面试高频，更是真实事故的四大来源。
| 单元 | 回答的核心问题 | 动手实验 | 吃透的标准 |
|---|---|---|---|
| 6.1 缓存穿透 | 查「不存在的数据」为什么打穿到库？布隆过滤器为什么能挡？ | 构造恶意 id 请求压测；分别用空值缓存与布隆过滤器（8.x 内置 BF. 命令）拦截，对比库压力 | 说清布隆「说不存在就一定不存在」的原理与误判率含义 |
| 6.2 缓存击穿 | 热点 key 过期瞬间的一万并发为什么全去查库？ | 模拟热点 key 失效压测；实现互斥重建与逻辑过期两种方案并对比 | 能说清两方案在「一致性 vs 可用性」上的取舍 |
| 6.3 缓存雪崩 | 大批 key 同时过期 / 实例宕机，怎么不把库压垮？ | TTL 加随机抖动前后对比；讨论多级缓存与熔断兜底 | 能给出「事前预防 + 事中熔断 + 事后恢复」三层方案 |
| 6.4 缓存一致性 | 先更新库再删缓存，什么时序还是会脏？延迟双删、binlog 订阅各解决什么？ | 推演 Cache Aside 的脏读窗口；实现「更新库 → 删缓存 → 延迟再删」；了解 canal 订阅 binlog 异步删 | 能画出至少两种方案的时序图并指出各自的不一致窗口 |
| 6.5 热 key | 某个 key 扛了全站流量怎么发现、怎么拆？ | 用 redis-cli --hotkeys（或监控）定位；实现「key 加随机后缀分片 + 汇总」治理 | 说清发现手段与「本地缓存 / key 打散」两种治理路线 |
| 6.6 大 key | 一个 100MB 的 value 危害在哪？删除为什么也要异步？ | --bigkeys 与 MEMORY USAGE 扫描；对比 DEL 与 UNLINK；复现大 key 引发的阻塞告警 | 说清大 key 三宗罪（内存倾斜、删除阻塞、带宽打爆）与治理四招 |
| 6.7 分层决策 | 什么数据该放 Redis、什么不该？ | — | 一张决策表：数据大小、读写比、一致性要求、丢失容忍四个维度 |
阶段验收：给定一份「商品详情页」真实代码（故意埋了穿透 + 大 key + 无 TTL 三个雷），限时代码评审找出全部问题并给出修复 PR。
十一、阶段 7：现代 Redis——8.x 新世界（第 13 周后半 ~ 第 14 周前半）
为什么有这个阶段：Redis 8 是一次身份转变——从「缓存/数据结构服务器」变成「实时数据平台」。新能力（JSON、Search、Vector Sets）正在进入主流生产栈；许可证剧变（BSD → RSAL/SSPL → AGPLv3）直接影响技术选型。资深工程师必须看得懂这张新地图。
| 单元 | 回答的核心问题 | 动手实验 | 吃透的标准 |
|---|---|---|---|
| 7.1 许可证与生态史 | 2024-03 改 RSAL/SSPL 引出了什么？Valkey 是谁？2025-05 的 AGPLv3 意味着什么？ | 梳理时间线：BSD 三十年 → 双许可风波 → Valkey 分叉（Linux 基金会）→ AGPLv3 回归 | 能回答「我们公司用 Redis 开源版有没有合规风险」「Redis CE 与 Valkey 怎么选」 |
| 7.2 JSON 文档 | RedisJSON 解决了「String 存 JSON 改一个字段要整个重写」的什么痛点？ | JSON.SET / JSON.GET + JSONPath 存取商品多规格数据，与 Hash 方案对比 | 能演示按路径读改嵌套字段，并说出适用场景 |
| 7.3 Search 查询引擎 | FT.CREATE / FT.SEARCH 怎么给 Redis 装上全文与聚合能力？ | 给商品名建全文索引，跑「关键词 + 价格区间」混合查询 | 说清倒排索引在 Redis 里的形态，及与 ES 的分工边界 |
| 7.4 TimeSeries | TS.ADD / TS.RANGE 怎么存监控指标？降采样怎么做？ | 写入一段时间序列，按窗口聚合查询（8.10 新增 TS.READ / TS.NRANGE 等命令一并试） | 能为一个 IoT 温度场景设计 label 与聚合策略 |
| 7.5 概率结构 | Bloom / Cuckoo / TopK / Count-Min Sketch / T-Digest 各解决什么「大约就够」的问题？ | 每种结构跑一遍增查统计，记录误差率 | 能为「去重判存、频次估计、分位数统计」选对结构 |
| 7.6 Vector Sets 与 AI | VADD / VSIM 怎么做相似检索？HNSW 为什么快？和 RAG 什么关系？ | 用文本 embedding（任意开源模型）入库 Vector Sets，实现「相似文章推荐」最小闭环 | 能说清向量检索的流程（向量化 → 入库 → KNN 查询）与 HNSW 的分层跳查直觉 |
| 7.7 8.2 → 8.10 演进速览 | 半年一版各带来了什么？Compact hashes、BACKUP 命令值得升级吗？ | 读官方 Release Notes，在 8.10 上体验 BACKUP 与 Compact hashes 内存对比 | 能为团队写一份「是否升级 8.10」的一页评估 |
阶段验收：用 8.x 新能力搭一个「商品搜索 + 相似推荐」小 demo（JSON 存储 + Search 关键词过滤 + Vector Sets 相似召回），全程不引入第二个中间件。
十二、阶段 8：性能与运维（第 14 周后半 ~ 第 15 周）
为什么有这个阶段：前面的能力决定你能不能构建，这一阶段决定你能不能守住。值班时 Redis 告警了，你的每一步排查都要有出处。
| 单元 | 回答的核心问题 | 动手实验 | 吃透的标准 |
|---|---|---|---|
| 8.1 慢查询定位 | SLOWLOG 与 latency monitor 怎么联动定位卡顿？ | 构造慢命令与大 key 场景，用两套工具还原现场 | 接到「Redis 偶发卡 100ms」工单时有标准排查路径 |
| 8.2 INFO 指标体系 | 哪十个指标值得上监控大盘？各预警什么病？ | 逐节读 INFO 输出，标注每项含义；搭建基础告警规则 | 能背出核心五项：内存水位、连接数、拒绝连接、主从延迟、碎片率 |
| 8.3 内存治理 | 碎片率 >1.5 说明什么？activedefrag 什么时候开？ | 制造碎片场景，观察 mem_fragmentation_ratio，验证碎片整理效果 | 说清碎片产生机理与在线整理的代价 |
| 8.4 安全 | ACL（7.0+）怎么做到命令级授权？哪些命令必须禁用？ | 配置多用户 ACL：只读账号、禁 FLUSHALL/KEYS；开 TLS | 能给一套「应用账号 + 运维账号 + 只读账号」的 ACL 方案 |
| 8.5 备份与容量 | 大促前怎么估算内存与带宽？8.10 的 BACKUP 命令和 RDB 备份什么关系？ | 压测推算容量；演练一次完整备份恢复（RDB + BACKUP 两种方式） | 有一张自己环境得出的「QPS-内存-带宽」容量对照表 |
阶段验收：一次模拟故障演练——「应用反馈 Redis 间歇超时」，限时 30 分钟内用监控数据定位到根因（预埋为 bigkey + 持久化 fork 卡顿组合）。
十三、阶段 9：毕业——综合实战（第 16 周）
毕业设计：一个短视频互动系统
所有环节只准用 Redis（+ MySQL 落库），强制覆盖全大纲考点：
| 功能 | 强制考点 | 对应阶段 |
|---|---|---|
| 视频点赞数与作者排行榜 | ZSet + pipeline 批量 | 0 / 5 |
| 秒杀限量礼物 | Lua 原子预扣 + Redisson 锁兜底 + 防超卖压测 | 5 / 6 |
| 关注流 Feed（推拉结合） | List/Stream + 消费组 + 大 V 拉模式 | 5 |
| 视频标签去重与热度估计 | Set + HyperLogLog/TopK | 7 |
| 相似视频推荐 | Vector Sets + HNSW | 7 |
| 缓存装配（视频详情） | Cache Aside + 随机 TTL + 穿透防护 | 6 |
| 部署形态 | 3 主 3 从 Cluster + 故障演练 | 3 / 4 / 8 |
交付物：架构图一张、每个功能的选型理由（必须能落到具体机制说理）、可运行代码、故障演练记录（杀主节点 / 制造大 key / 热 key 三次演练）。
资深自检 20 问（节选）
- 单线程为什么快？8.x 的 io-threads 多线程化了哪一段、为什么命令执行仍是单线程？
- everysec 策略下宕机，最多丢多久的写入？这个窗口由什么决定？
- 从库断线重连，什么条件走增量复制、什么条件退化为全量？backlog 大小怎么估？
- 哨兵的 quorum 和 majority 分别防住什么故障场景？
- Cluster 为什么选 16384 个槽而不是更多或更少？（提示：心跳包里的槽位图大小）
- MOVED 和 ASK 的区别，迁移中各出现在哪一步？
- Lua 脚本的原子性和事务的原子性是一回事吗？
- Redis 事务为什么设计成不回滚？这个设计换来了什么？
- 分布式锁的看门狗解决什么问题？Redlock 争议的核心分歧点是什么？
- 缓存雪崩和击穿都表现为「数据库被打」，怎么从现象上区分？
（完整 20 问在毕业设计时自测，答不出哪个，回对应阶段补哪个。）
十四、总时间线
| 周 | 内容 |
|---|---|
| 1 ~ 2 前半 | 阶段 0：地基，Redis 用起来 |
| 2 后半 ~ 4 | 阶段 1：单机内核（重点攻坚） |
| 5 | 阶段 2：持久化 |
| 6 ~ 7 前半 | 阶段 3：主从复制与哨兵 |
| 7 后半 ~ 9 | 阶段 4：Cluster |
| 10 ~ 11 | 阶段 5：客户端与工程化 |
| 12 ~ 13 前半 | 阶段 6：缓存工程 |
| 13 后半 ~ 14 前半 | 阶段 7：8.x 新世界 |
| 14 后半 ~ 15 | 阶段 8：性能与运维 |
| 16 | 阶段 9：毕业设计 |
每天 1.5 ~ 2 小时。进度可以慢，顺序不要乱：每个阶段的验收没过，不进下一阶段。
十五、参考资料（撰写时均已核验）
官方文档与发布记录
- Redis 官方文档（latest）——命令与机制以此为准，网上 6.x 时代的结论经常过时
- redis/redis GitHub Releases——版本事实的唯一权威来源；当前最新稳定版 8.10.1，维护线覆盖 6.2 ~ 8.10（2026-08 核验）
- Redis 8 GA 发布博客——Stack 并入核心、性能数据、新命令清单
- Redis 回归开源（AGPLv3）公告——2025-05 许可证变更的官方说明
- Vector Sets 发布博客——HNSW、VSIM 与向量检索入门
书（按阅读时机）
- 《Redis 设计与实现》黄健宏——底层结构（SDS/dict/skiplist）讲解仍是最清晰的中文材料；注意其基准是 3.0（ziplist 等已演进为 listpack），当「原理教材」读，当「现状手册」用官方文档
- 《数据密集型应用系统设计》（DDIA）第 5、6 章——复制与分片的通用理论，读完阶段 3、4 再读，吸收率完全不同
本博客已有材料
本目录早期系列 10 篇（01 安装部署 ~ 10 底层结构，Redis 7 基准）对应本大纲的阶段 0 ~ 4 与阶段 1 的部分单元，可在相应阶段先行阅读；遇到与 8.10 行为不一致处（如新命令、默认值），以官方文档与本大纲后续新篇为准。
结语：一条线，走到底
这份大纲的本质是把一张互相咬合的知识网压平成一条链：
用起来 → 懂内核 → 保不丢 → 高可用 → 能扩展 → 会工程 → 不踩坑 → 看得远（8.x）→ 守得住 → 串起来
每个环节只有一个入口——前一个环节。从阶段 0 第一个压测实验开始，走完这条线，你就是能讲、能选、能写、能读、能修的 Redis 资深工程师。
下一篇，从阶段 0 的第一个实验开始：先把 redis:8.10 跑起来。