Go Ristretto 怎么给缓存条目设置独立 TTL

如果一个缓存同时保存“用户资料”和“临时计算结果”，把所有键都交给同一个全局过期时间通常不够用。Ristretto v2 的做法是让每次写入携带自己的 TTL：资料可以保留 30 分钟，计算结果只保留 2 分钟，两个键互不影响。

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

给单个缓存条目设置有效期时，使用 SetWithTTL，把对应的 time.Duration 作为第四个参数传入；写入后调用 Wait 让缓冲中的写入可见，再用 GetTTL 判断条目是否存在以及还剩多久。TTL=0 表示不过期，负数则不会写入。

先确认使用的是支持单条目 TTL 的 API

Ristretto v2 的普通 Set 只有键、值和成本三个业务参数，本身表示永久缓存。需要逐条设置有效期时，应改用签名多一个 time.Duration 的 SetWithTTL。项目从 v1 迁移到 v2 时，还要留意模块路径和泛型缓存类型。

# 通过 Go Modules 引入支持泛型 API 的 Ristretto v2
go get github.com/dgraph-io/ristretto/v2

文章下面的示例使用 Cache[string, string]。它只展示 TTL 的边界，不把 Ristretto 当成跨进程或分布式缓存。

为每个缓存键传入独立 TTL

独立 TTL 的关键不是给缓存配置一个“全局过期值”，而是让不同的 SetWithTTL 调用传入不同的时长。下面的两个键分别代表较稳定的资料和短时计算结果。

package main

import (
    "fmt"
    "time"

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

func main() {
    // 配置只负责缓存容量；每个条目的 TTL 在 SetWithTTL 调用处决定。
    cache, err := ristretto.NewCache(&ristretto.Config[string, string]{
        NumCounters: 1e4,
        MaxCost:     1  0)
    fmt.Println(featureFound, featureTTL > 0)
}

这里的两个布尔变量先回答“写入是否进入缓冲”，GetTTL 返回的布尔值再回答“读取时条目是否存在且未过期”。它们不是同一个证据。Ristretto 的缓存写入还要经过内部策略，因此 SetWithTTL 返回 true 也不能把它理解成永久留存承诺。

用 GetTTL 看清零值、正值和负值

SetWithTTL 的第四个参数有三个重要分支：

如果业务允许“永不过期”，应显式把零值作为一种策略；如果 TTL 来自配置文件，则要在进入 SetWithTTL 前拒绝意外的负数。不要把负数当成“立即过期”，它的语义是本次写入不生效。

TTL 不生效时，先分层看证据

现场最容易混淆的是“条目很快读不到”。它可能是写入没有进入缓存、容量策略淘汰了条目、TTL 已到期，也可能只是写入还在缓冲中。按下面的顺序看，能把几个原因拆开：

1. 先看入参。记录本次调用的 TTL 是否为负数、是否误传成零，以及单位是否写成了 time.Second 而不是业务预期的分钟。
2. 再看返回值。如果新增键的 SetWithTTL 返回 false，先处理写入缓冲拥塞或调用时机；不要直接把问题归为过期。
3. 固定可见性。排查代码中调用 Wait，随后立刻用 GetTTL 读取。没有这一步时，后续读取可能早于缓冲应用。
4. 比较两种读取。GetTTL 的 found=false 只说明当前读不到有效条目；它不能单独证明是 TTL 到期，容量淘汰也会得到类似结果。
5. 检查更新路径。同一个键再次调用 SetWithTTL 会以新的 TTL 更新条目。若更新请求带了较短时长，旧的长 TTL 不会继续保留。

还要注意“到期时间”和“清理时间”不是同一个概念。Ristretto 会按内部清理节奏处理过期条目，但 Get 和 GetTTL 的读取结果会先依据条目的过期时间判断。因此不要用后台清理动作的时刻去推断 TTL 的精确边界。

更新 TTL 并做一次反向确认

实际业务经常需要续期，例如用户重新访问资料后，把资料条目的有效期重新设为 30 分钟。续期就是对同一个键再次调用 SetWithTTL，不需要先 Del。

// refreshProfile 只更新指定键的值和 TTL，不影响其他缓存键。
func refreshProfile(cache *ristretto.Cache[string, string], key, value string) bool {
    queued := cache.SetWithTTL(key, value, 1, 30*time.Minute)
    if !queued {
        // 新键未进入写入缓冲时，调用方应记录现场并决定是否重试。
        return false
    }

    // 让续期后的过期时间对紧接着的 GetTTL 可见。
    cache.Wait()
    ttl, found := cache.GetTTL(key)
    return found && ttl > 0
}

这个函数的返回值只适合做“续期后是否仍可读”的快速判断。生产代码如果需要更细的诊断，应分别记录 queued、found 和返回的 ttl，这样才能区分写入阶段和读取阶段的问题。

一张清单收尾

• 使用 Ristretto v2 时，模块路径是 github.com/dgraph-io/ristretto/v2。
• 单条目 TTL 由 SetWithTTL 的第四个 time.Duration 参数决定。
• 0 是不过期，负值是不写入，不是立即过期。
• 排查时先检查 SetWithTTL 返回值，再 Wait，最后用 GetTTL 和 Get 对照。
• 读不到条目可能来自 TTL 到期，也可能来自容量淘汰，不能只看一个布尔值下结论。

相关问题

Ristretto 的 SetWithTTL 传入 0 会立即删除条目吗？

不会。零值表示不设置过期时间，行为等同于普通 Set。如果业务要主动删除，应调用 Del。

为什么 SetWithTTL 返回 true 但之后 Get 仍然拿不到？

返回值主要表示写入请求进入了内部缓冲；条目后续仍可能被准入策略拒绝或被容量策略淘汰。排查时配合 Wait、GetTTL 和容量配置一起看。

GetTTL 返回 0, true 代表什么？

通常表示条目存在，但没有设置过期时间。它和 0, false 不同，后者表示当前没有可读取的有效条目。