2. 缓存一致性治理的总体架构：分层缓存架构、一致性治理的四个核心原则

在微服务与 OpenAPI 网关共存的架构中，缓存并非单一组件，而是一套贯穿数据访问路径的分层体系。每一层缓存都有其特定的生命周期、失效策略与一致性诉求。治理的核心不在于消除缓存，而在于在分层架构中建立可预测的一致性边界。

2.1 分层缓存架构

从客户端请求到数据库持久层，缓存通常分布在以下四个层级。每一层对一致性的容忍度与治理手段各不相同。

2.2 一致性治理的四个核心原则

在分层缓存架构中，不存在“一刀切”的一致性方案。我们需要根据业务场景，在最终一致性、强一致性、读写分离与失效传播四个原则之间做出选择与组合。

2.2.1 最终一致性

适用于对实时性要求不高的读场景（如用户资料、商品详情）。允许缓存数据在短时间内与数据库不一致，但保证在可接受的时间窗口内（通常为秒级）达到一致。

• 实现方式：TTL 过期 + 异步刷新。
• 典型场景：首页推荐列表、非关键配置。
• 治理指标：定义“不一致窗口”上限（如 5 秒）。

2.2.2 强一致性

适用于对数据准确性有严格要求的场景（如库存、余额、订单状态）。要求缓存数据与数据库实时同步，任何写入操作后，后续读取必须看到最新值。

• 实现方式：缓存更新 + 分布式锁（如 Redisson）或 2PC 事务。
• 典型场景：秒杀库存扣减、支付状态查询。
• 治理指标：缓存与数据库的“读写延迟”趋近于零。

2.2.3 读写分离

将缓存分为读缓存与写缓存两条路径。读缓存使用最终一致性，写缓存使用强一致性，通过缓存旁路（Cache-Aside）或读写穿透（Read/Write-Through）模式实现。

• 读路径：先查缓存，命中则返回；未命中则查数据库并回填缓存。
• 写路径：先更新数据库，再删除或更新缓存（推荐“先删缓存后写库”或“延迟双删”）。
• 治理重点：避免“写后读”读到旧缓存（脏读）。

2.2.4 失效传播

当底层数据发生变更时，需要将失效信号从数据源向上传播到所有缓存层级。失效传播的及时性与完整性直接决定一致性治理的成败。

• 传播机制：消息队列（如 Kafka / RabbitMQ）广播失效事件、Redis Pub/Sub、WebSocket 推送。
• 传播路径：L4（分布式缓存）→ L3（应用本地缓存）→ L2（网关/CDN）→ L1（客户端）。
• 治理指标：失效传播延迟（P99 < 100ms）、失效覆盖率（100% 相关缓存键）。

2.3 原则组合策略

在实际的 OpenAPI 接口治理中，四个原则并非互斥，而是根据接口语义进行组合。以下为典型组合模式：