12 Redis 学习验收与面试
从“我看懂了”，走到“我能独立处理”
Section titled “从“我看懂了”，走到“我能独立处理””学习目标 · 用业务约束解释设计，完成三个场景推演，并通过小练习证明自己会用。
12.1 三个场景，练习工程判断
Section titled “12.1 三个场景，练习工程判断”案例 A · 爆款商品上线，数据库突然变慢
先问清：是不是同一个商品集中回源？Key 是否刚到期？接口是否反复读取相同字段？先缓解：限制回源并发，合并同 Key 请求，可容忍旧值时使用有界陈旧数据。再改进：热点预热、合理 TTL、互斥或逻辑过期、本地缓存。验证：数据库 QPS、同 Key 回源数、接口 P99 与旧值时长同时看，不能只看命中率。
案例 B · Redis 不可用，接口要不要全部查数据库？
先根据数据库余量和接口重要性分级。浏览详情可用限流回源或本地旧值；推荐列表可返回明确的降级内容；登录态、验证码不可因缓存异常无条件通过。设置熔断和恢复探测，限制全实例总回源量。恢复后逐步预热与放量，观察错误率和 DB 负载，不能一恢复连接就瞬间释放全部流量。
案例 C · 用户改了店铺名称，偶尔仍看见旧名称
先区分浏览器缓存、CDN、后端本地缓存、Redis 和数据库副本。检查请求读写时间线：是否事务提交前删缓存、是否 DEL 失败、是否发生旧读晚回填、是否读了滞后副本。按业务允许的陈旧窗口采取提交后失效、可靠重试、版本化方案或关键读取绕过缓存。不要不加分析地把 TTL 改成 1 秒，那可能制造回源压力。
12.2 高频面试题：按“结论 → 原因 → 例子 → 边界”回答
Section titled “12.2 高频面试题：按“结论 → 原因 → 例子 → 边界”回答”基础 01 · Redis 与 MySQL 有什么区别？
Redis 常用于低延迟的数据结构操作和共享状态，MySQL 擅长关系模型、约束、事务和查询。选型看访问模式与正确性需求，不是简单“一个内存、一个磁盘”。商品详情可以加缓存，交易事实仍需可靠存储和并发约束。
基础 02 · Redis 为什么快？是单线程吗？
主要是内存访问、合适的数据结构与高效网络处理。普通命令主要在主线程执行，但 I/O 和后台工作可用其他线程/进程。单条慢命令会影响其他请求，网络、Value 大小和客户端也会成为瓶颈。
基础 03 · 五种常用类型各举一个例子
String：商品 JSON / 计数；Hash：用户局部属性；List：最近访问记录；Set：去重点赞成员；ZSet：按积分排序。继续说明关键操作，而不只报类型名，例如排行榜需要更新积分、取 Top N 和查询排名。
项目 04 · 穿透、击穿、雪崩如何区分？
穿透是请求不存在数据；击穿是热点失效引发集中回源；雪崩是大量缓存失效或缓存整体故障。分别考虑校验/空值/布隆、请求合并/互斥/旧值、过期分散/高可用/限流降级，不能用同一个“加锁”回答全部。
项目 05 · 缓存与数据库如何保持一致？
先明确允许多长陈旧窗口，再讲 Cache Aside 的提交后删除、失效失败重试和 TTL。补充旧读晚回填、写入顺序等竞态。普通缓存追求可接受的最终一致；需要强约束的决策读取，不能仅依赖异步更新缓存。
项目 06 · Redis 分布式锁有哪些坑？
加锁要带 NX 和过期，Value 是本次唯一令牌；解锁要原子比较后删除。业务超过租约、GC 暂停、续期失败和故障切换丢锁都可能产生重复执行。Redisson 封装机制但不消除正确性边界，下游还要幂等、约束或版本校验。
项目 07 · Pipeline、事务和 Lua 的区别？
Pipeline 减少逐条等待；MULTI/EXEC 组织一组命令执行，WATCH 检测竞争；Lua 在服务端做依赖读取结果的判断和写入。Pipeline 不保证整批原子性，事务和 Lua 不提供运行错误后的回滚。
进阶 08 · RDB 与 AOF 怎么选？
围绕允许丢多少数据、恢复多快、写入压力和备份成本比较。RDB 是快照，AOF 记录重建数据的写操作，按刷盘策略折中；可能同时使用，但需要实测备份和恢复。持久化不替代副本，也不等于数据绝不丢失。
进阶 09 · 内存满了会发生什么？
看 maxmemory 和淘汰策略。allkeys 类策略可以提前移除未过期数据；volatile 类只选设 TTL 的 Key；noeviction 下需要增加内存的写可能失败。要监控淘汰、拒绝写和进程实际内存，按数据语义隔离重要状态。
进阶 10 · 热 Key 与大 Key 如何处理？
热 Key 是访问集中，大 Key 是数据量/元素量大，可能同时存在。热点考虑本地缓存、合并请求和业务拆分；大 Key 先减字段、分页、分桶，谨慎迁移删除。Cluster 不会自动把一个 Key 拆到多台机器。
进阶 11 · Sentinel、Cluster 与复制有什么关系？
复制增加数据副本；Sentinel 管理非分片主从的监控和切换；Cluster 通过哈希槽做分片并提供集群故障处理。客户端要支持对应拓扑。异步复制带来延迟和丢写窗口，不能因此声称强一致。
项目 12 · 你做过什么 Redis 优化？
用真实经历回答：现象和基线 → 指标定位 → 具体改动 → 同条件验证 → 代价与边界。例如“我在练习环境比较了逐条 GET 与 MGET，在固定 Value 和并发条件下记录延迟变化”。没有线上经历就说明是实验，不虚构 QPS 或公司业务规模。
12.3 七次练习，一次只解决一个问题
Section titled “12.3 七次练习，一次只解决一个问题”| 次序 | 建议任务 | 可以交付给自己的证据 |
|---|---|---|
| 1 | 第 1–2 章：画请求路径、启动 Redis、验证 TTL | 一张路径图 + 过期前后输出 |
| 2 | 第 3 章：点赞、排行榜、签到的数据选型 | 对应 Key、命令、查询结果 |
| 3 | 第 4–5 章：在现有项目加入一次缓存读写 | 首次回源、再次命中、空值与异常的记录 |
| 4 | 第 6–7 章：限流与缓存故障推演 | 3 次允许/第 4 次拒绝，以及故障处理表 |
| 5 | 第 8 章：事务报错、锁令牌、重复请求 | 错误不会回滚的输出 + 并发时间线 |
| 6 | 第 9–11 章：正常重启、INFO 与小规模对照实验 | 观察数据、诊断结论、验证方法 |
| 7 | 本章：独立解释案例并口述面试题 | 不看答案讲清原因、方案与限制 |
每次按你的节奏安排约 45–90 分钟，需要配置环境时允许更久。章节完成标记只代表你的自评，不代表通过自动能力认证。第一遍先掌握必会内容，第二遍再补高可用、性能与面试追问。
12.4 命令速查：按问题找命令
Section titled “12.4 命令速查：按问题找命令”| 你想做什么 | 常用命令 |
|---|---|
| 判断类型、存在与剩余寿命 | TYPE / EXISTS / TTL / PTTL |
| 写入并设置过期 | SET key value EX 秒数；NX 为仅不存在时写 |
| 读取字符串 / 一组字符串 | GET / MGET（Cluster 留意同槽限制） |
| 原子增加 | INCR / INCRBY；结果未知时不能盲重试 |
| 对象字段操作 | HSET / HGET / HMGET / HINCRBY |
| 最近记录 | LPUSH / LRANGE / LTRIM |
| 去重、判断成员、计数 | SADD / SREM / SISMEMBER / SCARD |
| 积分排序 | ZADD / ZINCRBY / ZRANGE … REV / ZREVRANK |
| 游标查找 | SCAN / HSCAN / SSCAN / ZSCAN |
| 诊断 | INFO / SLOWLOG GET / MEMORY USAGE / OBJECT ENCODING |
| 删除明确属于自己的 Key | DEL；大对象释放评估 UNLINK |
- 学完视频就认为自己会用：至少亲手验证未命中、异常和重复请求。
- 为了面试堆砌所有技术：先明确约束，再选最少的有效措施。
- 只报结论和数字：能说明测量条件、失败路径和代价，回答才可信。
不翻前文，设计一个店铺详情缓存：给出 Key、TTL、空结果处理、更新时机、热点重建与 Redis 不可用策略。选一个环节写 10–30 行核心代码，或画出足够清楚的执行顺序。
自测与答案 · 判断自己是否达到了“会用”
你能独立完成：启动并连接 Redis；为操作选择结构；在 Spring Boot 读写且解释序列化；实现带 TTL 的缓存读取；区别未命中和故障；解释更新竞态与锁过期；读取指标并提出一次可验证的优化。店铺练习可用 shop:detail:v1:ID，按允许陈旧窗口选 TTL 和抖动，空结果短期缓存，事务提交后失效并可靠重试，热点合并重建，故障时限流回源或返回可接受旧值。能够说明这些方案的边界，比记住所有配置项更接近真正会用。