Go Ristretto Set 返回后立刻 Get 为什么可能取不到

Go Ristretto 的新键写入包含缓冲处理和策略接纳，Set返回不等于该键已经能被Get读到。Set返回true也不能保证新条目最终留下来；Wait能等待此前缓冲写处理，但不能让被拒绝、过期或淘汰的条目重新出现。我的取舍是：用Wait帮助区分“还没处理”和“处理后没留下”，业务代码始终允许缓存未命中并回源。

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

我先把未命中分成两类

假设接口刚从数据源拿到一个商品名称，随后Set到缓存，再立即Get。Get的found为false，很容易被理解成“商品不存在”。但这其实把缓存状态和业务状态混在了一起：数据源已经返回商品，缓存此刻没有这条值，并不能推翻前面的业务结果。

对我来说，排查这种现象最重要的第一步不是增加sleep，而是确认错误归属。缓存未命中通常意味着需要回源；业务不存在应由数据源的明确结果表达。本文围绕这段调用关系展开，不给出已经运行过的日志或命中率数据。

还有一个小细节：判断Get是否命中要看found，不能把空字符串或零值直接当作未命中。泛型值类型本身可以有合法零值。

Set的布尔值不是存储确认

Set接口文档 把两个判断分开：false表示写入请求被丢弃；true仍可能遭遇缓存策略拒绝。对于这里讨论的全新键，写缓冲是否接收它，与策略是否值得保留它，不是同一个判断。

因此，我会把变量命名为accepted而不是saved。saved容易让业务代码暗示“已经存好且一定可读”，accepted则提醒读者这只是调用结果。也不要把所有写入一概描述成纯异步：当前实现对已有键更新另有处理路径，本文症状以新键为重点。实现细节见 cache.go。

我觉得这种设计最需要适应的地方，就是不把Ristretto当作普通map。它是有容量取舍的缓存，条目能被拒绝和淘汰属于使用契约的一部分；如果应用无法接受任何未命中，这个用途就需要另一个可靠存储层。

用Wait排除尚未处理的写缓冲

下面是可供读者运行的诊断函数，采用v2泛型接口。它创建独立实例、只尝试一个新键，不设置TTL，也没有其他goroutine写入或删除。结果保留三个字段，避免把Set、Get和最终值混成一个布尔值。

package cachecheck

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

// Observation分别记录写入调用结果和读取结果。
type Observation struct {
    Accepted bool
    Found    bool
    Value    string
}

// ObserveOne用于诊断，不应在每次业务请求里创建缓存。
func ObserveOne() (Observation, error) {
    c, err := ristretto.NewCache(&ristretto.Config[string, string]{
        NumCounters: 10000,
        MaxCost:     1 

接口的等待语义见 Wait文档。读者运行时可以比较有无Wait的读取情况，但不应要求“不加Wait必然失败”：后台处理可能恰好先完成。这种现象本身就是调度差异，不能用一次命中否认异步缓冲，也不能把一次未命中说成所有配置都这样。

我更愿意在诊断或批量预热结束处使用明确的Wait，而不是赌一个固定毫秒数。sleep只是经过一段时间，没有表达缓冲工作已经处理完。Wait同样不是数据库事务确认，更不是为未来所有并发写入提供永久可见性保证。

等待后仍未命中再看哪些条件

Wait已经消除了一个等待因素，接下来应换一层判断，而不是不断延长sleep。我的排查顺序如下，表中的现象是判断线索，不是本次实测：

成本单位由你的配置约定，不要一边按字节设MaxCost，一边所有值都随意填1，然后把容量表现当成库失效。默认内部成本也可能参与计算，因此MaxCost不是完整进程RSS上限。TTL语义和成本说明可查 配置接口。

需要观察拒绝与丢弃时，可以在自己的程序中启用Metrics，区分调用层丢弃与策略拒绝。不要由Set返回true直接推算缓存新增数量。本文不编造这些计数。

业务结果不要绕缓存再取一次

商品已从数据源取到，就直接返回它；Set只是给后续请求提供一次缓存机会。下面的函数把这个取舍写进接口：命中缓存时返回缓存值，未命中时调用load；回源失败不伪造成功，回源成功不因缓存未留下条目而丢弃商品名称。

// Name在缓存未命中时回源；需要同包导入fmt。
func Name(c *ristretto.Cache[string, string], key string,
    load func(string) (string, error)) (string, error) {
    if c == nil || load == nil {
        return "", fmt.Errorf("缓存和回源函数不能为空")
    }
    if value, found := c.Get(key); found {
        return value, nil
    }
    value, err := load(key)
    if err != nil {
        return "", fmt.Errorf("回源失败: %w", err)
    }
    // 缓存写入失败不改变已取得的业务结果，按应用约定估算成本。
    c.Set(key, value, int64(len(value)))
    return value, nil
}

将这段函数放入前面的包时，在import中补上fmt。真实工程还应约定TTL与数据更新策略；如果同一键在高并发未命中时触发重复回源，需要单独处理并发合并。本文不把这个简化片段包装成完整缓存框架。

这个写法的收获，是把缓存可用性与数据正确性分开；代价是仍需维护数据源及一致性规则。对我来说，这比在每次Set后Wait再Get更符合缓存职责，也不会把等待开销偷偷塞进所有请求。

我会保留的使用边界

诊断时固定同一实例和同一键，检查Set布尔值，必要时Wait，再考虑策略、TTL和并发；业务路径则始终保留回源，不把命中当作硬性成功条件。它适合能容忍缓存未命中的加速层，不适合把条目是否存在当成不可丢失的业务状态。

Wait后就能保证每个Set都命中吗？

不能。等待处理不等于强制接纳，之后也可能发生淘汰、过期或删除。

每次Set后都Wait是不是最简单？

对一个小型诊断例子很直接；对高吞吐业务，会把批量缓冲优势变成频繁等待，而且仍解决不了策略拒绝。应围绕真正需要等待的边界使用。

Set返回false要不要无限重试？

不要。先识别缓存实例是否有效、写负载是否合理。缓存写入是可选优化时，保留已回源的值并观察丢弃情况，比让业务卡在缓存重试更合适。