主从延迟下缓存一致性必须用时间戳+版本号双校验，否则删缓存后读从库会回填旧值；需主库生成版本号、原子写入Redis、L1缓存含Version字段、动态TTL绑定主库写入时间戳，并主动感知从库延迟降级读主库。
主从延迟下缓存一致性不能靠“删完再等”，必须用时间戳+版本号双校验，否则 Redis 主库已更新、从库还没同步，L1/L2 就会返回过期旧值。
为什么「先删缓存再更新DB」在主从架构里更危险
MySQL 主从延迟常见于 50–500ms，尤其在大事务或网络抖动时。此时若按常规流程 DeleteCache → UpdateDB，DB 写入的是主库，但读请求可能打到从库（尤其用了读写分离中间件），而缓存已删——结果是：请求穿透到从库读出旧数据，再回填到 L1/L2，彻底污染整条缓存链路。
常见错误现象：GET user:1001 返回 5 分钟前的头像 URL，但 DB 主库明明刚更新过；监控显示 Redis TTL 正常，PTTL 剩余时间也合理，问题却持续存在。
- 别依赖“删缓存后 DB 必然立刻可见”——这是单点假设，主从场景不成立
- 别在应用层加
time.Sleep(200 * time.Millisecond)等从库同步——延迟不可控，且阻塞写路径 - 读请求若走从库，必须携带主库最新 binlog 位点或 GTID，否则无法判断该读是否“安全”
用 write-after-read + 版本号兜底读取旧值
核心思路：不阻止旧值被读出，而是让旧值“自证无效”。每次写 DB 时，同时写一个单调递增的版本号（如 user_version 字段或独立 user:1001:ver key），读缓存时强制校验版本。
立即学习“go语言免费学习笔记（深入）”；
读流程示例：
func GetUser(ctx context.Context, uid int64) (*User, error) {
// 1. 先查 L1
if u, ok := l1.Get(fmt.Sprintf("user:%d", uid)); ok {
// 2. 检查本地缓存是否带 version 字段且匹配 L2 最新 version
if u.Version != getRedisVersion(ctx, uid) {
l1.Delete(fmt.Sprintf("user:%d", uid))
return nil, ErrCacheStale
}
return u, nil
}
// 3. L1 miss → 查 L2（Redis）
data, _ := l2.Get(ctx, fmt.Sprintf("user:%d", uid))
ver, _ := l2.Get(ctx, fmt.Sprintf("user:%d:ver", uid))
if data != nil && ver != nil && string(ver) == string(data.Version) {
l1.Set(fmt.Sprintf("user:%d", uid), data, shortTTL)
return data, nil
}
// 4. L2 不一致 → 查主库（显式指定 master）
u, err := db.QueryRowContext(masterCtx, "SELECT * FROM users WHERE id = ? FOR UPDATE", uid).Scan(...)
if err == nil {
l2.SetEX(ctx, fmt.Sprintf("user:%d", uid), u, ttl)
l2.SetEX(ctx, fmt.Sprintf("user:%d:ver", uid), u.Version, longTTL)
l1.Set(fmt.Sprintf("user:%d", uid), u, shortTTL)
}
return u, err
}- 版本号必须由主库生成并写入（如
AUTO_INCREMENT、REPLACE INTO ... SELECT MAX(ver)+1或用 RedisINCR） - L2 中版本 key 和数据 key 必须原子写入（用 Redis
PIPELINE或WATCH/MULTI） - L1 缓存结构需包含
Version字段，不能只存原始 struct
Redis 读从节点时如何识别主从延迟风险
go-redis/v9 提供 ReadOnly() 选项，但它默认读任意从节点，不感知延迟。真要安全读从库，得主动查 INFO REPLICATION 中的 slave_repl_offset 和主库 master_repl_offset 差值。
实操建议：
- 在 Redis 客户端初始化时，定期（如每 3 秒）用
client.Do(ctx, "INFO", "REPLICATION").Val()解析从库延迟，缓存在本地变量中 - 对敏感读请求（如用户中心关键字段），若检测到从库延迟 > 100ms，自动降级到主库读，而非硬性拒绝
- 避免在业务代码里反复调用
INFO——它本身有开销，应由单独 goroutine 维护延迟快照 - 不要用
WAIT 1 1000强制同步——它阻塞写请求，放大主从延迟的副作用
L1 缓存 TTL 必须动态绑定主库写入时间戳
静态 TTL（如固定 5 分钟）在主从延迟下毫无意义。L1 的存活时间应取决于“主库写入时间 + 预估最大延迟”，而非业务逻辑认为的“应该缓存多久”。
写流程中需记录主库实际写入时间：
// 更新 DB 后立即获取当前主库时间戳
var ts int64
_ = masterDB.QueryRow("SELECT UNIX_TIMESTAMP()").Scan(&ts)
// 写入 Redis 时带上这个 ts
l2.SetEX(ctx, fmt.Sprintf("user:%d:ts", uid), ts, longTTL)
// L1 设置 TTL = max(1min, 主库 ts + 预估延迟 - 当前时间)
l1.SetWithTTL(fmt.Sprintf("user:%d", uid), u, time.Until(time.Unix(ts+200, 0)))- 预估延迟取值建议：线上统计 P99 主从延迟（如 180ms），再加 20% 安全余量
- 不能用
time.Now().Unix()——容器时钟漂移会导致 L1 过早失效或永久不清理 - 如果 Redis 使用了
replica-announced-ip，可结合ROLE命令识别当前连接是否为从节点，再决定是否启用时间戳校验
主从延迟不是网络问题，是架构契约的一部分。缓存一致性方案里最易被忽略的，是把“读从库”当成无条件优化——它必须配套版本校验、延迟感知和动态 TTL，三者缺一不可。否则你写的每一行 l1.Delete，都在给不一致埋雷。
