sync.Mutex在多实例部署下完全无效，因其仅作用于单进程内goroutine，无法约束跨机器、跨容器的并发请求；缓存击穿需Redis原子操作或singleflight.Group等分布式协调机制。
sync.Mutex 不能在多实例部署下避免缓存击穿，它只对单进程内 goroutine 有效；Redis 缓存击穿必须用分布式协调机制，不是本地锁能解决的。
为什么 sync.Mutex 在击穿场景下完全无效
击穿发生在 Redis key 过期瞬间，多个请求同时发现缓存 miss，全部涌向数据库——这些请求大概率来自不同机器、不同进程。哪怕你在 Get 逻辑里包了一层 mu.Lock()，也只能拦住本机同一时刻的 goroutine，其他实例照样并发查库。
- 本地锁对跨进程、跨容器、跨 Pod 的请求毫无约束力
- 即使单机部署，HTTP server 启动多个 worker（如 Iris、Gin 默认用 goroutine 池），
sync.Mutex也只保护其所在变量作用域，不阻塞后续请求进入 handler - 错误使用还会导致 goroutine 阻塞堆积，触发 context deadline 或连接池耗尽
真正可用的 Go 击穿防护组合：Redis + singleflight.Group
singleflight.Group 不是锁，而是“请求去重器”：对相同 key 的并发调用，只放行第一个执行真实加载逻辑（DB 查询 + 写缓存），其余等待其返回结果。它天然适配 Go 的并发模型，且不依赖外部系统。
- key 必须是
string，推荐用fmt.Sprintf("item:%d", id)构造，避免传入int或指针导致哈希不稳定 - 整个加载逻辑（含 DB 查询、反序列化、
rdb.Set）必须完整包裹在Do的func() (interface{}, error)中，不能在外面写缓存 - 全局复用一个
singleflight.Group实例即可，不要每次 new；它本身是线程安全的 - 务必检查
redis.Nil：如果 DB 查无结果，要明确返回空值并缓存（带短 TTL），否则下次请求仍会击穿
var sg singleflight.Group
<p>func getItem(ctx context.Context, id int) (*Item, error) {
key := fmt.Sprintf("item:%d", id)
if v, ok := rdb.Get(ctx, key).Result(); ok == nil {
var item Item
if err := json.Unmarshal([]byte(v), &item); err == nil {
return &item, nil
}
}</p><pre class='brush:php;toolbar:false;'>// 缓存 miss，走 singleflight
v, err, _ := sg.Do(key, func() (interface{}, error) {
// 注意：此处必须重查一次缓存，防止竞态
if v, ok := rdb.Get(ctx, key).Result(); ok == nil {
var item Item
if err := json.Unmarshal([]byte(v), &item); err == nil {
return item, nil
}
}
// 真实回源
item, err := db.QueryItem(ctx, id)
if err != nil {
return nil, err
}
// 写缓存（带随机 TTL 偏移防雪崩）
ttl := 10 * time.Minute
if item == nil {
ttl = 30 * time.Second // 空结果更短
}
ttl += time.Duration(rand.Int63n(int64(60 * time.Second)))
data, _ := json.Marshal(item)
rdb.Set(ctx, key, data, ttl)
return item, nil
})
if err != nil {
return nil, err
}
return v.(*Item), nil}
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
什么时候才该考虑加 Redis 分布式锁
只有当你需要强顺序控制或跨服务协作时，才引入 SETNX 类锁。比如：后台定时刷新热点数据、多服务共管同一配置项、或与非 Go 服务共享更新语义。
- 锁 key 命名建议带服务标识，如
lock:item:123:svc-order - 必须用
SET item:123_lock "req-abc123" NX EX 5原子命令，别拆成GET+SET或GETSET - value 必须带唯一标识（如 trace ID），释放前先 GET 校验再 DEL，避免误删别人锁
- 锁超时时间必须显著短于业务查询耗时，否则可能刚写完缓存，锁就过期被别人抢占
最容易被忽略的三个细节
击穿防护失效往往不出现在主逻辑，而藏在边界判断和类型处理里：
-
errors.Is(err, redis.Nil)才是正确判空方式，err == redis.Nil永远为 false（因为redis.Nil是变量，不是常量） - JSON 反序列化后字段全零值 ≠ 缓存空结果，需额外校验业务字段（如
item.ID == 0 && item.Name == ""） -
singleflight.Do返回的v是interface{}，类型断言失败会导致 panic，必须加if v, ok := v.(*Item); !ok { return nil, errors.New("type assert failed") }
