在数据库性能优化的漫长征程中，缓存始终扮演着 “救火队长” 的角色。然而，传统的 “在 SQL 前放置 Redis” 式缓存，往往治标不治本，它缓解了网络与磁盘 I/O 的压力，却可能将瓶颈转移至内存带宽与 CPU 缓存未命中。Cache Monet 项目的核心理念，正是对这一现状的深刻反思与革新。它并非另一个缓存中间件，而是一套旨在将数据库工作负载尽可能推入 CPU 缓存友好路径的系统性设计哲学，其灵感源于 MonetDB/X100 等向量化分析数据库，强调在缓存层次结构的每一级进行协同优化。
本文将聚焦于 Cache Monet 架构中最为关键的三层缓存设计，深入拆解其淘汰策略、内存布局与并发模式，并提供可直接应用于数据库 SELECT 查询 I/O 栈的工程化参数与实现要点。
一、 三层架构与混合淘汰策略：因层施策
Cache Monet 典型的三层缓存架构如下：
- L0 (线程 / 核心本地缓存)：容量最小，访问延迟极低，通常为每线程或每核心私有，用于存放极热的数据片段。
- L1 (进程级共享缓存)：容量较大，由进程内所有线程共享，存储热数据集，是避免访问 L2 的主要屏障。
- L2 (远程 / 磁盘 / 分布式缓存)：容量最大，访问延迟最高，作为最后一道防线，可能是另一个数据库实例、分布式缓存集群或持久化存储。
针对不同层级的访问模式与性能要求，应采用截然不同的淘汰策略，而非 “一招鲜吃遍天”。
1. L0：极简与低开销 L0 缓存追求极致的访问速度与零锁竞争。因此，复杂的 LRU 链表维护成本过高。推荐采用 Clock 算法或其变种（如 Segmented Clock）。每个缓存条目只需一个访问位（Reference Bit）。当需要淘汰时，指针像时钟一样扫描条目，清除访问位并跳过最近被访问过的条目（访问位为 1），直到找到访问位为 0 的条目进行替换。这种算法在 O (1) 时间复杂度下实现了近似的 LRU 效果，且数据结构紧凑，非常适合每线程独立的 L0。容量建议设定为每个线程 128 到 4096 个条目，具体取决于业务查询返回的结果集大小。
2. L1：平衡保护与效率 L1 作为共享缓存，需要抵御 “扫描污染”（一次性的全表扫描刷掉热数据）并识别真正的热数据集。Window TinyLFU (W-TinyLFU) 策略在此表现出色。它包含两部分：
- 准入过滤器 (Admission Filter)：使用一个紧凑的 Count-Min Sketch 近似统计频率。新条目仅在频率高于将被淘汰的 “受害者” 条目时，才被允许进入缓存。这有效过滤了偶然访问。
- 分段 LRU (SLRU) 存储：缓存内部划分为一个较小的 “受保护段”(Protected Segment) 和一个较大的 “试用段”(Probationary Segment)。新条目进入试用段，只有被再次访问才会晋升到受保护段。受保护段内的条目享受更长的存活时间，从而保护了热数据。 这种混合策略在有限的元数据开销下，提供了接近最优的命中率。
3. L2：持久化与成本感知 L2 缓存容量大、访问慢，淘汰策略需考虑数据持久性、访问频率甚至对象大小。LFU 结合 TTL (Time-To-Live) 是稳健的选择。LFU 识别长期热点，TTL 确保数据不会无限期陈旧。对于对象大小差异巨大的场景（如缓存查询结果），应采用基于价值的淘汰，例如计算 “频率 / 对象大小” 的比值，优先淘汰价值密度低的条目，以最大化缓存的空间利用率。
三层之间的淘汰操作应保持独立性。上层（如 L1）淘汰一个条目，并不意味着要从下层（L2）中删除它，因为下层可能仍持有该数据以供其他查询或未来重新加载。然而，可以考虑在 L1 淘汰时，向 L0 发送轻量的无效化通知（例如通过版本号或 epoch 机制），防止各线程的 L0 持有陈旧的引用，但这需要权衡通知带来的开销。
二、 内存布局优化：追求缓存友好性
缓存系统的性能不仅取决于算法，更取决于数据在内存中的组织方式。低效的布局会导致大量的缓存行浪费和伪共享问题。
1. 分离元数据与数据 将固定大小的元数据（哈希值、键长、值长、状态标志、访问频率 / 时间戳、下一个索引指针）存储在连续数组中。这种布局使得扫描、比较元数据的操作能充分利用 CPU 缓存预取。而变长的键和值数据则存储在另一块内存区域（Arena） 中，通过指针或偏移量关联。这种分离避免了因变长数据插入 / 删除导致的大块内存移动，也便于对元数据进行紧凑的缓存。
2. 哈希表结构选择 对于 L1 共享缓存的分片，哈希桶的设计至关重要。开放寻址法（如线性探测或罗宾汉哈希）将条目直接存放在一个大的连续数组中，访问模式高度本地化，对缓存极其友好。另一种方案是使用固定长度的链式桶数组，每个桶只包含少量（如 4 个）内联条目指针，溢出后再链接到外部节点。这避免了开放寻址下的长探测链，同时保持了主体数据的连续性。
3. 访问历史数据结构 淘汰算法所需的数据结构必须精心设计。例如，W-TinyLFU 所需的 Count-Min Sketch 可以用一个小的二维整数数组实现。SLRU 的分段可以使用侵入式双向链表，但链表节点应嵌入到上述的固定元数据槽中，而非额外分配，以减少指针追逐和内存分配开销。对于 Clock 算法，访问位可以直接编码在元数据的标志位中。
容量规划参数建议：
- L0：基于线程预期热工作集，例如，每个线程缓存最近 500 个主键查询的结果集 ID 列表。
- L1：总大小应为进程可用内存的 30%-50%，并设置软水位线（如 85%）触发后台异步淘汰，硬水位线（如 95%）触发同步淘汰，以平滑延迟毛刺。
- L2：根据持久化存储容量和成本设定，可采用分层配额管理不同业务线。
三、 并发模式：协调并行与一致
高并发下的线程安全是缓存系统必须跨越的鸿沟。Cache Monet 为不同层级设计了差异化的并发模型。
1. L0：线程本地，天下太平 最简单的并发策略就是没有并发。L0 被设计为线程本地存储 (Thread-Local Storage)。每个工作线程拥有自己独立的 L0 缓存副本，无需任何锁或原子操作。这带来了绝对的零竞争和极速访问。代价是可能的数据冗余和缓存重复，但对于纳秒级访问延迟的追求而言，这点内存开销是值得的。当线程因负载均衡发生迁移时，接受短暂的缓存冷启动即可。
2. L1：分片锁与乐观读取 L1 作为共享资源，必须处理并发。分片（Sharding） 是首要技术：将键空间通过哈希函数划分为 N 个独立的分片（例如 N=CPU 核心数 ×2）。每个分片管理自己的哈希表和淘汰数据结构，将全局竞争转化为分片内竞争。
对于分片内的同步，一种高效的模式是 “锁耦合” 的乐观读取：
- 读取路径：首先以原子方式读取条目的版本号或状态。然后读取数据。最后再次检查版本号是否变化。若未变化，则读取有效。若需要更新访问时间（如用于 LRU），可采用概率性更新（例如，仅 1/10 的读取会实际获取锁去更新），或者使用无锁的原子操作更新一个 “最近使用时间戳” 的近似值。
- 写入 / 淘汰路径：必须获取该分片的互斥锁。但得益于分片，锁的持有时间短且竞争域小。
后台可以运行一个或多个淘汰线程，定期扫描各分片，将冷数据异步移除，确保前端请求不会因同步淘汰而阻塞。
3. L2：异步化与请求合并 访问 L2 本质上是 I/O 操作，必须异步化以避免阻塞工作线程。所有对 L2 的读写都应封装为 Future/Promise 或回调形式。更重要的优化是请求合并（Request Coalescing）：当多个线程同时请求同一个缺失的键时，系统应只发起一个到 L2 的实际请求，并将这个正在进行的 Future 共享给所有等待者。这避免了 “缓存击穿” 导致的 L2 负载雪崩。
4. 与数据库查询栈的协同：向量化执行 Cache Monet 的精髓在于与数据库执行引擎的深度协同。现代分析型数据库的向量化执行模型与之完美契合。数据库执行器不再一次处理一行数据，而是以列式或批处理方式（每批 1024 到 65536 行）在紧密循环中操作。这种模式：
- 最大化指令缓存效率：循环体代码保持热状态。
- 优化数据缓存：连续访问批数据中的同一列，预取器高效工作，数据驻留在 L1/L2 缓存中的时间更长。
- 减少中间物化：算子间的中间结果可以设计为暂存在寄存器或 L1 缓存中的短生命周期向量，避免写回主内存。
在实现层面，这意味着数据库的扫描算子、过滤算子、聚合算子都需要围绕批处理接口重新设计。例如，一个扫描算子可以一次从缓冲池读入一个包含多个行指针的 “向量”，然后过滤算子对整个向量应用条件，生成一个选择位图，整个过程在缓存内流水线完成。
四、 工程落地清单与监控要点
将上述理论付诸实践，以下是一份可操作的清单：
- 度量先行：使用
perf工具或 eBPF 监控应用的关键指标：LLC（末级缓存）未命中率、数据库缓冲池命中率、各层缓存命中率、尾延迟（P99, P999）。 - 渐进实施：
- 首先实现分片的、带简单 LRU 的 L1 缓存和线程本地 L0。
- 接入真实负载，分析淘汰效果。若发现扫描污染，引入 W-TinyLFU 准入过滤器。
- 若对象大小差异大，在 L2 引入基于大小的淘汰权重。
- 最后优化并发细节，如实现乐观读取和请求合并。
- 参数调优：
- L0 大小：通过监控线程局部命中率调整，目标命中率 >95%。
- L1 分片数：设置为物理核心数的 2-4 倍，以平衡负载与锁粒度。
- 后台淘汰器唤醒间隔：根据写入速率设置，例如 100ms，在吞吐量和内存超用之间折衷。
- 失败与回滚策略：
- 为缓存组件设计降级开关，一旦出现严重 Bug 或性能回退，可快速切换回直连数据库模式。
- 实现影子缓存（Shadow Cache）机制，在新旧策略同时运行时对比命中率和延迟，确保新策略有效才全量切换。
结语
Cache Monet 所代表的三层缓存优化思想，本质上是一场从 “粗放式缓存” 到 “精细化缓存计算” 的范式转移。它要求开发者深入理解从 CPU 寄存器到分布式存储的整个 I/O 栈。通过为不同层级量身定制淘汰策略、精心设计缓存友好的内存布局、并采用分而治之的并发模型，我们能够显著降低数据库查询的延迟与资源消耗。更重要的是，将向量化执行与缓存层次结构对齐，使得大量计算得以在 CPU 高速缓存中完成，真正释放了现代硬件的潜力。这条路虽复杂，但对于追求极致性能的系统而言，无疑是值得深入探索的方向。
参考资料
- MonetDB/X100: A DBMS In The CPU Cache. CWI (Centrum Wiskunde & Informatica).
- “Caching is an abstraction, not an optimization.” Hacker News discussion.