1. 课程导论：为什么需要基于领域边界的缓存策略？性能瓶颈分析与缓存失效的常见场景
在 Go 后端项目中，缓存是提升系统吞吐量、降低数据库压力的核心手段。然而，许多团队在引入缓存后，反而遇到了数据不一致、缓存雪崩、穿透、击穿等“缓存病”。究其根源，往往在于缓存粒度过粗或缓存边界与业务领域边界不匹配。本讲将剖析性能瓶颈的典型成因，并引出“基于领域边界”的缓存设计思想。
1.1 性能瓶颈：缓存为何没能解决问题？
一个典型的 Go Web 服务，其请求链路通常包含网关、业务逻辑层、数据访问层与数据库。当并发量上升时，不加区分的全量缓存策略会引发以下问题：
| 瓶颈类型 | 现象 | 根因 |
|---|---|---|
| 缓存穿透 | 请求绕过缓存直接打到 DB，DB 连接数飙升 | 查询不存在的数据，缓存未命中且未做空值缓存 |
| 缓存击穿 | 热点 key 过期瞬间，大量并发请求穿透至 DB | 单点热点 key 过期，无互斥锁或提前续期机制 |
| 缓存雪崩 | 大量 key 同时过期，DB 瞬时压力爆表 | 缓存过期时间集中，缺乏随机化或二级缓存 |
| 数据不一致 | 用户读到旧数据，业务逻辑出错 | 缓存与 DB 更新时序不一致，缺乏领域级同步策略 |
| 内存浪费 | 缓存命中率低，大量冷数据占用内存 | 缓存粒度与业务查询维度不匹配，缓存了过多无用字段 |
关键洞察： 上述问题的共同特征是缓存策略没有与业务领域边界对齐。例如，将整个“用户聚合”作为一个缓存 key，当用户仅修改头像时，整个聚合被失效，导致其他字段的缓存也被误伤。
1.2 缓存失效的常见场景与领域边界缺失
我们以一个电商订单系统为例，分析缓存失效的典型场景：
- 场景一：全量对象缓存 —— 将整个
Order结构体（含 30+ 字段）缓存为 JSON。当订单状态从“待支付”变为“已支付”时，整个缓存被删除。但订单中的收货地址、商品快照并未变化，却也被迫重新查询。 - 场景二：跨服务缓存共享 —— 订单服务与库存服务共用同一 Redis key 前缀。库存服务更新库存后，未通知订单服务，导致订单服务读到过时的库存数据。
- 场景三：批量查询无局部失效 —— 前端请求“最近 100 条订单”，服务层将整个列表缓存。当其中一条订单状态变更时，整个列表缓存失效，所有用户重新查询 DB。
这些场景的共性在于：缓存 key 的边界大于业务变更的边界。正确的做法是：将缓存粒度拆解到与领域实体或值对象对齐的级别。
1.3 基于领域边界的缓存策略：核心思想
领域驱动设计（DDD）中的“聚合根”概念为缓存边界提供了天然参考。每个聚合根对应一个缓存单元，聚合内的变更只影响该聚合的缓存，不波及其他聚合。同时，跨聚合的数据同步通过领域事件驱动，而非全量失效。
核心原则： 缓存 key 的粒度 = 领域聚合根的粒度；缓存失效的范围 = 聚合内部变更的范围。
下图展示了传统缓存策略与基于领域边界的缓存策略在失效范围上的差异：
1.4 领域事件驱动的数据同步
当缓存按领域边界拆分后，数据同步不再依赖“全量删除+重新查询”，而是通过领域事件进行精准推送。以下是一个典型的同步流程：
- 业务操作：用户发起“支付订单”请求。
- 领域层：订单聚合根修改状态为“已支付”，并发布
OrderPaidEvent。 - 事件处理器：监听该事件，仅失效订单状态对应的缓存 key（如
order:status:{orderID}）。 - 查询时：若状态缓存缺失，从 DB 加载并回填；其他字段缓存（收货地址、商品快照）保持不变。
注意： 领域事件同步要求事件总线具备至少一次投递语义，且消费者需幂等处理。Go 中常用
watermill、asynq 或 Kafka 实现。
下图展示了基于领域事件的数据同步架构：
1.5 本课程路线图
在后续章节中，我们将依次深入：
- 第 2-4 章：Go 内存缓存（sync.Map、freecache、ristretto）的选型与压测。
- 第 5-7 章：Redis 缓存策略（多级缓存、热点 key 探测、分布式锁）。
- 第 8-10 章：领域事件驱动缓存同步（事件溯源、CQRS 模式）。
- 第 11-13 章：实战案例：订单系统、库存系统、用户系统的缓存重构。
- 第 14-15 章：监控、告警与持续调优（pprof、prometheus、缓存命中率分析）。