1. 离线缓存总体架构分层原理
离线缓存的架构设计必须回答三个核心问题：数据从哪来、存在哪、怎么管。分层架构通过职责划分、依赖倒置和隔离原则，将系统拆解为可独立演进、可替换的模块。本章定义离线缓存架构的四层核心分层模型，明确每层的边界与组件职责，并描述数据流、控制流与信任链路，最后给出落地方案与验收标准。
核心定义：分层架构是一种将系统按职责横切为若干“层”，上层依赖下层抽象、下层向上层暴露契约的结构模式。离线缓存架构采用接入层 → 缓存层 → 持久层 → 治理层的四层拓扑。
1.1 核心分层与模块边界
| 层次 | 名称 | 模块边界 | 核心组件 |
|---|---|---|---|
| L1 | 接入层 | 负责客户端请求接入、协议转换、认证与限流；不存储数据，仅做路由与预处理。 | 网关、反向代理、SDK 客户端、连接管理器 |
| L2 | 缓存层 | 分布式缓存集群，包含内存级缓存与近线缓存；负责热点数据加速与离线数据暂存。 | Redis Cluster / Memcached、本地缓存 (e.g. Caffeine)、分布式一致性存储 (e.g. etcd) |
| L3 | 持久层 | 冷存储与持久化底座：保存所有离线数据的主副本，支持按需回刷缓存。 | RDBMS (MySQL/PostgreSQL)、对象存储 (S3/MinIO)、HDFS、LSM-Tree 引擎 |
| L4 | 治理层 | 横切关注点的集中管控：配置下发、监控告警、故障迁移、缓存预热/清理策略。 | 配置中心 (Apollo/Nacos)、监控系统 (Prometheus+Grafana)、调度器 (K8s CronJob) |
边界隔离原则：每层只通过抽象接口（或标准协议）交互，严禁跨层直接调用。例如，缓存层不应感知持久层的具体数据库类型，接入层不应操作缓存键。
1.2 数据流方向与控制流方向
数据流：写请求通路为 客户端 → 接入层 → 缓存层 → 持久层，读请求通路为 客户端 → 接入层 → 缓存层（命中则返回）→ 持久层（未命中时回刷）。离线场景下，缓存层与持久层之间的批量数据同步走异步管道（如 Kafka 或 Debezium CDC）。
控制流：治理层向下驱动各层的行为变更，包括缓存容量伸缩、过期策略调整、故障恢复流程。信任链路基于 + 双向 TLS，治理层拥有最高权限，接入层与缓存层之间使用服务网格做流量整形。
风险警示：控制流必须与数据流物理隔离，防止治理操作（如全量预热）阻塞正常读写链路。推荐使用独立线程池或专用连接池。
1.3 全局缓存拓扑
离线缓存拓扑通常采用“本地缓存 + 分布式缓存 + 持久化层”的三级结构。下图展示四层架构及主要数据流向：
1.4 分层隔离原则与信任链路
- 依赖倒置：上层定义接口，下层实现；缓存层不直接调用持久层数据库驱动，而是通过 Repository 抽象。
- 有限信任：接入层只信任缓存层返回的数据签名，缓存层信任持久层的主副本，治理层拥有跨层访问凭证。
- 舱壁隔离：每层独立部署、独立故障域，缓存层崩溃不导致持久层雪崩，治理层故障不影响已有缓存命中。
- 防缓存穿透：缓存层与持久层之间增加布隆过滤器或空值缓存，控制流禁止直接透传请求。
1.5 选型权衡与风险点
| 维度 | 选型权衡 | 风险点 |
|---|---|---|
| 缓存层一致性 | 强一致性 (CP) vs. 最终一致性 (AP) | 脑裂 / 数据脏读 |
| 持久层选型 | 关系型 vs. 对象存储 vs. 列式存储 | 离线批量吞吐瓶颈 |
| 治理层调度 | 中心化配置 vs. 分布式协调 | 配置下发延迟导致缓存失效风暴 |
| 接入层协议 | HTTP/2 vs. gRPC vs. 专有协议 | 协议转换开销 / 连接数浪费 |
核心风险：若未实现分层隔离，缓存层与持久层共用连接池或线程池，一次持久层慢查询会拖垮整个缓存吞吐，导致级联雪崩。
1.6 落地步骤与验收标准
步骤：
- 定义接口契约：明确每层对外暴露的 API 与数据格式（Protobuf / Avro）。
- 搭建治理层底座：部署配置中心与监控系统，确保可观测性到位。
- 实现持久层适配器：封装数据读取、批量导入、增量同步接口。
- 构建缓存层集群：选择一致性哈希分区，配置失效时间与淘汰策略。
- 对接接入层限流路由：实现请求级熔断、降级、重试。
- 集成测试与混沌工程：验证单层故障不影响其他层。
验收标准：
- 各层可独立升级、重启不影响上下游（隔离验证）。
- 写链路：数据在 500ms 内写入持久层并异步刷新缓存层。
- 读链路：缓存命中率 > 95%，未命中回源延迟 < 20ms。
- 控制流操作（如全量预热）不阻塞数据流，响应时间波动 < 5%。
落地建议：初期可先合并缓存层与持久层为简单两层，待流量增长后逐步拆分。始终保留治理层监控，避免盲目分层过早优化。