延时双删（redis-mysql）数据一致性思考

2022-02-14
redis

延时双删 是应对缓存与数据库一致性挑战的实用策略。它通过两次删除操作配合延时等待，在性能与一致性间寻找平衡，实现最终一致而非强一致。

这里思考和分析一下它的工作原理。

1. 延时双删

延时双删常用步骤有 4 个，参考下面 Python 语言的伪代码：

1
2
3
4
5

def update_data(key, obj):
    del_cache(key)     # 删除 redis 缓存数据。
    update_db(obj)     # 更新数据库数据。
    logic_sleep(_time) # 当前逻辑延时执行（不是线程睡眠）。
    del_cache(key)     # 删除 redis 缓存数据。

logic_sleep 是当前请求逻辑延时执行，例如：协程睡眠切换，或者异步逻辑放进时钟里延时执行下一个步骤。很多人会误认为这是线程/进程睡眠切换，当然这样也行，不觉得这样影响实在太大了么~ 😱

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

func UpdateWithDoubleDelete(db *gorm.DB, redis *redis.Client, user *User) error {
    cacheKey := fmt.Sprintf("user:%d", user.ID)
    
    // 第一次删除缓存（防止脏读，增强数据一致性）
    redis.Del(context.Background(), cacheKey)
    
    // 更新数据库
    if err := db.Save(user).Error; err != nil {
        return err
    }
    
    // 延迟第二次删除（解决主从同步延迟期间的脏读）
    go func() {
        // 根据主从延迟调整
        time.Sleep(1 * time.Second)
        // 第二次删除
        redis.Del(context.Background(), cacheKey)
    }()
    
    return nil
}

2. Q & A

  1. 延时双删有啥作用？

    • 为了使得缓存和数据库数据最终一致。

  2. 为什么要删除缓存数据，而不是修改？

    • 并发改数据场景，先改缓存的有可能后改库，先改库的也可能后改缓存。

  3. 为什么要 “睡眠” 延时一段时间？

    • 读写分离是解决高并发比较有效的方案，但是缓存/库的主从是异步更新数据的。
    • 睡眠一段时间，就是为了库和缓存能实现数据主从同步。

  4. 延时双删能确保缓存和数据库最终一致吗？

    • 不能确保。
    • 只能通过延时最大程度上提高数据的最终一致的概率。
    • 如果缓存和数据库负载很高，主从同步很慢，很有可能不能在延时的时间内实现同步。

  5. 脏读怎么办？

    • 确实有这问题，要知道这是最终一致，并不是强一致，最后一次删除就是为了最终一致^_^！
    • 所以要确保你的业务场景能忍受数据最终一致的缺陷，实在不行你读主库呗。
    • 优化业务逻辑的设计，具体请参考下文的：通过业务设计加强数据一致性 章节。

  6. 为什么要有第一次删除缓存？

    1> 删除脏读。

    2> 提前实现其它操作的数据最终一致。

    • 延时双删有 4 个步骤，全部执行完才能实现数据最终一致，可能会比较慢！
    • 延时双删第三个步骤延时等待是比较漫长的，有可能在等待时间超时前，数据就已经完成同步了。在并发环境中，如果其它并发环节增加第一次删除，可能会提前实现前面操作的数据最终一致，不用等延时双删四个步骤都完成。

3. 系统布局

先从宏观上观察系统布局，了解数据一致性。

因为多个节点间的数据异步操作，所以整个系统要实现强一致是比较难的。

  1. 多个业务程序节点读写数据。
  2. redis 读写分离，主从同步。
  3. mysql 读写分离，主从同步。

4. 缓存处理

4.1. 更新缓存

为什么要删除缓存呢，更新缓存不行吗？

看看下面两种场景，不同服务节点修改存储数据，都可能出现 redis 和 mysql 出现数据不一致问题。

  • 先改缓存再改数据库。
  • 先改数据库再改缓存。

4.2. 删除缓存

  • 第一次删除是为了删除脏读，也有可能提前实现前面操作的最终一致。
  • 第二次删除为了最终一致。

5. 延时

为什么要延时呢？因为 mysql 和 redis 主从节点数据不是实时同步的，同步数据需要时间。

数据工作的大致流程：

  1. 服务节点删除 redis 主库数据。
  2. 服务节点修改 mysql 主库数据。
  3. 服务节点使得当前业务处理 等待一段时间，等 redis 和 mysql 主从节点数据同步成功。
  4. 服务节点从 redis 主库删除数据。
  5. 当前或其它服务节点读取 redis 从库数据，发现 redis 从库没有数据，从 mysql 从库读取数据，并写入 redis 主库。

6. 其它策略

6.1. redis 数据过期

redis 作为高速缓存，优点很明显：快；缺点也很明显：消耗内存。

所以 redis 的定位是缓存热点数据，热点数据应该设置过期时间，当数据过期后，redis 会自动淘汰，这样当业务服务节点从 redis 查询已淘汰的数据时，查询不到数据，会重新从 mysql 数据库读取数据写入 redis。

这也是加强 redis / mysql 数据一致性的相对简单有效的方法。

用户应该根据自己的实际业务场景去设置 redis 数据的过期时间。

6.2. 通过业务设计加强数据一致性

如果我们的业务是串行的，A 执行完操作，通知 B 处理。这种业务场景，系统应该如何在 数据最终一致 的情况下尽量确保业务数据的一致性？

  • 唯一 ID。例如 A 插入新数据，数据唯一 id: 123，然后通知 B 接收，B 从 redis slave 中读取缓存查询 id: 123 的数据，查询失败，就可以读取 redis master，如果 redis master 读取失败，就读取数据库从库，读取从库失败就读取主库，确保成功后重新写入更新缓存（当然数据不命中的各种查询对于业务逻辑而言是复杂的，开发对应的 proxy 去处理类似的不命中问题应该会让事情变得更加简单）。
  • 版本号匹配。如果 A 更新唯一 id: 123 的数据，我们可以为该数据添加一个 版本号：456，查询某个 id 数据，还需要匹配对应的版本号，逻辑同上。

6.3. 分布式路由策略

高性能系统当然是越快越好，所以延时双删的 “延时” 不见得有多好，但是在读多写少的应用场景中，也算是性能和功能的折中处理。

很多时候，数据不一致是因为多个节点并行读写共享数据导致。如果某些特定业务只落在某个进程某个线程上独立 串行 处理，那问题处理是否会更好呢？

当然这里面涉及到节点的变动带来的问题，所以没有万能的方案，只能根据场景进行取舍。

7. 缺点

  1. 性能损耗：等待环节引入额外延迟，对低延时要求的系统不友好。
  2. 场景限制：不适合秒杀等高并发强一致场景，频繁数据修改时效果不佳。
  3. 时间不确定性：延时基于预估，无法保证主从同步在指定时间内完成，仍可能出现数据不一致。

8. 小结

  1. 简洁的最终一致性方案：延时双删以相对简单的方式实现 MySQL 与 Redis 数据的最终一致性，但无法保证强一致性。
  2. 延时的核心作用：通过延时等待主从数据同步完成，减少缓存与数据库不一致的时间窗口，提升数据一致性概率。
  3. 异步延时的实现：延时指逻辑处理的异步等待，而非线程阻塞，确保系统性能不受影响。
  4. 复合策略的必要性：实际生产中需结合多种策略——如延时双删、缓存过期、串行路由、分布式锁等——共同保障数据一致性。
  5. 权衡的艺术：该策略在性能与一致性间寻找平衡点，适用于能接受短暂数据不一致的业务场景。
目录

我的链接

文集

归档