4. 网关缓存架构：缓存层在网关中的位置与多级缓存设计
在 OpenAPI 网关中引入缓存层，核心目标是降低后端 DB 的查询压力、缩短 API 响应延迟，同时为后续的“缓存与 DB 一致性校验”提供数据锚点。本章聚焦缓存层在网关架构中的物理位置、职责边界，以及本地缓存与分布式缓存协同工作的多级设计模式。
4.1 缓存层在网关中的位置
网关的请求处理流水线通常包含：协议解析 → 路由匹配 → 鉴权限流 → 缓存查询 → 后端转发 → 响应缓存回写。缓存层位于鉴权之后、后端调用之前，是请求的“快速路径”决策点。
关键位置原则：缓存层必须处于路由与负载均衡之间，且具备短路能力——当缓存命中时，直接返回响应，不再发起后端调用。
以下架构图展示了缓存层在网关流水线中的具体位置：
架构要点：缓存查询节点必须支持“读穿透”与“写旁路”两种模式。读穿透：缓存未命中时，由网关负责加载数据并回填缓存；写旁路：写请求直接更新 DB，同时失效或更新缓存，避免缓存与 DB 数据不一致。
4.2 多级缓存设计：本地缓存 + 分布式缓存
单一缓存层难以同时满足极低延迟与高容量扩展的需求。业界普遍采用本地缓存（L1）与分布式缓存（L2）组合的多级架构，在网关节点内部和集群层面形成缓存协同。
| 缓存层级 | 存储位置 | 访问延迟 | 容量 | 典型实现 | 适用场景 |
|---|---|---|---|---|---|
| L1 本地缓存 | 网关进程内堆内存 | < 1 ms | 小（MB ~ GB） | Caffeine、Guava Cache | 热点数据、频繁访问的配置/路由 |
| L2 分布式缓存 | 独立缓存集群 | 1 ~ 5 ms | 大（GB ~ TB） | Redis、Redis Cluster | 全量缓存、跨网关节点共享数据 |
多级缓存的核心流程遵循“L1 → L2 → DB”的逐级回退模式：
- 请求到达：网关首先查询 L1 本地缓存。
- L1 命中：直接返回，延迟最低，不产生网络开销。
- L1 未命中：查询 L2 分布式缓存。
- L2 命中：回填 L1 并返回，同时设置 L1 的 TTL（通常短于 L2）。
- L2 未命中：穿透到后端 DB 查询，回填 L2 和 L1，返回响应。
以下多级缓存架构图展示了 L1 与 L2 的协同关系：
4.3 多级缓存的关键设计参数
在实际落地时，以下参数直接影响缓存命中率与一致性：
| 参数 | L1 本地缓存 | L2 分布式缓存 | 推荐策略 |
|---|---|---|---|
| 最大容量 | 单节点 512 MB ~ 2 GB | 集群 10 GB ~ 1 TB | L1 按节点内存 10% 上限配置 |
| TTL | 30 ~ 120 秒 | 300 ~ 900 秒 | L1 TTL < L2 TTL，避免 L1 长期持有脏数据 |
| 淘汰策略 | W-TinyLFU / LRU | LRU / LFU / TTL | L1 使用 Caffeine 的 W-TinyLFU 抗热点 |
| 序列化 | Java 对象引用（无需序列化） | Protobuf / JSON / Hessian | L2 优先使用 Protobuf 降低带宽 |
常见陷阱：L1 缓存容量设置过大（超过节点堆内存 20%）会引发 GC 压力，导致网关整体延迟抖动。建议 L1 容量控制在堆内存的 5%~10%，并配合 JVM 参数 -XX:MaxGCPauseMillis=50 进行调优。
4.4 缓存一致性保障机制
多级缓存引入了一致性挑战：L1 与 L2 之间、缓存与 DB 之间都可能出现数据偏差。网关层需要建立以下机制：
- 主动失效：写请求到达时，网关先更新 DB，然后广播失效消息（通过 Redis Pub/Sub 或消息队列），所有网关节点监听后清除对应 L1 缓存。
- TTL 过期兜底：即使失效消息丢失，L1 的短 TTL 也能在数十秒内自动恢复一致性。
- 版本号校验：缓存中携带数据版本号（如 DB 行记录的更新时间戳），每次读取时校验版本，版本不一致时重新加载。
- 写回延迟：对于非关键数据，允许 L2 缓存异步写回 DB，但需配合“最终一致性”的业务承诺。
推荐组合：“主动失效 + 短 TTL”是网关多级缓存最实用的保底方案。主动失效保证秒级一致性，短 TTL 作为最后一道防线，防止因消息丢失导致的数据永久不一致。
4.5 多级缓存性能指标参考
以下为生产环境实测的典型性能数据（基于 8 核 16G 网关节点，QPS 10 万）：
| 指标 | 仅 L2 缓存 | L1 + L2 多级缓存 | 提升幅度 |
|---|---|---|---|
| P50 延迟 | 3.2 ms | 0.8 ms | ↓ 75% |
| P99 延迟 | 12.5 ms | 4.1 ms | ↓ 67% |
| 后端 DB QPS | 8,000 | 1,200 | ↓ 85% |
| Redis 集群 QPS | 100,000 | 25,000 | ↓ 75% |
实践建议：在引入多级缓存初期，先通过监控确认 L1 命中率是否达到 70% 以上。若 L1 命中率低于 50%，说明热点数据识别不准确，应调整缓存 key 的设计或增大 L1 容量。