[!info] related notes

• 上层入口：Backend Engineering MOC、Backend 常用中间件与基础设施 MOC
• 核心关系：缓存策略与一致性
• 具体实现：Redis、Go 缓存策略
• 相邻地图：数据库 MOC、Reliability Engineering MOC

Caching MOC

知识总览

filters:
  and:
    - 'file.ext == "md"'
    - 'file.inFolder("z")'
    - 'this.file.links.contains(file)'
    - 'file.path != this.file.path'
formulas:
  knowledge: 'file.asLink(title)'
properties:
  formula.knowledge:
    displayName: 知识
  note.description:
    displayName: Description
  note.mastery:
    displayName: Mastery
views:
  - type: table
    name: 知识总览
    order:
      - formula.knowledge
      - note.description
      - note.mastery
    columnSize:
      formula.knowledge: 280
      note.description: 760
      note.mastery: 56

[!abstract] 核心认识 缓存用空间和一致性复杂度换延迟与容量。第一问题不是“用 Redis 还是本地 Map”，而是：谁是事实源、允许读旧多久、失效失败时会怎样、缓存故障会不会打垮下游。

一张图看基本模型

Client
→ Cache
   ├─ hit  → return derived copy
   └─ miss → Source of Truth → fill cache → return

推荐阅读顺序

1. 缓存策略与一致性：事实源、Cache-aside、TTL 与失效。
2. Redis：分布式缓存、数据结构、持久化与高可用。
3. Go 缓存策略：本地缓存、Redis、singleflight 与多级缓存。
4. 接口幂等设计：写路径和重复请求。
5. Backpressure、Circuit Breaker：缓存失效时保护数据库。

核心问题树

数据正确性

• Source of Truth 是谁？
• Stale Read 可接受多久？
• 写后删除、更新还是版本化？
• DB 提交与缓存失效之间的窗口怎样处理？

容量与热点

• 穿透：不存在的 key 持续打事实层。
• 击穿：热点 key 失效时大量并发回源。
• 雪崩：大量 key 或缓存节点同时失效。
• Hot Key / Big Key：流量或数据集中到单点。

多实例与多级缓存

L1 process cache
→ L2 Redis
→ Database

层级越多，失效广播、版本和观测越重要。

设计检查表

• key 包含稳定命名空间和版本。
• TTL 有业务含义，并加入适当抖动。
• miss 回源设置 timeout、并发合并和容量保护。
• 写路径在事务提交后失效或更新缓存。
• 缓存不可用时有 fail-open / fail-closed 决策。
• 监控 hit rate、latency、evictions、memory、hot key 和 backend load。
• 明确缓存是否可重建，避免悄悄成为唯一事实库。

Related notes

• Redis
• 数据库 MOC
• Backend 常用中间件与基础设施 MOC