缓存应放在业务逻辑层而非HTTP层，因其能精确控制键、失效逻辑和空值缓存；开发用ristretto等内存缓存，上线必选Redis保障一致性；雪崩、穿透、击穿需分别用随机过期、空值缓存/布隆过滤器、互斥锁应对；更新策略为先更新DB再删缓存，并确保原子性或异步可靠删除。
缓存该放在哪一层：HTTP 层还是业务逻辑层？
多数人一想到缓存就直接往 http.Handler 里塞，比如用 httpcache 或自定义中间件拦截 GET 请求。但这容易出问题：缓存策略和业务语义脱节。比如用户 A 和用户 B 请求同一路径 /api/user/profile，但返回内容不同——HTTP 层无法区分身份上下文，缓存可能错乱。
更稳妥的做法是把缓存下沉到业务逻辑层（如 service 层），由具体函数控制缓存键、过期时间、是否穿透等。例如：
// GetUserInfo 缓存键包含 user_id，天然隔离用户维度
func (s *UserService) GetUserInfo(ctx context.Context, userID int64) (*User, error) {
cacheKey := fmt.Sprintf("user:info:%d", userID)
var u User
if err := s.cache.Get(ctx, cacheKey, &u); err == nil {
return &u, nil
}
u, err := s.db.GetUserByID(ctx, userID)
if err != nil {
return nil, err
}
s.cache.Set(ctx, cacheKey, &u, time.Minute*10)
return &u, nil
}
- HTTP 中间件适合做「无状态响应缓存」，比如公开的静态资源、聚合页 HTML
- 业务层缓存能精确控制 key 构造、失效逻辑、空值缓存（防止穿透）
- 避免在 handler 里直接调
cache.Get后再调db.Query—— 这种“裸缓存”没封装，难以复用和测试
用什么缓存后端：Redis 还是 memory？
开发阶段用 ristretto 或 bigcache 做内存缓存没问题，速度快、零依赖；但上线后必须切到 Redis（或兼容协议的集群如 AWS ElastiCache）。原因不是性能，而是一致性和可见性。
Go 进程内缓存（in-process）在多实例部署时完全不共享，A 实例更新了数据，B 实例的缓存还是旧的，且无法主动失效。
立即学习“go语言免费学习笔记（深入）”；
- 选 Redis 时，优先用
github.com/redis/go-redis/v9，它原生支持 context 取消、pipeline、failover - 避免用
SETNX手写分布式锁来防缓存击穿——直接用GET + SET EX PX NX原子操作即可 - 对高频小对象（如配置项），可考虑 Redis 的
HGETALL批量拉取，减少 round-trip
如何避免缓存雪崩、穿透、击穿
这三个词常被混讲，实际触发场景和解法差异很大：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
雪崩：大量 key 同一时刻过期 → 全部打到 DB。解法：设置随机过期时间，比如
time.Minute*10 + time.Second*time.Duration(rand.Intn(60)) -
穿透：查不存在的 ID（如
id = -1），缓存不命中，DB 也查不到，每次请求都穿透。解法：对空结果也缓存（cache.Set(ctx, key, nil, time.Minute)），或布隆过滤器前置校验 -
击穿：热点 key 过期瞬间，大量并发请求同时发现缓存失效，全部打 DB。解法：加互斥锁（
redis.SET key "lock" EX 3 NX），只放行一个请求回源，其余等待后读缓存
注意：ristretto 等内存库不支持原子 set-if-not-exist，所以击穿防护必须依赖外部存储（如 Redis）。
缓存更新策略：先删缓存还是先更新 DB？
答案是：先更新 DB，再删缓存（delete，不是 set），且要保证二者在同一个逻辑流程中完成。不要用「延迟双删」这类靠 sleep 补救的方案——网络抖动或 GC 暂停会让它彻底失效。
典型错误写法：
// ❌ 错误：删缓存失败后没回滚，DB 更新成功但缓存残留脏数据 db.UpdateUser(...) cache.Delete(ctx, key) // 这里失败怎么办？
正确做法是把缓存删除作为 DB 更新后的必要步骤，并做重试或降级：
- DB 更新成功后，同步调
cache.Delete；失败则记录日志并告警，人工介入 - 高可用要求下，可投递消息到队列（如 Kafka），由独立消费者异步删缓存，但需处理消息重复和顺序问题
- 绝不使用「更新缓存」代替「删除缓存」——除非你能 100% 保证所有字段都被覆盖且无竞态
最常被忽略的一点：缓存 key 的设计必须和 DB 查询条件严格对齐。比如 DB 是按 email 查用户，但缓存 key 却用 id，那删 key 根本无效。
