单靠redis不够，必须本地缓存+分布式缓存分层组合并主动防御穿透、击穿、雪崩；go-redis/v9需设context超时（100–200ms）、合理连接池（cpu核数×4～8）、区分redis.nil与真实错误，本地缓存高频更新场景优先选bigcache而非sync.map。
直接上结论：单靠 Redis 不够，必须本地缓存 + 分布式缓存分层组合，且要主动防御缓存穿透、击穿、雪崩——否则 QPS 上 5 万就容易抖动，到 10 万级可能直接拖垮数据库。
go-redis/v9 查询时如何避免阻塞主线程
很多人在 redisClient.Get(ctx, key) 后没处理 context 超时或连接异常，导致 goroutine 卡死或堆积。这不是 Redis 慢，是客户端没设限。
- 必须给
context.WithTimeout显式设超时，建议 100–200ms（比数据库查询快一个数量级） - 不要复用全局
context.Background()，每个请求应带独立ctx，便于 cancel 和 trace - 连接池大小需匹配实际并发：默认
PoolSize: 10在 3w+ QPS 下会成为瓶颈，建议设为 CPU 核数 × 4～8 - 遇到
redis.Nil错误（key 不存在）要区分处理，不能和网络错误混为一谈
本地缓存选 sync.Map 还是 bigcache
sync.Map 看起来“原生又简单”，但只适合读远多于写的场景；高频更新下它的删除延迟和内存碎片反而拖累 GC。真正扛 10w+ QPS 的服务基本都切到了 bigcache 或 freecache。
-
sync.Map：适合配置类数据（如开关、白名单），写操作 -
bigcache：底层用分片 + 环形缓冲区，写入不触发 GC，适合用户画像、推荐列表等每秒数百次更新的热点数据 - 注意
bigcache不支持 TTL 自动过期，得靠外部定时器或写入时附带时间戳自行判断 - 如果业务要求强一致性（比如库存），本地缓存必须配合版本号或 CAS 机制，不能只靠过期时间
怎么防缓存穿透：空值和布隆过滤器不是二选一
只存空值（redisClient.Set(ctx, key, "", time.Minute)）能挡一部分，但恶意请求量大时，Redis 里堆满无效 key，内存和 CPU 都浪费；只用布隆过滤器，初始化和更新成本高，且存在误判率——真实线上必须两者叠加。
- 布隆过滤器放在前置网关或服务入口，用
golang.org/x/exp/bloom或github.com/yourbasic/bloom实现，加载全量合法 ID 到内存 - 过滤器判断“肯定不存在”就直接返回 404，不进后续逻辑
- 若判断“可能存在”，再查 Redis；未命中时，**仅对确定存在的业务实体才写空值**（例如查用户，ID 格式合法但 DB 无记录 → 写空值；ID 格式非法 → 不写）
- 空值 key 必须带前缀隔离，比如
empty:user:id_abc，避免和正常数据冲突
缓存更新时机：先删缓存还是先改 DB
“先删缓存再改 DB”看似简单，但在并发写场景下极易出现脏数据——DB 更新成功，但缓存删除失败或延迟，旧值又回填进来。更稳妥的是“延时双删 + 版本号校验”。
- 写操作流程：改 DB → sleep 100–500ms → 再删缓存（给主从同步留出窗口）
- 读操作中，若从 DB 查到新数据，写回缓存时必须带上版本字段（如
updated_at时间戳或自增 revision） - 缓存 value 里嵌入版本，下次读到旧版本数据时拒绝使用，强制回源
- 对一致性要求极高的字段（如余额），干脆放弃缓存，走数据库直查 + 连接池优化
最常被忽略的一点：缓存键设计不是拼接完事，而是要包含业务语义边界。比如用户订单列表缓存用 orders:user_id:123:status:paid，而不是 orders:123——后者一旦 status 变更，整个列表失效，粒度太粗；前者可单独刷新某状态子集，降低穿透压力。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
