Redis 与缓存：什么时候才需要
Redis 擅长快速访问短期数据、缓存和限流，但它不是所有数据的默认归宿。
- 知道 Redis 是优化工具，而不是关系型数据库替代品。
- 缓存命中、失效、TTL 与数据源
- 为一个读取频繁、变化较少的查询设计缓存，并写清何时失效。
- 完成 6.3「ORM、Schema 与数据库迁移」
FOUNDATION
必须理解
Redis 擅长快速访问短期数据、缓存和限流，但它不是所有数据的默认归宿。
Redis 是以内存为主的数据存储，常用于缓存、限流、短期会话或队列。它很快，但不是所有项目都需要；过早加入会增加一致性和运维复杂度。
主数据库像档案库，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 如何参与
让 AI 先证明性能瓶颈和可接受的不一致窗口，再设计缓存键与失效策略。
推荐协作顺序
- 1
先给 AI 真实查询耗时、数据量和访问频率。
- 2
要求它先证明缓存能解决当前瓶颈，而不是默认上 Redis。
- 3
如果确实需要，再一起设计 key、TTL、未命中和失效流程。
任务应用目前每次打开都查询当前用户约 30 条任务。请先判断是否需要 Redis，并列出必须收集的性能证据。然后以“已完成任务统计”为例设计 cache-aside 流程，写明 key、TTL、命中、未命中和更新失效。
AI 应允许结论是暂时不需要 Redis；若设计缓存，要明确主数据库是真相和失效策略。
人工检查清单
- 确认缓存不跨用户泄露数据，key 包含用户边界，敏感内容与 TTL 合理。
- 让 AI 先提供真实查询耗时、频率和可接受旧数据窗口，再设计键、TTL 与失效。
- 通过缓存命中、未命中、数据更新、Redis 不可用和热点过期五种场景验证系统仍正确。
COMMON TRAPS
常见误区
错误不是需要隐藏的失败，而是帮助你看清系统边界的证据。下面三类问题在 AI 辅助学习中最常出现。
项目刚开始就加 Redis
- 你会看到
- 数据只有几十条，却先引入第二套存储和部署配置。
- 为什么发生
- 没有性能证据就加入 Redis，会增加第二份数据、网络故障与部署成本，却未必改善用户体验。
- 怎样纠正
- 先测量 PostgreSQL 的真实表现，没有瓶颈就保持简单。
只写缓存，不管失效
- 你会看到
- 用户完成任务后，统计仍显示旧数字。
- 为什么发生
- 写数据库后忘记失效缓存，会形成长期可复现的旧数据，排查时两边看起来都“正确”。
- 怎样纠正
- 每个缓存都要同时设计更新或删除时机。
缓存键没有用户边界
- 你会看到
- 不同用户读到同一个 key 下的数据。
- 为什么发生
- 大量键使用同一过期时间会一起回源，原本保护数据库的缓存反而制造流量尖峰。
- 怎样纠正
- key 中包含明确租户或用户标识，并检查敏感数据隔离。
HANDS-ON
动手任务
为一个读取频繁、变化较少的查询设计缓存，并写清何时失效。
- 完成 6.3「ORM、Schema 与数据库迁移」
跟着做
- 01
记录当前任务查询耗时与数据量。
- 02
判断瓶颈是否真实存在，写出不加缓存的基线。
- 03
为一项可重算统计设计 key 与 TTL。
- 04
画出命中、未命中、任务更新三条流程。
- 05
模拟缓存中是旧值，验证失效后能从数据库恢复。
知道 Redis 是优化工具，而不是关系型数据库替代品。
解释为什么不能简单地把用户全部任务永久缓存，并提出一种避免跨用户 key 冲突的命名。
离开本课前，自问四件事
- 缓存命中、未命中、失效和 TTL 分别是什么？
- 哪些 Redis 数据允许丢失，哪些需要其他权威数据源？
- 缓存穿透、击穿和雪崩有什么区别？
- 引入缓存前应收集哪些性能与一致性证据？
确认完成后，会同步更新学习中心的课程学习进度。