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

延时双删 策略是分布式系统中存储和缓存数据保持一致性的常用策略，但它不是强一致。

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

• 1. 延时双删
• 2. Q & A
• 3. 系统布局
• 4. 缓存处理
  • 4.1. 更新缓存
  • 4.2. 删除缓存
• 5. 延时
• 6. 其它策略
  • 6.1. redis 数据过期
  • 6.2. 通过业务设计加强数据一致性
  • 6.3. 分布式路由策略
• 7. 缺点
• 8. 小结

1. 延时双删

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

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

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. 延时双删，延时时间是一个预估值，不能确保 mysql 和 redis 数据在这个时间段内都实时同步或持久化成功了。

8. 小结

1. 延时双删用比较简洁的方式实现 mysql 和 redis 数据最终一致性，但它不是强一致。
2. 延时，是因为 mysql 和 redis 主从节点数据同步不是实时的，所以需要等待一段时间，去增强它们的数据一致性。
3. 延时 是指当前请求逻辑处理延时，而不是当前线程或进程睡眠延时。
4. mysql 和 redis 数据一致性是一个复杂的课题，通常是多种策略同时使用，例如：延时双删、redis 过期淘汰、通过路由策略串行处理同类型数据、分布式锁等等。