Redis缓存高频读、低频写数据可将响应压至亚毫秒级，但需严控一致性、超时、重试、连接池及穿透/击穿/雪崩防护，否则引发系统性风险。
直接用 Redis 缓存高频读、低频写的查询结果，能跳过数据库 IO，把响应从几十毫秒压到亚毫秒级。前提是缓存逻辑不破坏数据一致性，且连接和超时配置得当——否则反而引入雪崩或穿透风险。
redis.NewClient 初始化时必须设对超时和重试
默认 rdb := redis.NewClient(&redis.Options{...}) 不设超时，网络抖动时请求会卡住几秒，拖垮整个 HTTP 请求。生产环境至少配三项：
-
ContextTimeoutEnable: true—— 启用上下文超时控制 -
MinIdleConns: 10和PoolSize: 50—— 避免连接池耗尽（尤其在 burst 流量下） -
MaxRetries: 2和MinRetryBackoff: 8 * time.Millisecond—— 防止瞬时故障导致批量失败
漏掉 MinIdleConns 是常见坑：冷启动后第一个请求要建连接，延迟突增；没设 MaxRetries 则单点 Redis 暂时不可用时，rdb.Get(ctx, key) 直接返回 error，业务层若没兜底就炸。
缓存读写必须遵循 “先查缓存、查不到再查 DB、写回缓存” 流程
这不是伪代码建议，是防止缓存与 DB 不一致的底线。典型错误是：
- 更新 DB 后只删缓存（
rdb.Del(ctx, key)），但删完瞬间有并发读，会把旧值重写进缓存（脏读） - 读逻辑里没处理
redis.Nil错误，直接 panic 或返回空对象，前端看到 500
正确写法示例：
val, err := rdb.Get(ctx, "user:123").Result()
if err == redis.Nil {
// 查 DB
user, dbErr := db.FindUserByID(123)
if dbErr != nil {
c.JSON(500, gin.H{"error": "db fail"})
return
}
// 写回缓存，带过期时间（防雪崩）
_ = rdb.Set(ctx, "user:123", user, 10*time.Minute).Err()
c.JSON(200, user)
return
} else if err != nil {
c.JSON(500, gin.H{"error": "redis fail"})
return
}
c.JSON(200, val)
避免缓存穿透、击穿、雪崩的三个硬控制点
这三类问题不是理论风险，上线后一小时就能触发：
-
穿透：查
user:-1这种非法 ID，缓存无，DB 也无，大量打穿到底层。解决：对空结果也缓存（如rdb.Set(ctx, "user:-1", "nil", 2*time.Minute)），并加布隆过滤器预检 -
击穿：热点 key（如首页 banner）过期瞬间大量并发读。解决：用
rdb.SetNX+ goroutine 异步重建，或设置随机过期偏移（time.Duration(rand.Int63n(60)) * time.Second） -
雪崩：大量 key 同一时刻过期。解决：所有缓存写入时加随机 TTL 偏差，别全设
10*time.Minute
很多人忽略的是：Redis 客户端的 context.WithTimeout 必须比业务超时短 200ms 以上，否则超时后 goroutine 还在等 Redis 响应，堆积泄漏。
本地缓存 + Redis 二级缓存适合配置类数据
比如权限菜单、系统开关这类几乎不变更的数据，用 github.com/patrickmn/go-cache 做一级缓存，TTL 设 4 小时；Redis 作二级，TTL 设 24 小时。好处是：
- 99% 的请求走内存，
cache.Get(key)耗时 ≈ 50ns - Redis 只承担“兜底刷新”角色，压力极小
- 服务重启后本地缓存为空，自动降级走 Redis，不影响可用性
注意别反着来——把高频变动的用户数据放本地缓存，节点间状态就不同步了。
