高性能 Go 缓存库 Ristretto：从算法原理到生产级架构实践

如果你的业务要求写后立刻必须读到，并且绝不能被策略拒绝，那你需要的是数据库、Redis 强写路径，或者同步本地结构，而不是把 Ristretto 当成事务性组件。

3. 核心原理：为什么它的命中率和吞吐都很高

Ristretto 的核心并不是单一算法，而是一套组合拳：

• 用近似频率统计识别值得保留的热点数据
• 用采样淘汰降低全量维护开销
• 用异步缓冲降低写路径竞争
• 用成本模型替代按条数缓存，使内存控制更贴近真实资源消耗

3.1 TinyLFU：高命中率的根基

传统 LRU 的问题在于它更偏向最近访问过，但无法很好地区分偶然访问一次和长期高频访问。

TinyLFU 的思路是：

1. 先用近似频率结构记录访问热度
2. 新对象进入缓存前，不是直接放行，而是和候选淘汰对象比较谁更值得保留
3. 如果新对象热度不如已有对象，就拒绝写入

这样做的收益是：

• 扫描流量不容易污染缓存
• 突发请求不会迅速挤掉长期热点
• 在固定内存下，整体命中率通常优于简单 LRU

3.2 Count-Min Sketch：用近似换效率

Ristretto 并不会为每个 key 保存一个精确计数器，那样空间成本太高。它采用近似计数结构来估计频率。

Count-Min Sketch 的特点：

• 空间占用可控
• 更新速度快
• 支持高并发下的频率近似统计
• 允许少量哈希冲突带来的误差

这是一种典型的工程权衡：不追求每个 key 的绝对精确频率，而是追求大规模场景下足够好的热度判断。

3.3 Sampled LFU：不是全量比较，而是采样比较

严格 LFU 维护成本很高。Ristretto 会从候选对象中采样，挑出部分对象与新写入对象比较成本和热度，再决定是否淘汰。

这带来的好处是：

• 避免全局排序或大堆结构的高开销
• 在高并发下保持较好吞吐
• 仍能获得接近最优的淘汰效果

3.4 异步写入：吞吐提升的关键

Ristretto 的 Set 不是直接同步写入底层存储，而是进入缓冲队列，再由后台 goroutine 做策略处理和存储更新。

它的意义不是让写一定成功，而是：

• 让业务线程尽快返回
• 把多次写入合并为批量处理
• 降低锁竞争和策略计算对前台请求的影响

这也是为什么：

• Set 返回 true 不代表一定最终留下
• 在测试或极端依赖写后读时，常常要调用 Wait()

3.5 成本模型：Ristretto 最容易被低估的能力

很多缓存只支持最多存 N 条。这在生产环境通常不够，因为：

• 一个 512B 对象和一个 256KB 对象都算 1 条并不合理
• 大对象可能迅速击穿内存预算
• GC 压力和对象大小强相关

Ristretto 允许业务自定义 cost，本质上是把缓存容量从条目数升级为资源预算。

在架构层面，这意味着我们能把缓存治理从感觉差不多升级为可测量、可预算、可压测。

4. 架构拆解：Store、Policy、Buffer、TTL、Metrics

可以把 Ristretto 理解成下面这条流水线：

业务请求 │ ├── Get ──────> Store 查询 ──────> 命中返回 │ │ │ └── 记录访问热度 │ └── Set ──────> Buffer 缓冲 ─────> Policy 决策 ─────> Store 写入/拒绝/淘汰

4.1 Store：真正存值的地方

Store 负责：

• 根据 hash 保存 key/value
• 支持并发读写
• 在淘汰发生时删除对象

从架构上看，它更像是缓存数据平面。