1. 课程导论：一致性问题的本质、缓存与数据库的博弈、领域建模的引入价值
1.1 一致性问题的本质：从 CAP 到数据裂缝
在分布式系统与高并发架构中，缓存与数据库之间的数据不一致，本质上是状态传播延迟与操作顺序错乱共同作用的结果。从 CAP 定理的视角看，当系统选择可用性（A）和分区容错性（P）时，一致性（C）必然面临妥协。这种妥协在缓存层被进一步放大：缓存作为加速读写的“副本”，其更新时机、失效策略与数据库事务边界天然存在时间窗口。
核心矛盾：数据库保证持久化与事务隔离，缓存追求低延迟与高吞吐。两者对“数据正确性”的判定标准不同，导致同一份数据在两条路径上出现“裂缝”。
一致性问题的本质可以归纳为以下三类裂缝：
| 裂缝类型 | 产生原因 | 典型场景 |
|---|---|---|
| 时序裂缝 | 写数据库与写缓存非原子操作，中间存在时间窗口 | 先更新数据库，缓存删除失败；或先删缓存，数据库更新前有并发读 |
| 顺序裂缝 | 多个写请求并发到达，缓存与数据库接收顺序不一致 | 写请求 A 和 B 先后到达，但缓存先执行 B 后执行 A |
| 视图裂缝 | 不同节点或不同客户端看到的数据版本不同 | 主从延迟导致缓存从从库加载了旧数据 |
这三种裂缝并非独立存在，它们往往叠加出现，形成复杂的“一致性迷雾”。传统解决方案（如延迟双删、消息队列补偿）只能缓解症状，无法从根源上界定“哪些数据必须强一致，哪些可以最终一致”。
1.2 缓存与数据库的博弈：经典策略的困境
业界为解决一致性问题，演化出多种缓存策略。每种策略都在一致性强度、系统吞吐和实现复杂度之间做出取舍。下表对比了四种主流策略的博弈结果：
| 策略 | 操作顺序 | 一致性等级 | 吞吐影响 | 典型缺陷 |
|---|---|---|---|---|
| Cache-Aside（旁路缓存） | 读：先查缓存，miss 则查 DB 并回写；写：先写 DB，再删缓存 | 最终一致 | 低（删除操作轻量） | 删除缓存后到下次回写前存在空窗期，并发读可能读到旧 DB 数据 |
| Read-Through / Write-Through | 读写都通过缓存层代理 DB | 强一致（单节点） | 高（每次写都穿透） | 缓存层成为瓶颈，扩展性差 |
| Write-Behind（异步回写） | 先写缓存，异步批量写 DB | 弱一致 | 极低（异步合并） | 宕机时数据丢失风险高 |
| 延迟双删（Delayed Double Delete） | 写 DB → 删缓存 → 延迟 N ms → 再删缓存 | 最终一致（高概率） | 中等（额外延迟） | 延迟时间难以精确设定，极端并发仍可能不一致 |
博弈的代价：没有一种通用策略能同时满足“强一致”、“高吞吐”和“低复杂度”。传统方案试图用“一刀切”的策略覆盖所有数据，结果要么过度设计导致性能浪费，要么一致性漏洞频出。
更深层的困境在于：缓存与数据库的博弈本质上是“速度”与“准确”的对抗。缓存追求微秒级响应，数据库追求事务级可靠。当业务要求“既快又准”时，技术选型往往陷入两难——要么牺牲用户体验接受短暂不一致，要么牺牲性能等待同步完成。
1.3 领域建模的引入价值：从“技术策略”到“业务边界”
传统一致性方案之所以陷入困境，根源在于以技术为中心而非以业务为中心。工程师试图用统一的技术手段解决所有数据的一致性问题，忽略了不同业务数据对一致性的敏感度存在天然差异。
领域驱动设计（DDD）的核心思想——通过业务边界划分来管理复杂性——为缓存一致性提供了全新的解决视角。其引入价值体现在三个层面：
- 界定一致性边界：通过限界上下文（Bounded Context）将系统拆分为独立的业务领域。每个领域内部可以定义自己的“一致性契约”，明确哪些数据需要强一致，哪些可以最终一致。
- 分离读写关注点：利用聚合（Aggregate）和值对象（Value Object）的划分，识别出“高频读、低频写”的缓存友好型数据，以及“强一致要求高”的事务敏感型数据。
- 建立缓存策略与业务语义的映射：将缓存失效策略、更新时机与领域事件（Domain Event）绑定，使缓存操作不再是孤立的“技术动作”，而是业务流转的自然结果。
核心洞察：领域建模不是要消除缓存与数据库的不一致，而是帮助架构师精确回答“哪些不一致可以接受，哪些必须杜绝”。这种“边界意识”是设计高性价比一致性方案的前提。
下表展示了领域建模如何将一致性需求从“技术指标”转化为“业务决策”：
| 传统视角 | 领域建模视角 | 一致性策略影响 |
|---|---|---|
| 所有数据同等对待 | 按限界上下文划分数据主权 | 不同上下文采用不同缓存策略 |
| 缓存策略由性能驱动 | 缓存策略由业务规则驱动 | 强一致区域使用 Write-Through，弱一致区域使用 Cache-Aside |
| 一致性补偿靠事后修复 | 一致性边界在设计期定义 | 通过聚合边界防止不一致扩散 |
| 技术团队独立决策 | 业务专家与架构师共同决策 | 一致性等级成为业务需求的一部分 |