4. 一致性模型：强一致性、最终一致性、读写一致性、因果一致性在缓存场景下的适用性分析

在分布式缓存与数据库构成的混合存储体系中，一致性模型决定了系统在并发读写、节点故障、网络分区等场景下对外呈现的数据状态。选择错误的一致性模型会导致缓存与数据库长期不一致，或引入不可接受的延迟。本章对四种核心一致性模型在缓存场景下的适用性进行结构化分析。

4.1 一致性模型全景对比

下表从核心定义、典型实现、缓存场景代价三个维度对四种模型进行横向对比：

4.2 强一致性：适用场景与缓存陷阱

强一致性要求缓存与数据库在任何时刻对外呈现完全一致的状态。在缓存场景中，通常通过 同步双写 或 分布式事务（如 2PC） 实现。

• 适用场景： 金融交易、库存扣减、配置中心等不允许任何数据偏差的核心链路。
• 缓存陷阱：
  • 写入延迟大幅增加：每次写操作需等待缓存与数据库均确认成功。
  • 可用性降低：缓存节点故障直接阻塞写入链路。
  • 缓存击穿风险：强一致性通常配合“先写库再删缓存”模式，高并发下删缓存失败会导致长时间不一致。

4.3 最终一致性：高吞吐的代价

最终一致性是缓存场景中最常用的模型。它允许短暂的不一致窗口，通过异步机制（如消息队列、Binlog 监听、定时补偿）将缓存最终对齐到数据库状态。

• 适用场景： 用户资料、商品详情、内容 Feed 流等对实时性要求不高的读多写少场景。
• 不一致窗口控制：
  • TTL 过期：设置合理的缓存过期时间（如 5 分钟），强制刷新。
  • 延迟双删：写库后先删缓存，延迟几百毫秒再删一次，降低并发写导致的脏数据概率。
  • 版本号比对：缓存中存储数据版本号，读取时与数据库版本对比，不一致则回源。

以下 SVG 展示了最终一致性模型下缓存与数据库的异步同步流程：

4.4 读写一致性：用户维度的“自洽”

读写一致性（Read-Your-Writes Consistency）保证：写入者本人 在写入后立即读取时，一定能看到自己写入的最新值；其他用户可能仍看到旧值。这是用户体验与系统吞吐之间的折中方案。

• 实现策略：
  1. Session 级缓存： 用户写入后，将最新数据写入 Session 本地缓存，优先从 Session 读取。
  2. 写后读路由： 写入时记录用户 ID 与时间戳，读取时强制从主库或最新缓存分片读取。
  3. 本地版本戳： 客户端携带本地版本号，服务端根据版本号决定是否回源。
• 适用场景： 用户个人设置、购物车、草稿箱等“谁写谁读”的业务。
• 缓存场景优势： 不需要全局强一致，仅维护用户级上下文，实现成本远低于强一致性。

4.5 因果一致性：分布式复杂场景的平衡点

因果一致性要求：如果操作 A 在因果顺序上先于操作 B，那么所有节点必须先看到 A 的结果，再看到 B 的结果。它比最终一致性更强，但比强一致性更灵活。

• 核心机制： 使用向量时钟或版本向量追踪操作的因果依赖关系，确保因果相关的操作按序生效。
• 适用场景：
  • 社交 Feed：用户发帖（A）与评论（B），评论必须在帖子之后可见。
  • 协作编辑：文档的多个修改版本需要保持因果顺序。
  • 多级缓存级联：上游缓存更新必须在下游缓存之前完成。
• 缓存场景挑战：
  • 元数据膨胀：每个缓存 key 需携带版本向量，存储开销随节点数线性增长。
  • 时钟同步：依赖可靠的时钟或逻辑时钟，在 Development 环境中容易因时钟漂移导致因果序错乱。

以下 SVG 展示了因果一致性在缓存场景中的操作顺序约束：

4.6 模型选择决策矩阵

在 Development 环境的缓存一致性闭环中，建议根据以下条件选择一致性模型：