缓存双删不是简单删两次，第二次删除必须延迟执行以确保DB写入完成，且需幂等、解耦、监控返回值，并适配本地缓存与主从延迟。
缓存双删为什么不是“删两次就完事”
双删（先删缓存、再更新DB、再删缓存）常被当作“保一致”的银弹，但实际中Delete操作本身可能失败、重试逻辑缺失、或与DB事务脱钩，导致缓存残留脏数据。更关键的是：第二次删缓存如果在DB写入完成前发生，等于白删——因为后续读请求会把旧值重新塞进缓存。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 第二次删缓存必须带延迟（如 100–500ms），确保 DB 写事务已落盘；用
time.AfterFunc或消息队列解耦，别阻塞主流程 - 删缓存操作要幂等：对同一个
cacheKey多删几次不能出错，Redis 的DEL本身是安全的，但若中间加了本地缓存层，得自己兜底 - 避免在事务内调用
redis.Client.Del：Go 的sql.Tx不感知 Redis，一旦 DB 回滚而缓存已删，就会出现“缓存空、DB有值”的短暂不一致
Go 里怎么安全触发延迟双删
直接用 time.Sleep 在 HTTP handler 里硬等，会卡住 goroutine，放大延迟；用 time.AfterFunc 又面临进程重启时任务丢失。真正可用的方案得兼顾轻量和可靠性。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用带 TTL 的 Redis key 做“延迟信号”：写 DB 后，
SET cacheKey_delay true EX 300，另起一个 goroutine 监听这个 key 过期事件（通过redis.PubSub+__keyevent@0__:expired），过期后执行第二次DEL - 如果不用 PubSub，退一步用定时轮询：启动一个常驻 goroutine，每秒查一次
KEYS *_delay（仅开发环境），生产环境改用有序集合ZADD delay_queue timestamp cacheKey+ZRANGEBYSCORE扫描 - 别依赖
context.WithTimeout包裹第二次删——超时只取消 goroutine，不撤销已发的 Redis 命令
Redis pipeline 和事务在双删里反而容易翻车
有人想用 redis.Pipeline 把两个 DEL 包在一起发，或者用 MULTI/EXEC 保证原子性，但这没意义：缓存双删本来就不需要原子性，而且 pipeline 无法解决“删早了”的时序问题；MULTI 在 Redis 7.0 前还不支持带条件的执行，根本防不住并发写。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 放弃 pipeline / MULTI 做双删协调——它们解决的是“多个命令一起成功或失败”，而双删要解决的是“命令在什么时间点执行”
- 如果 DB 更新用了
UPDATE ... WHERE version = ?乐观锁，那第二次删缓存前可以顺手GET一下对应version字段，确认没被其他写覆盖，再删；这比纯延迟更准 - 监控
DEL返回值：redis.IntCmd.Result()返回0表示 key 不存在，不是错误；返回-1或 err 才真要告警
本地缓存（如 freecache）和 Redis 联合双删的坑
加了本地缓存后，“删 Redis”不等于“删干净”——本地副本还在内存里，下次读直接命中，完全绕过 Redis。这时候双删必须变成“三删”：删本地 → 删 Redis → 延迟删 Redis，但本地删没法跨进程同步。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 本地缓存键必须带服务实例标识，比如
user:123:node-01，这样删的时候能定向清除；否则删了也是随机命中 - 用 Redis 的
PUBLISH通知其他节点清理本地缓存，topic 统一为cache:invalidate:user:123，各节点订阅后调用localCache.Delete - 别给本地缓存设永不过期：哪怕 Redis 双删失败，本地缓存也得靠自身 TTL（如 10s）兜底，否则脏数据会卡死
