3、缓存一致性定义：强一致性、弱一致性、最终一致性、读写一致性场景分析

在分布式系统与缓存架构中，“一致性”是决定数据正确性与系统可用性的核心权衡点。不同业务场景对一致性的容忍度截然不同，理解并正确选择一致性模型，是设计缓存方案的前提。本章从定义出发，逐一剖析四种核心一致性模型及其适用场景。

3.1 一致性模型全景对比

下表从核心定义、典型延迟、实现代价与适用业务四个维度，对四种一致性模型进行横向对比：

3.2 强一致性（Strong Consistency）

强一致性要求缓存与数据源之间保持“线性一致性”（Linearizability）。写入操作完成后，所有后续读取操作（无论从哪个节点）都必须返回最新写入的值。在缓存场景中，这意味着：

• 写后读严格有序： 更新数据库后，缓存必须同步更新或立即失效，且后续读请求必须命中最新数据。
• 全局串行化： 所有节点对同一数据的操作顺序达成共识，不存在“读到旧值”的时间窗口。
• 实现手段： 分布式锁（如 Redis RedLock）、两阶段提交（2PC）、Paxos/Raft 共识算法。

3.3 弱一致性（Weak Consistency）

弱一致性是约束最宽松的模型。它只保证“数据最终会收敛”，但不提供任何关于何时收敛的时间承诺。在缓存架构中，弱一致性通常表现为：

• 异步写回： 更新数据库后，缓存更新通过异步消息队列或定时任务执行，不阻塞主流程。
• 无读校验： 读取缓存时不做任何版本或时间戳校验，直接返回缓存值。
• 适用边界： 对实时性无要求、允许短暂数据偏差的业务，如文章阅读计数、非关键统计报表。

弱一致性的核心优势在于极低的写入延迟和高吞吐，但代价是业务必须容忍“读到过期数据”的窗口期。

3.4 最终一致性（Eventual Consistency）

最终一致性是弱一致性的一个特例，它增加了“在没有新更新的情况下，所有副本最终会达到一致状态”的保证。这是分布式缓存中最常见的一致性模型，DNS 系统和 CDN 是其经典代表。

最终一致性的关键特征：

• 收敛保证： 系统保证在无新写入后，经过足够时间，所有副本数据一致。
• 冲突处理： 需要定义冲突解决策略（如最后写入者获胜 LWW、版本向量、CRDT）。
• 时间窗口： 不一致窗口的大小取决于复制延迟、网络状况和冲突检测算法。

3.5 读写一致性（Read-Your-Writes Consistency）

读写一致性（也称“读己之写一致性”）是一种折中模型：它保证写入者自己能够立即看到自己的写入，但其他用户可能仍然读到旧值。这种模型在用户体验层面非常实用——用户编辑个人资料后，期望刷新页面立即看到更新，而其他用户看到旧资料是可以接受的。

实现读写一致性的常见策略：

• 会话粘滞（Session Stickiness）： 将同一用户的请求始终路由到同一缓存节点，该节点持有用户的最新数据。
• 本地写缓存： 写入操作同时更新本地 ThreadLocal 或请求上下文缓存，后续读取优先从本地获取。
• 版本号校验： 写入时生成递增版本号，读取时携带用户会话中的版本号，缓存节点返回不低于该版本的数据。

3.6 一致性模型选择决策流程

以下 SVG 图展示了在 Spring Boot 缓存架构中，如何根据业务需求选择合适的一致性模型：

3.7 场景案例分析

以下通过四个典型业务场景，展示不同一致性模型的实际应用：

3.8 一致性模型与 CAP 定理的关系

缓存一致性模型的选择本质上是 CAP 定理在数据层的外化表现。以下 SVG 图展示了三种一致性模型在 CAP 空间中的位置：

3.9 总结：一致性模型选择矩阵

在实际的 Spring Boot 缓存架构设计中，一致性模型的选择应遵循以下矩阵：