Go Ristretto 怎么按对象成本限制缓存容量

如果希望 Ristretto 按对象大小而不是按条目数量控制缓存容量，核心做法是把容量预算抽象成一个统一的“成本单位”：在配置里设置 MaxCost，写入时通过 Set(key, value, cost) 传入当前对象的成本。成本可以直接用字节数，也可以用业务定义的权重，但同一个缓存中必须保持单位一致。

官方地址：https://github.com/dgraph-io/ristretto

Ristretto 的容量限制不是“最多放多少条”，而是“所有已接纳条目的 cost 总和不能超过 MaxCost”。大对象应该传更大的 cost；新条目是否最终进入缓存还会受到异步缓冲和准入策略影响。

先把总预算和对象成本说清楚

Ristretto v2 的配置中，MaxCost 表示缓存允许使用的最大总成本，Set 的第三个参数表示单条数据的成本。两者不要求必须是字节，但需要能比较大小。例如，若缓存预算按字节计算，就让每个 value 的 cost 等于序列化后的字节数；若对象大小不方便测量，也可以用“轻对象 1、重对象 8”这样的离散权重。

不要把“缓存 1000 条”直接换算成 MaxCost: 1000 后就认为得到了内存上限。若一条 JSON 只有几百字节，另一条响应有几百 KB，它们都记为 1 会让成本模型失真。

在 Config 中设置 MaxCost

下面的例子以 Ristretto v2 为例。这里选用字节作为成本单位，并让 NumCounters 大于预期缓存键数量的一个数量级，用于频率跟踪；它不是缓存容量，也不会替代 MaxCost。

package main

import (
    "fmt"

    "github.com/dgraph-io/ristretto/v2"
)

func main() {
    cache, err := ristretto.NewCache(&ristretto.Config[string, []byte]{
        NumCounters: 1e6, // 跟踪访问频率的键数量，不代表可缓存条目数
        MaxCost:     64 

这里的 MaxCost 和 len(payload) 使用同一种单位，所以缓存会优先把总成本看成字节预算。配置创建后要在应用生命周期结束时调用 Close，不要把每次请求创建缓存当成容量控制手段。

写入时为大对象传入更高 cost

成本计算要发生在写入边界，而不是等缓存内部猜测 value 的大小。对字符串、JSON 或二进制响应，可以在编码完成后计算字节长度；对共享对象，则要先约定是按序列化大小、估算大小，还是按业务权重计费。

func putJSON(cache *ristretto.Cache[string, []byte], key string, payload []byte) {
    if len(payload) == 0 {
        return // 空值不值得占用预算，调用方也可选择直接删除旧值
    }

    cost := int64(len(payload)) // 与 Config.MaxCost 保持相同的“字节”单位
    accepted := cache.Set(key, payload, cost)
    _ = accepted // 新条目可能被异步缓冲或准入策略丢弃，不能把 bool 当持久化确认
}

如果采用离散权重，也要在代码中集中定义规则，避免一个调用点按字节、另一个调用点按对象个数：

func cacheCost(payload []byte) int64 {
    switch {
    case len(payload) 

这类权重适合只需要控制相对大小的场景，但它不是精确内存统计。若文章中的容量预算就是内存预算，优先使用实际字节数或经过压测校准的估算。

理解 Set、Wait 和淘汰边界

Ristretto 为吞吐采用了批量和最终一致的写入路径。Set 返回的布尔值表示调用是否被接受到写入路径，但对新条目而言，并不等价于“此刻已经能从 Get 读到”；项目文档也说明新条目可能在缓冲或准入阶段被丢弃，而更新已有条目有不同保证。

cache.Set("large", largePayload, int64(len(largePayload)))
cache.Wait() // 示例或需要确定读取时，再等待写入缓冲处理完

if got, ok := cache.Get("large"); !ok {
    // 未命中不一定是 cost 计算错误，也可能是新条目未通过准入或已被淘汰
    fmt.Println("cache miss")
} else {
    fmt.Println(len(got))
}

当一个新对象的 cost 较大时，它可能挤出多个较小对象；这正是成本淘汰与按条目数淘汰的差别。成本上限仍然只是缓存策略，不是对进程 RSS 的精确承诺，运行时、对象指针、碎片和其他组件都会消耗内存。

三个容易混淆的边界

另一个常见误区是把 MaxCost 当成硬实时的“写入成功保证”。Ristretto 的设计优先考虑并发吞吐和命中率，新条目可能因为缓冲或准入策略没有进入缓存；业务必须能接受缓存未命中，并把真实数据放在数据库、远端服务或其他权威存储中。

落地时可以这样选择成本单位

• 响应体大小差异明显：用序列化后的字节数，MaxCost 直接按字节配置。
• 对象结构稳定但不便序列化：用经过压测校准的离散权重，并集中维护权重函数。
• 想限制条目数量：所有条目的 cost 传 1，但要明确这只是条目预算，不是内存预算。

最后记住一条判断：如果两个条目在你的业务里占用资源明显不同，就不要给它们相同的 cost。让 MaxCost 表达总预算，让 Set 表达单条代价，Ristretto 才能按对象成本做出有意义的准入和淘汰决定。

相关问题

MaxCost 设置成 0 会怎样？

不要把 0 当作“自动计算内存”。应根据应用预算和统一的成本单位设置正数，并在容量策略外单独管理 Go 运行时和进程级内存。

为什么 Set 成功后马上 Get 仍然未命中？

Ristretto 的写入包含异步缓冲，新条目还可能没有通过准入策略。需要在必须等待的示例或批处理边界调用 Wait，同时把未命中视为缓存的正常结果。

一个对象 cost 大于 MaxCost 能强行写进去吗？

不应把成本超过总预算的对象当作一定可缓存对象。可以在调用方提前决定跳过、降级或只缓存摘要，避免让极大对象反复消耗写入路径。