Golang热路径如何处理缓存未命中-Golang-PHP中文网

singleflight能防止缓存击穿，其核心是让同一key的并发请求只执行一次加载逻辑并共享结果；但必须配合先查缓存、稳定key命名、分层fallback及超时控制等策略才有效。

golang热路径如何处理缓存未命中

热路径上缓存未命中不是“等它自己好”，而是必须主动控制并发、避免雪崩、防止重复加载——否则一个 key 失效，几十个 goroutine 同时打穿缓存去查 DB，QPS 瞬间翻倍，数据库先扛不住。

go-cache、sync.Map 本身不合并未命中请求，singleflight.Group 是唯一轻量且可靠的解决方案。

每个热 key 对应一个 sg.Do("user:123", loadFunc) 调用，不管多少 goroutine 同时进来，只执行一次 loadFunc
loadFunc 必须返回 (interface{}, error)，成功后所有等待者拿到同一份结果，失败则全部收到 error
别把 sg.Do 包在 cache.Get 前面就完事：要先 cache.Get，未命中再 sg.Do；否则每次请求都进 singleflight，失去本地缓存意义
key 命名要稳定：比如用 "user:" + strconv.FormatInt(id, 10)，别用 fmt.Sprintf("%+v", req) —— 字段顺序一变，key 就不同，singleflight 形同虚设

热数据靠 TTL 自然过期，等于把压力交给高峰时刻。对已知高频 key，该预热就预热，该失效就失效，别赌“它刚好没过期”。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

服务启动后，用 goroutine 异步调用 cache.Set("config:global", data, cache.NoExpiration) 预热核心配置，避免首请求卡顿
监听配置变更（如 fsnotify）、DB 更新（如 binlog/cdc）或业务事件，触发 cache.Delete("user:123")，而不是等它自然过期
预热和失效都要加限流：比如用 semaphore.NewWeighted(5) 控制并发预热数量，防 Redis 或 DB 瞬间被打满
别给所有 key 统一设 time.Minute * 5：配置类设 time.Hour * 24，用户属性类设 time.Minute * 10，实时指标类设 time.Second * 30

热路径不能只有一条路可走。本地未命中 ≠ 直接查 DB，中间至少还有一层远程缓存兜底。

典型 fallback 顺序：local cache → redis → db，每层 miss 都要记录指标（如 cache_miss_local_total），否则无法定位瓶颈在哪一层
redis 层也得防击穿：对空结果（redis.Nil）同样写入本地缓存，TTL 缩短为 time.Second * 10，避免反复穿透
db 查询必须带 context 超时（如 ctx, _ := context.WithTimeout(r.Context(), 200*time.Millisecond)），且超时后返回上层缓存旧值（stale-while-revalidate），而非直接报错
如果 redis 也挂了，本地缓存该保留 stale 数据就保留，别清空——热数据有几秒延迟，总比整个接口不可用强

真正难的从来不是“怎么加缓存”，而是“缓存失效那一瞬间，系统有没有预案”。singleflight、预热、分层 fallback 这三样，漏掉任何一环，热路径上的未命中就会变成压垮服务的最后一根稻草。