延时双删(redis-mysql)数据一致性思考

2022-02-14

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

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


1. 系统布局

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

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

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

2. 延时双删

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


3. 问题

带着问题理解这个策略。

  1. 为什么要删除缓存数据,而不是修改?
  2. 为什么要睡眠一段时间再进行第二次删除数据?

4. 缓存处理

4.1. 更新缓存

为什么要删除缓存呢,更新缓存不行吗?

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

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

4.2. 删除缓存

双删缓存,理论上,mysql 与 redis 的数据是比较一致的。


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. 分布式路由策略

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

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

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


7. 缺点

  1. 延时双删,有等待环节,如果系统要求低延时,这种场景就不合适了。
  2. 延时双删,不适合“秒杀”这种频繁修改数据和要求数据强一致的场景。
  3. 延时双删,延时时间是一个预估值,不能确保 mysql 和 redis 数据在这个时间段内都实时同步或持久化成功了。

8. 小结

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