s2-streamstore 如何结合 LRU 与 TTL 策略实现高效缓存淘汰

在现代大规模数据处理架构中，对象存储（如 S3）因其高可用性和低成本而被广泛采用，但其固有的网络延迟和尾部延迟问题，使得直接访问往往成为性能瓶颈。为了解决这一问题，s2-streamstore 团队开源了 cachey —— 一个专为对象存储设计的高性能读穿透缓存。它不仅通过 16MiB 页面对齐和请求合并优化了 I/O，更关键的是，其底层依赖的 foyer 缓存库，提供了一套强大且灵活的混合淘汰机制，巧妙地融合了 LRU（最近最少使用）和 TTL（生存时间）策略，实现了缓存空间的高效利用与冷热数据的智能分层。

cachey 本身是一个应用层缓存服务，其核心淘汰逻辑并非自行实现，而是委托给了其存储引擎——foyer-rs/foyer。foyer 是一个用 Rust 编写的高性能混合内存与磁盘缓存库，其设计目标之一就是提供“即插即用”的可替换缓存算法。默认情况下，foyer 采用 LRU 作为其内存层的淘汰策略，这在 HybridCacheBuilder 的示例配置中清晰可见（.with_eviction_config(LruConfig {...})）。LRU 策略的核心思想是优先淘汰最久未被访问的数据，这对于处理具有时间局部性的访问模式（即最近访问过的数据很可能再次被访问）非常有效。在 cachey 的场景中，这意味着频繁被请求的视频片段、热门文件的页面会被保留在高速的内存缓存中，从而确保低延迟响应。

然而，仅靠 LRU 并不足以应对所有场景。对象存储中的数据往往是不可变的（immutable blobs），但其热度会随时间衰减。一个上周发布的热门视频，其访问频率可能在几天后急剧下降。如果仅依赖 LRU，这些“过气”的冷数据可能会因为偶尔被访问一次而长期占据宝贵的缓存空间，导致真正需要缓存的新热点数据无法进入。这时，TTL 策略就成为了完美的补充。虽然 cachey 的公开文档没有直接暴露 TTL 配置接口，但 foyer 的架构天然支持 TTL 语义。在 foyer 中，可以通过为缓存项附加一个过期时间戳来实现 TTL。当一个缓存项被访问时，系统会首先检查其是否已过期，若已过期则视为缓存未命中并触发淘汰。这种机制确保了数据拥有一个明确的生命周期，无论其访问频率如何，一旦超过预设的生存时间，就会被自动清理，从而为新数据腾出空间。这种设计特别适合于内容有明确时效性的场景，例如新闻、限时活动资源或临时生成的中间文件。

将 LRU 与 TTL 结合，cachey 实现了一种“双重保险”的智能淘汰机制。LRU 负责在缓存空间紧张时，根据访问热度进行动态调整，保证最活跃的数据常驻内存；TTL 则从时间维度进行宏观调控，强制清理生命周期结束的数据，防止缓存污染。这种混合策略的优势在于其灵活性和高效性。开发者可以根据业务需求，在 foyer 的配置层面进行深度调优。例如，可以调整 LRU 配置中的 high_priority_pool_ratio，为关键数据预留一个永不被 LRU 淘汰的高优先级池；或者，通过自定义 weighter 函数，根据数据大小或业务重要性赋予不同缓存项不同的“权重”，影响其在 LRU 队列中的位置。对于 TTL，虽然 cachey 当前未在 API 层面提供 per-object 的 TTL 设置，但其架构允许在未来通过扩展 C0-Config 头或配置文件，为不同 kind（桶集）设置不同的全局 TTL，实现更精细化的分层管理。

在工程实践中，这种混合淘汰策略带来了显著的性能提升。首先，它极大地提高了缓存命中率。LRU 确保了热点数据的快速访问，而 TTL 则通过及时清理冷数据，间接提高了新热点数据的入缓存概率。其次，它优化了资源利用率。内存和磁盘缓存空间被动态地分配给最有价值的数据，避免了因冷数据堆积导致的资源浪费。最后，它增强了系统的可预测性。TTL 为缓存数据设定了一个上限，使得运维人员可以更准确地预估缓存容量需求和数据新鲜度。对于 cachey 的使用者而言，理解其背后的 LRU+TTL 淘汰逻辑，有助于更好地配置 --memory 和 --disk-capacity 参数，并根据业务访问模式调整 foyer 的底层配置（如果未来开放），从而榨取最大的性能收益。总而言之，s2-streamstore 通过将成熟的 LRU 算法与实用的 TTL 机制在 foyer 库中进行融合，为 cachey 构建了一个既智能又高效的缓存淘汰核心，使其在应对海量、多变的对象存储访问时游刃有余。