Go语言无分布式缓存一致性保障，需外部机制协同；本地缓存+Redis双写不一致主因是DB与缓存操作非原子，推荐延迟双删加版本号校验，将不一致窗口压缩至秒级并确保最终收敛。
Go 语言本身不提供分布式缓存一致性保障，sync.Map 或 map + sync.RWMutex 只能保证单进程内线程安全，跨实例（多副本、微服务）时必须靠外部机制协同——这是最常被忽略的前提。
为什么本地缓存 + Redis 双写会不一致
典型场景：先更新 DB，再删 Redis；或先删 Redis，再更新 DB。任一环节失败（如 DB 成功但 Redis 删除超时/网络中断），就会导致缓存与 DB 不一致。
- DB 写成功但缓存操作失败，旧值残留 → 读到脏数据
- 并发写入时，A 删缓存、B 更新 DB、A 再写缓存（回源老值）→ 缓存被覆盖为过期数据
-
SET替代DEL更危险：一旦 DB 更新失败，缓存里存的是彻底错误的快照
推荐用「延迟双删 + 版本号」组合兜底
不是追求“绝对一致”，而是把不一致窗口压缩到秒级，并确保最终收敛。核心是让缓存失效可重试、可验证。
- 第一次
DEL在 DB 更新前：提前清掉可能正在被读的旧缓存 - DB 更新成功后，启动异步 goroutine，休眠 100–500ms，再执行第二次
DEL：覆盖“先查缓存 → 缓存失效 → 查 DB → 写缓存”这个竞态窗口 - 缓存 value 中嵌入 DB 记录的
updated_at或自增version字段，读取时比对：若缓存 version DEL 并回源
// 示例：读取时校验版本
func GetUserInfo(id int) (*User, error) {
data, err := redis.Get(ctx, "user:"+strconv.Itoa(id)).Bytes()
if err == redis.Nil {
return loadFromDBAndCache(id)
}
var u User
json.Unmarshal(data, &u)
// 检查缓存中的 version 是否落后于 DB
dbVer := getDBVersion(id) // SELECT version FROM users WHERE id=?
if u.Version < dbVer {
redis.Del(ctx, "user:"+strconv.Itoa(id))
return loadFromDBAndCache(id)
}
return &u, nil
}
用消息队列解耦缓存更新（适合中高流量）
DB 更新后不直接操作 Redis，而是发一条 user_updated 消息到 Kafka/RabbitMQ，由独立消费者负责删缓存。好处是失败可重试、削峰、解耦 DB 和缓存逻辑。
立即学习“go语言免费学习笔记（深入）”；
- DB 事务提交后，同步发送消息（建议用本地事务表 + 定时扫描，避免消息发送失败导致丢失）
- 消费者需幂等：对同一
user_id的多次DEL无副作用，但要容忍重复投递 - 不要在消费者里做复杂计算或调用其他服务——只做
DEL或SET，否则又引入新故障点 - 监控
redis.del返回值：如果返回 0，说明 key 不存在，可能是已过期或从未写入，无需告警；但连续大量返回 0 需检查缓存写入链路是否中断
真正难的不是“怎么删缓存”，而是确认“什么时候该删”以及“删完谁来补”。很多团队卡在缓存穿透和击穿上，其实是没把缓存加载逻辑和 DB 查询边界划清楚——比如一个接口既查用户又查权限，却只用 user:123 当 key，导致权限变更时无法精准失效。
