Go语言ristretto缓存库_Golang Dgraph缓存准入策略-Golang-PHP中文网

tinylfu准入策略本质是轻量级频率筛检机制：仅用12位计数器+count-min sketch估算key访问趋势，预估低价值即拒绝写入，不占内存、不触发淘汰；numcounters需设为10×maxcost量级以防哈希冲突误拒高频key。

go语言ristretto缓存库_golang dgraph缓存准入策略

TinyLFU 准入策略不是“放行所有热数据”，而是用极小代价（12位计数器）筛掉大概率低价值的写入

很多开发者以为 TinyLFU 是个“智能判断是否该缓存”的黑盒，实际它只做一件事：在 Set() 时快速估算这个 key 的访问频率趋势，若预估长期价值偏低，就直接拒绝写入——不进缓存、不占内存、不触发淘汰逻辑。这和传统“先写再淘汰”有本质区别。

关键点：

TinyLFU 依赖 NumCounters 参数（默认 1e7），值太小会导致哈希冲突激增，把高频 key 当作噪声拒掉；建议设为 10 * MaxCost 量级
它不维护完整访问历史，只靠 Count-Min Sketch 统计采样频次，所以对突发流量（如秒杀首波请求）识别滞后，前几次可能被误拒
没有 TTL 或权重参与准入决策——cost 和 ttl 只影响后续淘汰，不影响 TinyLFU 是否放行
如果你发现大量 Set() 后 Get() 不命中，且 cache.Metrics().Gets 远高于 cache.Metrics().Hits，大概率是 NumCounters 设置过小或工作负载 Zipf 分布太陡

SampledLFU 不遍历全量缓存，而是在每次淘汰时随机采样一批 storeItem（默认 16 个），从中挑出“频率计数最低 + 成本最高”的组合项驱逐。这意味着：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

它不保证精确 LRU 行为，但实测在搜索/数据库类负载下命中率反超 LRU —— 因为真实场景中“最近访问”不等于“未来还会访问”
淘汰决策受 cost 显著影响：一个 cost=100 的大对象，可能换掉 10 个 cost=1 的小对象，这是 IgnoreInternalCost: false 时的核心逻辑
如果关闭成本感知（IgnoreInternalCost: true），则退化为纯频次驱动，此时 MaxCost 就变成纯条目数限制，和示例里 MaxCost: 10 那种用法一致
采样本身有随机性，所以同一缓存实例在相同压力下，两次淘汰的 key 可能不同——别依赖淘汰顺序做业务假设

ristretto 把写入拆成两阶段：Set() 只写入无锁 buffer，异步批量刷到分片 map；Wait() 等待 buffer 刷完。不调用 Wait() 就读不到刚写的值，尤其在测试或短生命周期服务中极易踩坑。

别被“并发安全”字面意思骗了。sync.Map 读快写慢，写操作需锁整个 dirty map；ristretto 的分片 map（256 个 lockedMap）让写竞争概率下降两个数量级。

压测显示：16 核机器上，10k goroutine 并发 Set()，sync.Map 吞吐跌到 2w ops/s 以下，ristretto 仍稳定在 80w+ ops/s
ristretto 的写吞吐几乎不随 goroutine 数线性衰减，而 sync.Map 在 goroutine 超过 CPU 核数 2 倍后就开始明显抖动
但 ristretto 内存占用固定（由 MaxCost 和 NumCounters 决定），sync.Map 会无限增长——这点常被忽略
如果只是存配置、开关等极少更新的数据，sync.Map 更轻量；一旦涉及高频写+有限内存+高命中率诉求，ristretto 的准入/淘汰协同才是关键