Redis 和 数据库的一致性的保证
Jihongchang(讨论 | 贡献)2024年7月13日 (六) 03:09的版本
首先,要确定的是:一般我们讨论的是最终一致性,而不是强一致性。
强一致性:需要保证缓存操作和数据库操作的原子性,但这样的实现就会影响系统的吞吐量。
所以我们只能尽量追求最终一致性。
延迟双删
延迟双删是指:先删除缓存,然后操作数据库,然后再延迟删除一次缓存
即使采用了延迟双删策略,也不能保证数据库和缓存最终一致,因为第二次的延迟删除操作也有可能失败。
最终的方案
现在流程的一种相对成熟的方案是:
引入阿里的Canal监听数据库的binlog,在数据发生变更的时候,监听binlog的Canal服务发起删除缓存的操作,如果操作失败,再存储到消息队列进行删除重试。