查看“Redis 和数据库的一致性的保证”的源代码

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

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

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

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

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

=== 最终的方案 ===
现在流程的一种相对成熟的方案是：

引入阿里的Canal监听数据库的binlog，在数据发生变更的时候，监听binlog的Canal服务发起删除缓存的操作，如果操作失败，再存储到消息队列进行删除重试。
[[文件:缓存和数据库的一致性保证方案.png|无|缩略图|900x900像素]]