直接用 redis.Client 做微服务缓存易出连接泄漏、超时缺失、序列化不一致等问题；需显式设 PoolSize、键加服务前缀、统一 JSON 序列化、读操作加 timeout、写慎用 SETNX，并结合配置中心、哨兵/集群适配、空值缓存、本地 LRU 二级缓存及透传 context 防 goroutine 泄漏。
为什么直接用 redis.Client 做微服务缓存容易出问题
微服务场景下，每个服务实例都直连 Redis，看似简单，但会快速暴露连接泄漏、超时配置缺失、序列化不一致等问题。比如一个服务启用了 10 个 goroutine 并发写缓存，却没设置 redis.Options.PoolSize，实际可能创建数百个空闲连接，Redis 服务端很快拒绝新连接。
常见错误现象包括：redis: connection pool timeout、EOF、缓存值反序列化失败（如 struct 字段 tag 不一致导致 json.Unmarshal 忽略字段）。
- 务必显式设置
PoolSize（建议设为并发请求数的 2–4 倍，最小不低于 10） - 所有缓存键必须带服务前缀，例如
"user-service:user:123"，避免跨服务键冲突 - 统一使用
json.Marshal/json.Unmarshal，禁用gob（跨语言/版本不兼容） - 读操作加
context.WithTimeout，写操作慎用SETNX替代SET—— 多数场景不需要强互斥，反而增加延迟
如何让缓存操作自动支持服务发现与故障转移
硬编码 Redis 地址（如 "localhost:6379"）在容器化部署中必然失效。你需要把地址来源从代码移出，交由配置中心或环境变量驱动，同时封装一层自动重试和哨兵/集群适配逻辑。
使用 github.com/go-redis/redis/v8 时，根据部署模式选择初始化方式：
立即学习“go语言免费学习笔记（深入）”；
- 单节点：用
redis.NewClient，配合redis.FailoverOptions指向哨兵地址列表 - Redis Cluster：用
redis.NewClusterClient，传入至少 3 个 seed node 地址（如[]string{"redis-node-0:7000", "redis-node-1:7000", "redis-node-2:7000"}） - 所有客户端都应设置
MinIdleConns（建议 5）和MaxConnAge（建议 30 * time.Minute），防止连接老化后被中间设备断连
示例片段：
opt := &redis.ClusterOptions{
Addrs: []string{"redis-cluster:7000"},
Password: os.Getenv("REDIS_PASSWORD"),
MaxRedirects: 8,
}
client := redis.NewClusterClient(opt)
缓存穿透、击穿、雪崩在 Go 微服务里怎么防
这三类问题不是 Redis 自身能解决的，必须在 Go 业务层拦截。关键不是“加锁”或“布隆过滤器”，而是分清场景、选对粒度。
- 缓存穿透（查不存在的 key）：在 DAO 层对空结果也缓存（如
SET user:9999 "" EX 60），值设为空字符串而非nil；高频 ID 类查询可前置用google.golang.org/grpc/metadata携带校验位，或引入轻量级布隆过滤器（如github.com/yourbasic/bloom） - 缓存击穿（热 key 过期瞬间大量请求打穿）：用
redis.SetNX+ 后台异步加载，而不是在请求线程里加锁；或者干脆设永不过期，靠定时任务刷新 - 缓存雪崩（大量 key 同时过期）：过期时间加随机偏移，例如
rand.Int63n(300) + 3600（基础 1 小时 + 最多 5 分钟浮动）
注意：不要在 HTTP handler 里直接调 client.Get(ctx, key) 后判断 err == redis.Nil 就去查 DB —— 这会放大击穿。应该先走本地 LRU（如 github.com/hashicorp/golang-lru）做二级缓存，再兜底远程 Redis。
为什么 context.Context 必须传给每个 Redis 调用
微服务链路中，上游超时（如 HTTP 请求设了 500ms timeout）必须能及时中断下游 Redis 调用，否则 goroutine 泄漏、连接卡死、监控指标失真。Go-Redis v8 强制要求传 context.Context，但很多人只传 context.Background()，等于放弃控制权。
正确做法是：从 HTTP handler 或 gRPC 方法入口提取 context，透传到缓存操作，并确保它携带 deadline：
- HTTP handler 中用
r.Context()，不要自己 new - 如果需要延长缓存操作时间（比如 DB 查询慢），用
ctx, cancel := context.WithTimeout(parentCtx, 200*time.Millisecond)，并记得defer cancel() - 禁止在 goroutine 里直接用
context.Background()调 Redis —— 一旦父 context 取消，子 goroutine 不知道该停，资源就悬着
最容易被忽略的一点：redis.Client 的 WithContext 方法只是返回新 client 实例，不改变原实例行为。你必须把带 context 的 client 作为参数传下去，或用 closure 封装，而不是期望“设一次全局生效”。
