“Redis 和 数据库的一致性的保证”的版本间的差异
跳到导航
跳到搜索
Jihongchang(讨论 | 贡献) (建立内容为“1”的新页面) |
Jihongchang(讨论 | 贡献) |
||
(未显示同一用户的2个中间版本) | |||
第1行: | 第1行: | ||
− | + | 首先,要确定的是:一般我们讨论的是最终一致性,而不是强一致性。 | |
+ | |||
+ | 强一致性:需要保证缓存操作和数据库操作的原子性,但这样的实现就会影响系统的吞吐量。 | ||
+ | |||
+ | 所以我们只能尽量追求最终一致性。 | ||
+ | |||
+ | === 延迟双删 === | ||
+ | 延迟双删是指:先删除缓存,然后操作数据库,然后再延迟删除一次缓存 | ||
+ | |||
+ | 即使采用了延迟双删策略,也不能保证数据库和缓存最终一致,因为第二次的延迟删除操作也有可能失败。 | ||
+ | |||
+ | === 最终的方案 === | ||
+ | 现在流程的一种相对成熟的方案是: | ||
+ | |||
+ | 引入阿里的Canal监听数据库的binlog,在数据发生变更的时候,监听binlog的Canal服务发起删除缓存的操作,如果操作失败,再存储到消息队列进行删除重试。 | ||
+ | [[文件:缓存和数据库的一致性保证方案.png|无|缩略图|900x900像素]] |