singleflight 可防止缓存击穿和重复更新：同 key 请求合并为一次执行，其余协程共享结果；需配合读写锁保护缓存存储、延迟双删+短 TTL 保障一致性、版本号或原子操作避免并发覆盖。
用 singleflight 防止缓存击穿和重复更新
当多个协程同时发现缓存失效，都去加载数据并回填缓存，会造成下游服务压力激增（缓存击穿），还可能因写入顺序不确定导致最终缓存值不一致。Go 标准库 golang.org/x/sync/singleflight 可以让同一 key 的多次请求合并为一次实际执行，其余协程等待结果返回。
使用方式很简单：封装一个带 singleflight.Group 的缓存更新函数：
- 定义全局或结构体内的
singleflight.Group实例 - 在 Get 或 Load 方法中，先查缓存；未命中时调用
Do(key, fn)，其中fn执行真实加载+写缓存逻辑 -
Do保证同 key 只有一个fn运行，其他协程共享其返回值（含 error）
加读写锁控制缓存写入临界区
即使有 singleflight，如果缓存本身是 map 等非线程安全结构，多协程并发写仍会 panic。对缓存存储层（如内存 map、本地 LRU）需加锁保护。
推荐使用 sync.RWMutex：
立即学习“go语言免费学习笔记（深入）”；
- 读操作用
RLock()/RUnlock()，允许多个协程并发读 - 写操作（Set/Replace/Delete）用
Lock()/Unlock()，串行化写入 - 注意避免在持有写锁时调用可能阻塞或依赖外部服务的逻辑（比如远程 DB 查询），否则会拖慢所有写请求
采用延迟双删 + 设置合理过期时间
缓存与数据库一致性不能靠强同步（性能差），常用策略是「先更 DB，再删缓存」。但删缓存失败会导致脏数据。更稳健的做法是：
- 更新数据库成功后，立即删除缓存（第一删）
- 启动一个异步 goroutine，在几百毫秒后再次删除该 key（第二删），覆盖因网络抖动、中间件重试等导致的第一删失败场景
- 缓存本身设置较短 TTL（如 1–5 分钟），作为兜底保障，防止双删全部失败后长期脏数据
用原子操作或版本号避免并发覆盖
当多个协程几乎同时完成数据加载并试图写入缓存，后写入者可能覆盖先写入者的结果（尤其在 singleflight 失效或跨实例部署时）。可通过以下方式降低风险：
- 缓存 value 中嵌入时间戳或版本号，写入前比对当前缓存中的版本，仅当新版本更高才更新（CAS 语义）
- 使用
atomic.Value存储整个缓存项（适合只读频繁、更新较少的场景） - 在分布式环境，考虑引入 Redis 的
SET key value NX EX seconds命令，利用服务端原子性保证单次写入
不复杂但容易忽略的是：缓存更新逻辑要幂等，失败要可重试，且所有路径（成功/失败/超时）都要明确处理缓存状态。把加载、写缓存、错误回退封装成一个原子单元，再套上 singleflight 和锁，就能兼顾性能与一致性。
