可行但需绕过Ristretto不处理空值和过期语义的缺陷：必须封装SetNullWithTTL和GetWithNullCheck，用带IsNull和Expire字段的结构体显式编码空值语义，避免nil混淆、僵尸键及并发击穿。
直接用 Ristretto 做防穿透缓存是可行的，但必须绕过它默认不处理“空值”和“过期语义”的设计缺陷——它本身不区分 nil、空结构体或业务意义上的“不存在”，Get() 返回 false 只代表未命中，不是“查无此数据”。防穿透的关键动作：缓存空结果、控制其 TTL、避免污染有效条目。
为什么 Set(nil) 或 Set("") 无法防穿透
Ristretto 不拒绝空值，但也不会主动标记它是“空响应”。如果你只写 cache.Set("user:999", nil, 1)，后续 Get("user:999") 确实能拿到 nil 和 true，但问题在于：
- 你无法区分这个
nil是“缓存了空值”，还是“刚初始化还没写入” - 没有 TTL 时，它永远留在内存里，变成僵尸键
- 如果多个 goroutine 同时查
user:999，Ristretto 不提供 singleflight 机制，会并发回源打 DB
必须封装 SetNullWithTTL 和 GetWithNullCheck
不能裸调 Set，得把空值语义显式编码进去。推荐用一个带标记的结构体，而不是直接塞 nil：
<pre class="brush:php;toolbar:false;">type CacheValue struct {
Data interface{}
IsNull bool
Expire int64 // UnixNano
}
func (c *Cache) SetNullWithTTL(key string, ttl time.Duration) {
now := time.Now().UnixNano()
c.cache.Set(key, CacheValue{IsNull: true, Expire: now + int64(ttl.Nanoseconds())}, 1)
}
func (c *Cache) GetWithNullCheck(key string) (data interface{}, isNull bool, ok bool) {
v, found := c.cache.Get(key)
if !found {
return nil, false, false
}
cv, ok := v.(CacheValue)
if !ok {
return nil, false, false
}
if cv.Expire < time.Now().UnixNano() {
c.cache.Del(key) // 主动清理过期空值
return nil, false, false
}
return cv.Data, cv.IsNull, true
}
- 用
CacheValue 统一封装，避免类型断言失败 -
Expire字段用于 Get 时校验，不依赖 Ristretto 内置 TTL（它 v2 版本才支持ristretto.TTL，且仅作用于驱逐，不自动清理） - 主动调
Del()而非等驱逐，防止过期空值长期占位
并发查空键时如何防击穿
Ristretto 自身不提供防击穿能力，必须外挂 singleflight.Group：
立即学习“go语言免费学习笔记（深入）”；
- 对每个 key 做
group.Do(key, loadFunc)，确保同一时刻最多一个 goroutine 回源 -
loadFunc内先GetWithNullCheck，命中空值就直接返回；未命中再查 DB；查到空结果就调SetNullWithTTL - 别在
loadFunc里直接cache.Set(..., 0)——ItemCost=0会导致立即驱逐，空值存不住
成本设置必须让空值“便宜”但不可忽略
空值条目也要设 ItemCost，但不能为 0，也不能和大对象同价：
- 设
ItemCost = 1是安全下限：既不会被立即踢出，又不会挤占有效缓存空间 - 别用
unsafe.Sizeof(nil)算成本——它返回 0；改用固定小整数 - 如果缓存中空值占比超过 20%，说明上游查询逻辑有问题（比如没前置布隆过滤），该加预检而非调高成本
真正难的不是把空值塞进去，而是让它在正确的时间点被识别、清理、且不干扰正常条目的驱逐节奏——Ristretto 的 cost 模型是双刃剑，用错一点，空值就会从防护盾变成内存钉子。
