“Redis 和 数据库的一致性的保证”的版本间的差异

来自姬鸿昌的知识库
跳到导航 跳到搜索
 
(未显示同一用户的1个中间版本)
第9行: 第9行:
  
 
即使采用了延迟双删策略,也不能保证数据库和缓存最终一致,因为第二次的延迟删除操作也有可能失败。
 
即使采用了延迟双删策略,也不能保证数据库和缓存最终一致,因为第二次的延迟删除操作也有可能失败。
 +
 +
=== 最终的方案 ===
 +
现在流程的一种相对成熟的方案是:
 +
 +
引入阿里的Canal监听数据库的binlog,在数据发生变更的时候,监听binlog的Canal服务发起删除缓存的操作,如果操作失败,再存储到消息队列进行删除重试。
 +
[[文件:缓存和数据库的一致性保证方案.png|无|缩略图|900x900像素]]

2024年7月13日 (六) 03:12的最新版本

首先,要确定的是:一般我们讨论的是最终一致性,而不是强一致性。

强一致性:需要保证缓存操作和数据库操作的原子性,但这样的实现就会影响系统的吞吐量。

所以我们只能尽量追求最终一致性。

延迟双删

延迟双删是指:先删除缓存,然后操作数据库,然后再延迟删除一次缓存

即使采用了延迟双删策略,也不能保证数据库和缓存最终一致,因为第二次的延迟删除操作也有可能失败。

最终的方案

现在流程的一种相对成熟的方案是:

引入阿里的Canal监听数据库的binlog,在数据发生变更的时候,监听binlog的Canal服务发起删除缓存的操作,如果操作失败,再存储到消息队列进行删除重试。

缓存和数据库的一致性保证方案.png