📚 课程目录第2章本地存储层次设计

2. 本地存储层次设计：内存缓存、持久化缓存、混合缓存的分层职责与数据流转

离线缓存设计中，“分层”是控制复杂度、平衡性能与持久性的核心手段。本章界定三层缓存的边界，明确各层组件职责，并描述数据在层间的流转路径、控制信号以及信任假设。任何缺少分层边界的缓存设计都会在后续扩展中暴露一致性与资源竞争问题。

三个层次不是孤立存在的：L1 是 L2 的“热区加速层”，L2 是 L3 的“持久底座”，L3 则是前两层的统一调度器。离线场景下，L1 与 L2 之间的数据流动由应用代码显式控制，而非操作系统缺页中断。

离线缓存通常采用三层结构，但在嵌入式系统或轻量场景可合并为两层（L1+L2 直连）。以下描述标准三层参考架构。

内存缓存层（L1）：运行在应用进程内，使用 LRU/LFU/TTL 驱逐算法。典型实现：Guava Cache、Caffeine、本地HashMap+并发锁。
持久化缓存层（L2）：运行在磁盘上，通过嵌入式数据库（SQLite、LevelDB、RocksDB）或自定义文件格式提供服务。支持索引、批量写入、崩溃恢复。
混合管理层（L3）：协调 L1 与 L2 的读写。负责“写回”或“写通”策略的选择、缓存预热、逐出数据降级到 L2、从 L2 按需加载到 L1。

分层原则：下层不应依赖上层实现细节。L2 只提供键值存取与范围查询接口；L1 只负责快速存取；L3 决定何时在层间移动数据。

组件	职责	典型实现	关键接口
L1 Store	热键快速访问，驱逐过期的冷键	Caffeine Cache	get(key), put(key, value), invalidate(key)
L2 Store	全量持久化，支持事务或批量原子写入	RocksDB	read(key), write(key, value), delete(key), iterator(range)
Eviction Controller	监控 L1 容量，触发驱逐，将冷数据写入 L2	定时/异步轮询 + 回调	onEvict(key, value) → L2.write()
Load Controller	L1 miss 时从 L2 加载，并更新 L1	CacheLoader 模式	load(key) → L2.read() → L1.put()
Consistency Guardian	维护 L1/L2 间的数据版本或时间戳，防止脏读	版本号 / 写时复制位图	validate(key, version)

以一次典型的“读流程”为例，描述数据在层间的转移：

应用调用 get(key) → 到达 L3 混合层。
L3 先查询 L1 Store：若命中且未过期，直接返回（热读路径）。
若 L1 miss，L3 委托 Load Controller 查询 L2 Store：若命中，则 Load Controller 将数据放入 L1（更新 L1 并重置 TTL），再返回给应用（温读路径）。
若 L2 也未命中，则视为缓存整体 miss，需要回源到远程后端（离线场景下通常是本地预下载的压缩包或远程存储），然后将结果同时写入 L2 和 L1（冷加载路径）。

写流程则涉及“写回”与“写通”两种模式：

写通（Write-Through）：应用写 L1 的同时，由 L3 同步写入 L2，保证两层数据实时一致。延迟较高，但适合对持久化要求严格的场景。
写回（Write-Back）：应用只写 L1，L3 异步将变更刷入 L2。吞吐高，但窗口期内若进程崩溃会丢失数据。离线场景常用写回策略配合周期性 checkpoint。

离线场景推荐：大部分场景采用“写通”控风险，仅在纯只读离线数据（如地图瓦片、预计算特征）中使用“写回”预热。不建议混合使用两种模式，否则调试一致性问题代价极高。

层间信任：L3 完全信任 L1 和 L2 返回的数据格式（不校验校验和）。这一假设在离线环境中成立，因为数据由应用自身写入且不经过外部网络。
过期信任：L1 的 TTL 机制假定时钟在离线环境内单调递增（可容忍 NTP 漂移）。若设备系统时间被恶意修改，L1 可能误判过期，导致加载延迟上升，但不会产生数据损坏。
崩溃信任：L2 的磁盘写入应具备原子性（如 SQLite 的 WAL 模式、RocksDB 的 WAL）。若 L2 本身不支持崩溃安全，则 L3 必须通过预写日志（Write-Ahead Log）自己维护一致性。

场景	L1 推荐	L2 推荐	L3 策略	原因
只读大数据（>10GB）	直接映射文件（mmap）	RocksDB + 压缩	按需加载，无写回	避免堆外内存占用，利用操作系统 page cache
频繁读写小数据（<100MB）	Caffeine（heap）	SQLite（WAL）	写通	一致性要求高，吞吐不是瓶颈
嵌入式/低内存设备	手动管理环形缓冲区	LevelDB（精简编译）	写回 + 定期同步	减少写放大，控制内存占用

L1 污染：一次全范围扫描导致 L1 热数据被批量淘汰，后续读全部穿透到 L2。需引入准入策略（size-based eviction 或 maximumWeight）。
L2 写放大：LevelDB/RocksDB 的 Compaction 可能产生数倍于写入量的磁盘 I/O。离线场景下若写入不均匀，需优化 Compaction 触发间隔。
层间死锁：L3 同时持有 L1 和 L2 的锁时，可能造成循环等待。解法：L3 使用非阻塞读（tryLock）或固定加锁顺序（先 L1 后 L2）。
预热风暴：应用重启后 L1 为空，大量请求同时穿透 L2。需设计预热流程（从 L2 批量加载 top-N 热点键）。

定义键的类型与序列化：统一使用 Protobuf / FlatBuffers，减少 L1 到 L2 的转换开销。
选择 L2 数据库：按容量、写入模式、崩溃恢复需求决策（参考 2.6 选型表）。
实现 L3 策略类：抽象 CacheManager 接口，暴露 get(key)、put(key, value, ttl)、delete(key)，内部封装 L1 与 L2 的调用。
集成 Eviction Listener：为 L1 设置 evictionListener，将逐出键写入 L2 的异步队列。
增加 Consistency Guardian：可选开启版本号校验（适用于 L1 和 L2 可能被外部修改的场景）。
压力测试与热加载验证：模拟 L1 miss、L2 miss、并发读写、进程崩溃重启等场景。