Go微服务缓存策略首选本地缓存（bigcache或golang-lru）+Redis旁路模式，bigcache适合读多写少、百万级QPS场景，通过分片锁提升并发性能但需手动管理过期；golang-lru支持精确TTL但高并发写易成瓶颈；sync.Map仅适用于少量元数据；Redis旁路模式需结合空值缓存、互斥锁、TTL随机偏移等手段防范穿透、击穿、雪崩。
Go微服务缓存策略不能只选“快”的，得看数据一致性要求、QPS规模、故障容忍度——本地缓存（bigcache或golang-lru）+ Redis旁路模式是当前生产环境最稳的组合；Redis高可用不是配个哨兵就行，必须主从+连接池+健康检查三者联动。
本地缓存用 bigcache 还是 golang-lru？
选型取决于你的读写比和内存敏感度：
-
bigcache适合读多写少、百万级QPS场景：它把键哈希分片后独立锁，避免全局锁争用；但不支持带过期时间的自动淘汰，得自己加定时清理逻辑 -
golang-lru更适合中小规模、需要精确TTL控制的业务：它内置expirable.LRU模块，支持按key设置单独过期时间；但所有操作都走sync.RWMutex，高并发写多时会成瓶颈 - 别直接用原生
sync.Map做缓存：它没有容量限制和淘汰机制，OOM风险极高；仅适合临时存储少量固定key的元数据
Redis旁路模式下怎么避免缓存穿透/击穿/雪崩？
旁路模式（Cache-Aside）本身不解决这三类问题，必须手动加固：
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 穿透：对空结果也缓存，比如
rdb.Set(ctx, "user:999999", "", 2*time.Minute)，值设为空字符串，避免反复查DB；更彻底的方案是前置布隆过滤器（roaringbitmap或google/bloom）拦截非法ID - 击穿：热点key失效瞬间大量请求打穿缓存，用
redis.Mutex（基于SET key val NX PX 30000）实现互斥重建，其他goroutine等待而非直接查库 - 雪崩：避免大量key同一时间过期，给TTL加随机偏移，比如
expire := 60 + rand.Intn(30)秒；关键数据用永不过期+主动更新机制
Redis高可用配置里最容易被忽略的三个点
很多团队配了哨兵或集群，但线上仍频繁超时或连接失败，问题常出在这儿：
立即学习“go语言免费学习笔记（深入）”；
- 连接池没调优：
PoolSize不能只看峰值QPS，要按下游实例数×平均并发数估算；MinIdleConns至少设为PoolSize / 2，防止突发流量时反复建连 - 健康检查没落地：光配
Ping不够，得在服务启动后起time.Ticker定期执行rdb.Do(ctx, "INFO", "replication").Val()，确认主从同步延迟 - 超时参数分层缺失：只设
ReadTimeout会导致网络抖动时goroutine堆积；必须同时配Context超时（如context.WithTimeout(ctx, 100*time.Millisecond)）和客户端级ReadTimeout（建议≤Context超时的80%）
复杂点不在组件选型，而在各层超时、重试、熔断的配合节奏——比如Redis连接池超时设成300ms，但业务层context超时只给了100ms，结果永远等不到池返回就先cancel了，白白浪费连接资源。
