Redis 与缓存：什么时候才需要
Redis 把数据放在内存中，适合缓存、短期状态和部分队列场景。它是选修优化工具，不应在没有测量前替代主数据库。
- 为任务统计设计一个带过期时间的缓存，并能说明缓存失效后怎样回到数据库。
- 缓存命中、失效、TTL 与数据源
- 复现Redis 与缓存：什么时候才需要后，应当为任务统计设计一个带过期时间的缓存，并能说明缓存失效后怎样回到数据库，并保留查询结果、影响行数、迁移记录和缓存命中情况作为可重复检查的依据。
- 完成 6.3「ORM、Schema 与数据库迁移」
FOUNDATION
必须理解
Redis 是以内存为主的数据存储，常用于缓存、限流、短期会话或队列。它很快，但不是所有项目都需要；过早加入会增加一致性和运维复杂度。
本课依次讲清缓存命中、失效、TTL 与数据源、会话、验证码、限流和任务状态和缓存一致性与雪崩、穿透的基础风险，最后通过“模拟缓存中是旧值，验证失效后能从数据库恢复”检查学习结果。
主数据库像档案库，Redis 缓存像前台常用资料夹。资料夹取用快，却可能过期；关键档案不能只留在前台。
任务应用初期直接查询 PostgreSQL。只有真实监控显示热门统计查询成为瓶颈时，才把可重新计算的结果缓存到 Redis 并设置过期时间。
缓存命中、失效、TTL 与数据源
Redis 最常见的用法是拿一个 key 快速找到 value，它还支持集合和哈希等结构。数据主要放在内存里，所以很快，但容量和故障方式与 PostgreSQL 不一样。
基础概念
缓存保存数据源结果的临时副本。命中表示缓存已有可用值，未命中需查询真实数据源；失效使旧副本不可再用；TTL（Time To Live，生存时间）规定自动过期时长。
进一步理解
常见读流程是先查缓存，未命中查数据库并写回。写操作后要删除或更新相关键，否则用户继续读到旧数据。
TTL 是最后防线而非完整一致性策略。时间越长命中率可能越高，旧数据窗口也越长，要按业务可接受程度选择。
项目统计缓存为 `project:42:summary` 五分钟；任务改变后立即删除该键，下次请求重新从数据库计算。
缓存值不是新的权威数据源。若数据库与缓存冲突，必须预先定义哪一方为真以及如何恢复。
这一小节记住：缓存是可丢失、可重建、有明确失效规则的数据副本。
会话、验证码、限流和任务状态
缓存里有结果就直接返回，这叫命中；没有就去查数据库，再把结果放回来。数据更新后要记得让旧缓存失效，否则用户会一直看到旧内容。
基础概念
Redis 是以内存访问为主的数据系统，除缓存外常用于短期会话、验证码、限流计数和任务状态。不同用途需要不同数据结构、过期与持久化策略。
进一步理解
验证码强调短 TTL 与一次性，限流强调原子计数，会话强调安全标识和撤销，后台任务状态强调进度更新。不能用同一套键和值机械处理。
Redis 很快，但内存昂贵且可能重启或淘汰数据。是否允许丢失决定它能否独立承载某类状态。
登录尝试以用户与时间窗口为键原子计数，超过阈值暂时拒绝；确实用户账户仍保存在关系型数据库。
会话使用 Redis 不代表身份校验自动安全；令牌生成、Cookie、过期、撤销和权限仍需要完整设计。
这一小节记住：先明确数据能否丢、活多久和如何重建，再选择 Redis 用法。
缓存一致性与雪崩、穿透的基础风险
TTL 是一条缓存还能活多久，到时间会自动过期。缓存会带来击穿、雪崩和键设计等新问题，所以先确认真的需要，再引入会更省事。
基础概念
缓存一致性关注副本与数据源何时同步；穿透是大量查询永远不存在的数据，击穿是热点键失效瞬间压垮数据源，雪崩是大量键同时失效造成集中回源。
进一步理解
应对方式包括缓存空结果、请求合并、随机化过期、限流和热点预热，但每种措施都会增加复杂性。
确实解决前先用延迟、查询量和命中率证明瓶颈。很多小应用直接优化 SQL 和索引比引入 Redis 更简单可靠。
热门项目统计失效时只允许一个请求回源重建，其他请求等待；TTL 加少量随机抖动避免整批同时过期。
缓存问题不是只有“过期太短”。永不过期会产生长期旧数据，过度预热又会缓存无人访问内容。
这一小节记住：缓存优化必须同时设计回源压力、失效时机和降级行为。
AI COLLABORATION
AI 如何参与
在Redis 与缓存：什么时候才需要这一课，AI 负责根据真实材料解释缓存命中、失效、TTL 与数据源并指出遗漏，学习者负责控制范围、执行修改和核对查询结果、影响行数、迁移记录和缓存命中情况。
推荐协作顺序
- 1
先给 AI 真实查询耗时、数据量和访问频率。
- 2
要求它先证明缓存能解决当前瓶颈，而不是默认上 Redis。
- 3
如果确实需要，再一起设计 key、TTL、未命中和失效流程。
这是慢查询证据、数据更新路径和一致性要求。请判断是否值得缓存，再设计键、值、过期时间、失效时机和回源流程。不要把 Redis 当唯一持久数据源，不保存秘密。
AI 应允许结论是暂时不需要 Redis；若设计缓存，要明确主数据库是真相和失效策略；Redis 与缓存：什么时候才需要的人工验收必须回到真实页面、请求、终端、测试或数据结果，不能用 AI 的文字说明代替。
人工检查清单
- 确认缓存不跨用户泄露数据，key 包含用户边界，敏感内容与 TTL 合理。
- 让 AI 先提供真实查询耗时、频率和可接受旧数据窗口，再设计键、TTL 与失效。
- 通过缓存命中、未命中、数据更新、Redis 不可用和热点过期五种场景验证系统仍正确。
COMMON TRAPS
常见误区
下面三类问题会让任务看似完成，却经不起刷新、错误输入或真实环境检查。先看现象，再找原因和修正方法。
没有测量就加缓存
- 你会看到
- 系统更复杂却没有明显收益
- 为什么发生
- 缓存增加一致性和失效成本，若瓶颈不在读取，复杂度不会换来收益。
- 怎样纠正
- 先记录慢点和访问频率
把 Redis 当唯一数据库
- 你会看到
- 重启或淘汰后任务无法恢复
- 为什么发生
- 缓存数据可能过期、淘汰或丢失，不能默认承担永久事实的唯一副本。
- 怎样纠正
- 持久事实仍放主数据库
忘记失效旧值
- 你会看到
- 用户修改任务后仍看到旧统计
- 为什么发生
- 数据库更新后缓存仍返回旧副本，用户会看到彼此矛盾的结果。
- 怎样纠正
- 定义每条写路径的缓存处理
HANDS-ON
动手任务
为任务统计设计一个带过期时间的缓存，并能说明缓存失效后怎样回到数据库。
- 完成 6.3「ORM、Schema 与数据库迁移」
跟着做
- 01
记录当前任务查询耗时与数据量。
- 02
判断瓶颈是否真实存在，写出不加缓存的基线。
- 03
为一项可重算统计设计 key 与 TTL。
- 04
画出命中、未命中、任务更新三条流程。
- 05
模拟缓存中是旧值，验证失效后能从数据库恢复。
为任务统计设计一个带过期时间的缓存，并能说明缓存失效后怎样回到数据库。
解释为什么不能简单地把用户全部任务永久缓存，并提出一种避免跨用户 key 冲突的命名。
离开本课前，自问四件事
- 缓存命中、未命中、失效和 TTL 分别是什么？
- 哪些 Redis 数据允许丢失，哪些需要其他权威数据源？
- 缓存穿透、击穿和雪崩有什么区别？
- 引入缓存前应收集哪些性能与一致性证据？
确认完成后，会同步更新学习中心的课程学习进度。