3. 缓存一致性定义：从强到弱的模型体系

在分布式系统与 OpenAPI 网关、微服务架构中，缓存一致性 是指缓存中的数据副本与后端数据源（数据库、上游服务）之间的数据同步程度。当数据发生更新时，不同节点、不同缓存层能否在预期时间内看到相同的数据，决定了系统对外提供的语义保证。

理解缓存一致性，首先需要区分两个核心维度：

• 时间维度：更新操作发生后，多久才能让所有读取者看到新值。
• 顺序维度：多个并发更新操作，所有观察者看到的执行顺序是否一致。

根据这两个维度的约束强弱，业界将缓存一致性模型划分为以下四种主要类型：

3.1 强一致性（Strong Consistency）

强一致性要求缓存系统表现得像单副本系统：一旦写入操作确认完成，所有后续的读取操作（无论从哪个节点、哪个缓存层发起）都必须返回该最新值。在分布式缓存中，这通常意味着：

• 写入操作必须同步更新所有副本，或使用分布式共识协议（如 Paxos、Raft）确认。
• 读取操作必须从主副本或达成共识的多数副本中获取数据。
• 任何未同步完成的副本不能对外提供读取服务。

在 OpenAPI 场景中，强一致性常用于：

• 库存扣减接口：缓存中的库存数量必须与数据库严格一致，超卖不可接受。
• 分布式锁缓存：锁状态的读取必须准确反映当前持有者。
• 支付状态查询：用户支付成功后，后续查询必须立即显示“已支付”。

3.2 弱一致性（Weak Consistency）

弱一致性是约束最宽松的模型：写入操作成功后，系统不承诺后续读取何时能看到新值。读取可能返回旧值、过期值，甚至不一致的值。系统只保证数据最终会收敛，但收敛时间不确定。

弱一致性的典型特征：

• 写入操作只需写入一个副本即可返回成功。
• 副本之间的同步是异步的、后台进行的。
• 读取操作不检查副本版本，直接返回本地缓存数据。

适用场景：

• 用户头像、昵称等非关键元数据。
• 静态资源版本号、前端配置。
• 日志收集、监控指标等允许丢失或延迟的数据。

3.3 最终一致性（Eventual Consistency）

最终一致性是弱一致性的一个重要子集，它增加了收敛保证：如果系统在一段时间内没有新的写入操作，那么所有副本最终会达到一致状态。最终一致性是分布式系统中最常用的模型，因为它提供了可预测的收敛行为，同时保持了高可用性和低延迟。

最终一致性的关键特性：

• 收敛保证：存在一个时间窗口 T，超过 T 后所有副本一致。
• 无顺序保证：不同节点可能以不同顺序看到更新。
• 冲突可能：并发写入可能导致冲突，需要冲突解决策略（如 LWW、CRDT）。

在 OpenAPI 缓存场景中，最终一致性广泛用于：

• CDN 缓存：源站更新后，CDN 节点逐步刷新。
• Redis 主从复制：主节点写入后，从节点异步同步。
• 本地缓存 + 分布式缓存：本地缓存通过 TTL 或消息队列异步更新。

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

读写一致性（也称“写后读一致性”）是一种以用户为中心的一致性模型。它保证：写入者本人在写入操作成功后，后续的读取操作一定能看到自己写入的最新值；但其他用户可能仍然看到旧值。

这种模型在 OpenAPI 场景中非常实用，因为它：

• 对调用方自身提供“所见即所得”的体验。
• 允许其他用户或服务读取过期数据，降低系统同步压力。
• 实现成本较低，通常只需在缓存中记录写入者标识或会话上下文。

典型实现方式：

• 会话级缓存：用户写入后，将最新值写入用户专属缓存分区。
• 版本戳：写入时返回版本号，读取时携带版本号，缓存返回匹配版本的数据。
• 本地优先：写入者优先从本地缓存读取，本地缓存实时更新。

3.5 一致性模型的选择策略

在实际的 OpenAPI 网关与微服务架构中，通常不会全局使用同一种一致性模型。合理的策略是按接口语义分级：

3.6 一致性模型在 OpenAPI 缓存中的落地要点

在 OpenAPI 网关与微服务缓存架构中，落地一致性模型时需注意以下关键点：

1. 接口文档显式声明：在 OpenAPI 规范中，通过 x-cache-consistency 扩展字段标注每个接口的一致性级别，方便客户端和服务端对齐预期。
2. 缓存键设计：读写一致性场景下，缓存键应包含用户标识或会话 ID，避免不同用户的数据混淆。
3. 失效策略配合：强一致性通常配合“写入即失效”策略；最终一致性配合 TTL 或异步刷新策略。
4. 监控与告警：对强一致性接口增加延迟和一致性校验监控，及时发现同步异常。