Go-Cache不能用于微服务间共享配置缓存，因其仅为单机内存缓存，无跨实例同步、持久化及主动失效能力；正确方案是Redis作为主源、Go-Cache作本地加速层，通过TTL分级与singleflight控制一致性。
Go-Cache 不适合微服务间共享的热点配置缓存，它只是单机内存缓存，无法解决多实例下的数据一致性问题；真正该用的是 Redis + 本地 cache 双层结构，Go-Cache 仅可作为本地层补充。
为什么不能直接用 Go-Cache 存配置
Go-Cache（github.com/patrickmn/go-cache）本质是带 TTL 的线程安全 map，无持久化、无跨进程同步能力。在微服务多实例部署下：
- 每个实例各自加载一份配置，修改后其他实例完全不知情，导致配置漂移
- 重启即丢失，无法支撑“配置热更新”场景
- 不支持主动失效广播，比如通过 Redis Pub/Sub 通知所有节点刷新
- 无法与 go-zero 的
CachedConn或 sqlc 缓存层对齐，需额外维护两套缓存逻辑
正确的双层缓存结构：Redis 主源 + Go-Cache 本地加速
把 Go-Cache 当作 Redis 的“前置缓冲”，只缓存高频读、低频改的配置项（如开关、限流阈值、灰度比例），而非替代 Redis：
- 首次读配置：先查
localCache.Get(key)→ 未命中 → 查rdb.Get(ctx, "config:"+key).Result()→ 命中则localCache.Set(key, val, ttl) - 配置更新时：写 Redis（
rdb.SetEX(ctx, "config:"+key, val, ttl)），**不直接操作 Go-Cache**；靠 TTL 自然过期，或用简单版本号+轮询检测（避免复杂监听） - 本地缓存 TTL 应显著短于 Redis TTL（例如 Redis 设 10 分钟，Go-Cache 设 30 秒），防止本地 stale 数据滞留过久
- 注意
go-cache的DefaultExpiration和cleanupInterval：设太短（如 1s）会频繁触发清理 goroutine，设太长（如 24h）可能堆积无效 key
避免踩坑：空值缓存与并发加载
配置项可能临时不存在（如新功能开关未录入），若不处理会导致反复穿透查询 Redis 和 DB：
- 对空结果也缓存，但用特殊标记（如
nil或"__MISSING__"），并在localCache.Set时指定更短 TTL（如 5s） - 高并发下多个 goroutine 同时发现本地无缓存，会一起打 Redis —— 必须加
singleflight.Group控制：用sg.Do("config:"+key, func() (interface{}, error) { ... })保证同一 key 只有一路加载 - 不要在
init()里预热 Go-Cache：它没初始化完成时调用Get会 panic；应在NewServiceContext中构造好*cache.Cache实例再注入
实际代码片段：带 singleflight 的安全读取
var configGroup singleflight.Group
func GetConfig(ctx context.Context, key string) (string, error) {
val, ok := localCache.Get(key)
if ok {
return val.(string), nil
}
v, err, _ := configGroup.Do(key, func() (interface{}, error) {
// 先查 Redis
res, err := rdb.Get(ctx, "config:"+key).Result()
if err == redis.Nil {
// 空值缓存 5 秒
localCache.Set(key, "__MISSING__", 5*time.Second)
return "", nil
}
if err != nil {
return nil, err
}
// 写入本地缓存（TTL 比 Redis 短）
localCache.Set(key, res, 30*time.Second)
return res, nil
})
if err != nil {
return "", err
}
if v == "__MISSING__" {
return "", fmt.Errorf("config %s not found", key)
}
return v.(string), nil
}
真正麻烦的不是“怎么缓存”，而是“谁负责更新缓存”和“各实例如何感知变更”——Go-Cache 本身不提供这些能力，必须靠上层业务逻辑兜底。
