Golang微服务中的分级缓存策略_本地缓存、Redis与DB结合

首选 ristretto：支持过期、容量控制、lfu/lru 混合淘汰，避免 oom；sync.map 无淘汰策略，不适用高并发读场景。

本地缓存该用 sync.Map 还是 ristretto？

单机高并发读场景下，sync.Map 不是首选——它写多读少时性能反降，且不支持过期、大小限制和淘汰策略。真实微服务里，本地缓存要扛住突发流量、自动驱逐冷数据、避免内存无限增长。

• 用 ristretto：默认 LRU + LFU 混合策略，支持带权重的近似容量控制（比如固定 10MB），能主动驱逐低访问频次条目
• 别直接封装 sync.Map 做“简易缓存”：没有 TTL 的键会永久滞留，GC 压力大，上线后容易 OOM
• 注意 ristretto 的 Cache.Get() 返回 (value, ok)，不是指“是否存在”，而是“是否命中缓存”——未命中时需自行回源并调用 Set()

redis 缓存穿透：空值怎么存才不浪费内存？

用户查一个根本不存在的订单 ID，每次请求都穿透到 DB，DB 压力飙升。简单存 nil 或空字符串进 redis，会导致大量无效 key 占满内存，还拖慢 SCAN 和 RDB 快照。

• 统一用 SET key "NULL" EX 60（注意是字符串 "NULL"，不是 nil）：应用层可识别并跳过后续逻辑，Redis 本身不感知语义，但空间可控
• 加一层布隆过滤器（bloomfilter）前置判断：对高频查询字段（如 user_id）做预检，误判率控制在 1% 内即可大幅降低穿透量
• 禁止用 EXPIRE 单独设置空值 key 的过期时间——必须和 SET 原子执行，否则存在竞态导致空值长期残留

三级缓存读取顺序：为什么不能先查 DB 再写两级缓存？

常见错误是「查 DB → 写本地缓存 → 写 Redis」，看似稳妥，实则破坏一致性：若第二步失败，本地缓存有新值而 Redis 仍是旧值，下次其他实例读 Redis 就拿到脏数据。

• 正确顺序是：先查本地缓存 → 未命中查 Redis → Redis 未命中再查 DB → 成功后**并行写入本地缓存和 Redis**（非串行）
• 本地缓存写入用 ristretto.Cache.Set()，Redis 写入用 redis.Client.Set(ctx, key, val, ttl)，两者失败互不影响，各自重试或降级
• DB 查询结果必须带版本号或更新时间戳，写入 Redis 时作为 value 的一部分，避免本地缓存与 Redis 因序列化差异导致结构不一致

缓存失效时的雪崩风险：如何让多个请求不同时刷新同一条数据？

热门商品详情页缓存过期瞬间，上百请求同时打到 DB，CPU 直接拉满。加分布式锁（如 Redis SET key val NX EX）能解决，但锁粒度太粗会卡住无关 key 的请求。

立即学习“go语言免费学习笔记（深入）”；

• 用“逻辑过期”代替物理删除：Redis 中 value 存结构体 {"data": ..., "expire_at": 1717...}，读取时检查 expire_at，过期则异步刷新，当前请求仍返回旧值
• 本地缓存层加 singleflight.Group：同一 key 的并发请求只放行一个去回源，其余等待其结果，避免重复加载
• 禁止在 http handler 里直接调用 time.Sleep() 等待刷新完成——会阻塞 goroutine，压垮连接池

分级缓存真正难的不是写几行 Get 和 Set，而是每个环节的失败路径是否被显式处理：本地缓存写失败要不要告警？Redis 超时后是返回旧值还是直接报错？这些边界一旦漏掉，压测时才暴露，就晚了。