如何保证Redis与Mysql的双写一致性？

前言：

在实际开发中，MySQL 与 Redis 的双写一致性问题 是一个非常常见又复杂的技术难点。本文将就其产生的原因、触发场景、解决方案、代码示例 进行完整的讲解，帮助大家更好地在实际的项目开发过程中采用合适的方式保证两者间的双写一致。

🔍 一、什么是双写一致性问题？

当我们对数据进行修改时，既要更新数据库（MySQL），又要更新缓存（Redis），这就形成了“双写”。在高并发的情况下，如果更新顺序不合理或出现失败重试，就可能导致 Redis 和 MySQL 的数据不一致。

⚠️ 二、常见不一致的场景

✅ 三、解决方案汇总

📌 四、推荐方案：延迟双删策略（适用于大多数情况）

步骤流程：

1、删除缓存

2、更新数据库

3、睡眠短时间（如 500ms）

4、再次删除缓存

✅ 为什么有效？

如果在第1次删除后有并发请求重建了旧缓存，第4步能再次删掉这个“脏缓存”。

🧑‍💻 五、Go 实现示例（延迟双删）

func UpdateUserName(userId int64, newName string) error {
    cacheKey := fmt.Sprintf("user:%d", userId)

    // Step 1: 删除缓存
    _ = redisClient.Del(context.Background(), cacheKey)

    // Step 2: 更新数据库
    if err := db.Model(&User{}).Where("id = ?", userId).Update("name", newName).Error; err != nil {
        return err
    }

    // Step 3: 延迟后再次删除缓存（避免并发脏数据）
    go func() {
        time.Sleep(500 * time.Millisecond)
        _ = redisClient.Del(context.Background(), cacheKey)
    }()

    return nil
}

🔍 注意：

• 睡眠时间 500ms~1s 根据业务调整。

• 异常重试可以使用 go-redis 的重试机制或加兜底策略。

📌 六、更高级的方案：Binlog + Canal 增量同步缓存

适用于要求 最终一致 且不易修改业务逻辑的大型系统。

原理：

1、MySQL 写入数据。

2、Canal 监听 Binlog 变化。

3、触发缓存更新逻辑（如重建 Redis 对应 key）。

架构图：

App写库
  ↓
MySQL ——> Binlog ——> Canal ——> Kafka ——> Cache更新消费器
                                       ↓
                                     Redis

优势：

• 对业务零侵入。

• 最终一致，适合数据查询为主的业务。

🔐 七、使用分布式锁强一致（场景有限）

通过 Redis 的 SETNX 加锁，串行执行更新缓存 + 更新数据库。

lockKey := fmt.Sprintf("lock:user:%d", userId)
ok, _ := redisClient.SetNX(ctx, lockKey, 1, 5*time.Second).Result()
if ok {
    defer redisClient.Del(ctx, lockKey)

    // 更新DB & 缓存
} else {
    // 忽略或重试
}

缺点：

• 性能损耗高，存在死锁风险。

• 一般用于重要但低并发场景。

🧠 八、总结对比