3. 缓存架构设计：本地缓存（L1）与分布式缓存（L2）分层架构
在云原生配置管理系统中，缓存是降低后端存储压力、提升配置读取响应速度的核心手段。单一缓存层往往无法同时满足极低延迟与高容量、高可用的需求，因此业界普遍采用 本地缓存（L1）与分布式缓存（L2）分层架构。本节将深入剖析该架构的设计原理、Key 规范与过期策略。
3.1 L1 + L2 分层缓存架构
分层缓存的核心思想是将热数据存储在应用进程内的本地缓存（L1），将全量或次热数据存储在跨进程共享的分布式缓存（L2）。读取时优先查询 L1，未命中则回源到 L2，L2 也未命中才回源到数据库或配置中心。
架构收益： L1 提供纳秒级访问延迟，消除网络开销；L2 提供高容量与数据一致性，减少对后端存储的穿透。两者结合可实现 P99 延迟 < 1ms 且命中率 > 99% 的目标。
3.2 缓存 Key 设计规范
Key 的设计直接影响缓存的命中率、可维护性与避免冲突。在配置管理场景下，推荐采用 命名空间 + 业务域 + 版本号 + 配置标识 的分层结构。
| 层级 | 示例 | 说明 |
|---|---|---|
| 命名空间 | cmdb |
区分不同系统或模块，避免 Key 冲突 |
| 业务域 | app_config |
标识配置所属的业务领域 |
| 版本号 | v2 |
配置版本，用于灰度发布与回滚 |
| 配置标识 | service_a:timeout |
唯一标识具体配置项 |
最佳实践： 最终 Key 格式为
cmdb:app_config:v2:service_a:timeout。L1 与 L2 使用相同的 Key 结构，便于回填与失效。避免使用可变长度或包含特殊字符的 Key，统一使用小写字母与下划线。
3.3 缓存过期策略
配置管理场景对数据一致性要求较高，过期策略需要平衡 时效性 与 命中率。推荐采用 主动失效 + 被动过期 + 后台刷新 的组合策略。
- 主动失效（Cache Invalidation）： 配置变更时，通过消息队列（如 Kafka、Redis Pub/Sub）广播失效通知，L1 和 L2 立即删除对应 Key。这是保证一致性的第一道防线。
- 被动过期（TTL）： 为每个 Key 设置合理的 TTL（如 60s ~ 300s），防止因广播丢失导致的数据不一致。L1 的 TTL 通常短于 L2，例如 L1 TTL = 60s，L2 TTL = 300s。
- 后台刷新（Refresh Ahead）： 在 TTL 过期前（如 TTL 的 1/3 时间），后台异步线程提前刷新缓存，避免高并发下大量请求同时回源导致“缓存雪崩”。
3.4 分层缓存对比与选型建议
| 维度 | L1 本地缓存 | L2 分布式缓存 |
|---|---|---|
| 延迟 | 纳秒级（进程内） | 毫秒级（网络 RTT） |
| 容量 | 受限于 JVM 堆内存（通常 < 1GB） | 可水平扩展至 TB 级 |
| 数据一致性 | 弱一致性（需主动失效） | 强一致性（Redis 主从同步） |
| 典型实现 | Caffeine、Guava Cache | Redis、Redis Cluster |
| 适用场景 | 高频读取、极少变更的配置 | 全量配置、跨进程共享、灰度发布 |
避坑指南： L1 缓存不要存储大对象（如超过 100KB 的配置），否则会频繁触发 GC 导致应用抖动。L2 缓存务必配置连接池与熔断机制，防止 Redis 故障时应用线程阻塞。Key 设计避免使用
* 通配符批量删除，改用 Redis SCAN 或按命名空间前缀逐条删除。