用 redis + go-redis v9 实现分布式缓存的最小可行路径是:全局复用 *redis.client,配置合理 poolsize 并 ping 验证连接;通过空值缓存+随机 ttl 应对穿透,singleflight 缓解击穿,错峰过期+二级缓存防雪崩;更新采用先 db 后删缓存策略,异步重试失败删除;本地缓存仅用于低一致性场景,且须以 redis 为权威源。

用 Redis + go-redis 实现分布式缓存的最小可行路径
Go 本身没有内置分布式缓存,必须依赖外部存储(如 Redis、etcd)+ 客户端库协同工作。生产中最常用的是 Redis 配合 github.com/redis/go-redis/v9(即 go-redis v9),它支持连接池、Pipeline、Lua 脚本和自动重连。
直接初始化一个全局 *redis.Client 并复用即可,别每次操作都新建 client:
var rdb *redis.Client
func init() {
rdb = redis.NewClient(&redis.Options{
Addr: "localhost:6379",
Password: "",
DB: 0,
PoolSize: 20, // 根据 QPS 调整,一般 10–50
})
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
if err := rdb.Ping(ctx).Err(); err != nil {
log.Fatal("failed to connect to redis:", err)
}
}
-
PoolSize过小会导致阻塞,过大可能耗尽 Redis 连接数(默认 maxclients=10000) - 务必调用
Ping()验证连接,否则首次Get()失败才暴露问题 - 不要在 handler 里用
context.Background(),应传入带超时的 request context
缓存穿透、击穿、雪崩的 Go 层应对策略
这三类问题不是 Redis 自己能解决的,得在 Go 代码里加逻辑。比如缓存穿透(查不存在的 key)最简单有效的方式是「空值缓存」+「随机过期时间」:
func GetUserInfo(ctx context.Context, uid int64) (*User, error) {
key := fmt.Sprintf("user:%d", uid)
val, err := rdb.Get(ctx, key).Result()
if err == redis.Nil {
// 查询 DB
u, dbErr := db.FindUserByID(uid)
if dbErr != nil {
return nil, dbErr
}
if u == nil {
// 写空值,TTL 加个 1–3 分钟随机偏移防集中失效
rdb.Set(ctx, key, "", 2*time.Minute + time.Duration(rand.Intn(60))*time.Second)
return nil, nil
}
rdb.Set(ctx, key, u, 30*time.Minute)
return u, nil
}
if err != nil {
return nil, err
}
return jsonToUser(val), nil
}
- 空值不能设固定 TTL,否则大量空 key 同时失效会引发穿透风暴
- 缓存击穿(热 key 过期瞬间大量请求打到 DB)建议用
singleflight包做请求合并 - 雪崩靠错峰过期(如 baseTTL + rand.Intn(120) 秒)+ 二级缓存(本地内存 cache)缓解
如何安全地更新缓存与数据库(Cache-Aside 模式)
先更新 DB,再删缓存(而非更新缓存),这是目前最稳妥的做法。删缓存失败怎么办?加重试 + 日志告警,但别卡住主流程:
func UpdateUserName(ctx context.Context, uid int64, name string) error {
tx := db.Begin()
if err := tx.Model(&User{}).Where("id = ?", uid).Update("name", name).Error; err != nil {
tx.Rollback()
return err
}
if err := tx.Commit().Error; err != nil {
return err
}
// 异步删缓存:不阻塞,失败也不回滚事务
go func() {
if err := rdb.Del(ctx, fmt.Sprintf("user:%d", uid)).Err(); err != nil {
log.Printf("failed to delete cache for user %d: %v", uid, err)
// 可推送到延迟队列重试,或发告警
}
}()
return nil
}
- 千万别「先删缓存再更新 DB」——中间若有并发读,会把旧值重新写进缓存(脏数据)
- 更新缓存比删缓存风险更高:DB 更新成功但缓存写失败,会导致不一致且难以察觉
- 删缓存失败日志必须可检索,线上要配置告警(比如 1 分钟内连续 5 次删缓存失败)
本地缓存(BigCache / Freecache)和 Redis 联动的边界在哪
本地缓存只适合「读多写少、key 空间可控、允许短暂不一致」的场景,比如配置项、用户权限白名单。一旦涉及多实例状态同步,就必须以 Redis 为准:
- 不要用本地缓存存订单、库存等强一致性数据;哪怕加了 Redis 删除通知,也难保消息丢失或延迟
- 如果用了
BigCache,注意shards数量别设太小(建议 16–64),否则热点 shard 锁争用严重 - 本地缓存命中后,仍建议异步触发一次
GET到 Redis,用于探测是否已过期(refresh-ahead),但别阻塞返回
分布式缓存真正的复杂点不在连接或序列化,而在于「什么时候不该缓存」「缓存失效后怎么兜底」「不同服务对同一份数据的过期策略是否对齐」——这些没法靠工具解决,得在业务模型里显式定义。
golang免费学习笔记(深入):立即使用
在学习笔记中,你将探索golang的核心概念和高级技巧!











