Go微服务与分布式缓存的应用实践-Golang-PHP中文网

根本原因是db与缓存操作天然非原子：即使数据库事务提交成功，redis删除操作仍可能因网络超时、连接中断或实例宕机而失败，导致旧值残留；并发下更易发生“缓存污染”，即a删缓存→b更新db→a回源写入旧值。

go微服务与分布式缓存的应用实践

根本原因不是代码写错了，而是 DB 和缓存操作天然非原子：哪怕 tx.Commit() 成功，redis.Del() 仍可能因网络超时、连接中断或 Redis 实例宕机而失败。一旦失败，旧值就卡在缓存里，后续读请求持续拿到脏数据。

这不是理论方案，而是可直接抄的最小可行组合：先删缓存 → 更新 DB → 延迟再删一次缓存，并在读取时用版本号兜底。

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

第一次 DEL 是为了尽快让后续读请求穿透到 DB；延迟（比如 500ms）后的第二次 DEL 是为了覆盖“B 更新 DB 后、A 回源写缓存”这个窗口期
读取时必须校验版本：SELECT id, name, version FROM users WHERE id = ?，比对缓存中 version 字段是否匹配，不匹配则丢弃缓存并触发回填
版本号不要用时间戳——它可能因服务器时钟漂移导致乱序；推荐用数据库自增字段或 UPDATE ... RETURNING version 获取
延迟时间不能拍脑袋：需结合业务 RT（比如 P99 数据库更新耗时是 320ms），设为 1.5 倍较稳妥

DB 更新后不直连 Redis，而是发消息，把缓存维护变成异步、可重试的独立环节。

关键不是用 Kafka 还是 RabbitMQ，而是确保消息不丢：推荐用“本地事务表 + 定时扫描”模式——DB 更新和消息记录写入同一事务，再由后台 goroutine 轮询发送
消费者只做一件事：redis.Del(ctx, "user:"+id)，绝不在这儿调 DB 或调其他服务；幂等靠 key 本身实现（重复 DEL 无副作用）
监控重点不是“消息发没发”，而是 redis.Del 的返回值：连续大量返回 0（key 不存在）说明上游缓存写入链路可能中断，不是消费者问题
别指望消息 100% 实时——它解决的是可靠性，不是低延迟；对一致性要求极高的字段（如账户余额），仍需同步删缓存+版本校验

go-zero 封装了多级缓存，但默认行为容易掩盖一致性问题。

cache.WithRedis 默认启用自动回写（auto fill），即缓存未命中时自动查 DB 并写入两级缓存——这会放大“缓存污染”风险，务必关掉：cache.WithRedis(...).WithAutoFill(false)
它的本地缓存默认 TTL 是 0（永不过期），但没配清理策略，内存可能缓慢泄漏；建议显式设 cache.WithExpire(time.Minute)
删除操作走的是 Del 方法，但底层对 Redis 是 DEL，对本地缓存是 delete map key——两者不同步失败时无 fallback，需自己加重试逻辑
最易忽略的一点：go-zero 的缓存 key 拼接默认不包含版本号，你得手动把 version 加进 key，比如 "user:" + id + ":" + strconv.FormatInt(version, 10)

真正难的不是选哪种方案，而是明确每条数据的“一致性 SLA”：用户昵称允许秒级不一致，订单状态必须强一致，而库存需要分布式锁+CAS。缓存不是开关，是光谱——从本地 map 到 Redis Cluster，每个环节都要按数据敏感度配权。