不能只用 sync.Map 做多级缓存，因为它仅是单层并发映射，缺乏过期机制、容量控制和穿透能力，无法支撑本地+远程+数据库的分层职责；正确做法是分层解耦，每层专注自身生命周期与错误处理，并配备 fallback、回填与一致性策略。
为什么不能只用 sync.Map 做多级缓存
因为 sync.Map 是单层、无过期、无容量限制的并发安全映射，它没法自动淘汰旧数据，也不支持穿透到下一级（比如 Redis 或数据库）。真要实现多级缓存，得自己串起几层策略：内存层（快）、远程层（大）、源层（准）——每层职责不同，不能靠一个结构体硬扛。
常见错误是把所有层级塞进一个 map 加锁管理，结果锁竞争高、过期逻辑混乱、穿透失败时反复打下游。正确做法是分层解耦，每层只管自己的生命周期和错误处理。
- 内存层建议用
bigcache或freecache（比原生sync.Map支持 TTL 和驱逐） - 远程层用
redis.Client，别直接裸调Do，封装成带重试和超时的Get/Set - 穿透逻辑必须有 fallback 机制：比如 Redis 挂了，内存层失效后应允许降级直查 DB，而不是全量雪崩
怎么写一个带 fallback 的三级缓存 Get 方法
核心不是“怎么存”，而是“怎么取”——尤其在某一层不可用或 miss 时，如何不阻塞、不重复请求、不污染上层状态。
典型结构是：先查本地内存 → miss 则查 Redis → 再 miss 则查 DB → 成功后异步回填前两层。关键点在于中间层失败时的错误分类处理：
立即学习“go语言免费学习笔记（深入）”；
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
-
redis.Nil表示 key 不存在，可继续往下查 - 网络错误（如
redis: nil或context.DeadlineExceeded）应跳过该层，不写入、不传播错误给上层 - DB 查询失败需返回具体 error，由调用方决定是否重试或返回默认值
- 回填内存层要用
Set而非Store，确保 TTL 生效；Redis 层用SetEX显式设过期
示例片段（简化版）：
func (c *MultiLevelCache) Get(key string) ([]byte, error) {
// 1. 查内存
if data, ok := c.local.Get(key); ok {
return data, nil
}
// 2. 查 Redis
val, err := c.redis.Get(context.Background(), key).Bytes()
if err == nil {
c.local.Set(key, val, 10*time.Minute) // 回填内存
return val, nil
}
if !errors.Is(err, redis.Nil) {
log.Printf("redis get failed: %v", err) // 记录但不中断
}
// 3. 查 DB
data, err := c.db.QueryRow("SELECT value FROM cache WHERE key = ?", key).Bytes()
if err != nil {
return nil, err
}
// 异步回填（避免阻塞主流程）
go func() {
c.redis.Set(context.Background(), key, data, 24*time.Hour)
c.local.Set(key, data, 10*time.Minute)
}()
return data, nil
}
如何避免缓存击穿和一致性问题
击穿本质是热点 key 失效瞬间大量请求穿透到 DB；一致性则是多级之间状态不同步。这两个问题不能靠加锁全解决，得结合策略组合。
- 对可能击穿的 key，内存层用
atomic.Value+ double-check 配合sync.Once初始化，Redis 层用SET key value EX 3600 NX实现原子占位 - 更新时必须按“先删远端（Redis），再删本地，最后写 DB”顺序，否则出现短暂脏读；删除操作本身也要幂等，比如用
Del而非Flush - 本地内存层如果用了
bigcache，注意它的Get返回的是字节切片引用，别直接改内容，否则可能被后续请求读到脏数据 - 不要依赖 TTL 自动清理——业务侧应在关键路径（如订单状态变更）主动触发
Delete，降低过期延迟带来的不一致窗口
什么时候该放弃多级缓存
不是所有场景都适合堆三层。当你的数据更新频率低、QPS 小于 500、或者下游 DB 本身已带足够缓存（如 PostgreSQL 的 shared_buffers + pg_prewarm），多级反而增加复杂度和故障面。
真正需要多级的信号是：内存层 hit rate 100ms 占比超 5%）。否则优先优化单层——比如把 sync.Map 换成 freecache，加个合理的 TTL，比硬搞 Redis + 本地更稳。
最容易被忽略的是监控粒度：必须单独统计每层的 miss rate、平均延迟、错误类型分布。没有这些数据，你根本不知道哪一层在拖后腿，还是只是某次部署导致 Redis 连接池耗尽。
