这种方式，在方案3的基础上，又将二者的顺序进行了调换。我们再把前面的场景在这种方案下进行验证：一个是查询操作，一个是更新操作的并发，我们先更新了数据库中的数据，此时，缓存依然有效，所以，并发的查询操作拿的是没有更新的数据，但是，更新操作马上让缓存的失效了，后续的查询操作再把数据从数据库中拉出来。而不会方案3一样，后续的查询操作一直在取老的数据。

而这，也正是缓存使用的标准的design pattern，也就是cache aside。包括Facebook的论文《Scaling Memcache at Facebook》也使用了这个策略。

那么，是否这种方案就是万无一失的完美策略呢？其实也并不然，再来看看这种场景：一个是读操作，但是没有命中缓存，然后就到数据库中取数据，此时来了一个写操作，写完数据库后，让缓存失效，然后，之前的那个读操作再把老的数据放进去，所以，会造成脏数据。

因此，在使用更新缓存操作时，无论谁先谁后，但凡后者发生异常，就会对业务造成影响。

三、解决问题策略思想

选择合适的数据同步方式：根据应用的需求和数据访问模式，选择合适的数据同步方式。同步方式包括单向同步、双向同步和不同步等。
使用事务：在 MySQL 中使用事务来确保数据的原子性。在 Redis 中，可以使用 MULTI/EXEC 命令组来执行事务操作。
避免长时间的事务：MySQL 中的长时间事务可能会导致 Redis 中的数据不同步。因此，在设计数据库操作时，应尽量避免长时间的事务。
主从复制：使用 MySQL 的主从复制功能，将数据变更同步到从数据库。然后，使用 Redis 的订阅/发布功能，将从数据库中的数据变更同步到 Redis。这种方式可以实现 MySQL 和 Redis 的双向同步。
分布式事务：使用分布式事务协议，如两阶段提交或三阶段提交，来确保 Redis 和 MySQL 之间的数据一致性。分布式事务可以保证多个数据库之间的数据一致性。
定时同步：对于一些不需要实时同步的数据，可以使用定时同步的方式。例如，每天定时将 MySQL 中的数据同步到 Redis 中。
数据校验：定期进行数据校验，以确保 Redis 和 MySQL 中的数据一致。如果数据不一致，及时进行修复。

四、具体解决方案

1、延时双删

我们重点在将先更新数据库，在删除缓存。那如果我要先删除缓存，再更新数据库呢？
回顾之前讲的先删除缓存，再更新数据库，它会出现旧值覆盖缓存的问题，那好办，我们直接把这个旧值给删了不就完了吗，延时双删就是这个原理，它的基本思路是：

先删除缓存
再更新数据库
休眠一段时间（根据系统情况确定）
再次删除缓存

这样做的目的是为了防止在更新数据库后，有其他线程读取到旧的缓存数据，并将其写回缓存，导致数据不一致。

2、Binlog实现异步重试删除

使用binlog实现一致性的基本思路是利用binlog日志来记录数据库的变更操作，然后通过主从复制或者增量备份的方式来同步或者恢复数据。

举例来说，如果我们有一个主数据库和一个从数据库，我们可以在主数据库上开启binlog日志，并设置从数据库作为它的复制节点。这样，当主数据库上发生任何变更操作时，它会将对应的binlog日志发送给从数据库，从数据库则会根据binlog日志来执行相同的操作，从而保证数据一致性。

另外，如果我们需要恢复某个时间点之前的数据，我们也可以利用binlog日志来实现。首先，我们需要找到对应时间点之前的最近一个全量备份文件，并将其恢复到目标数据库。然后，我们需要找到对应时间点之前的所有增量备份文件（即binlog日志文件），并按照顺序将其应用到目标数据库。这样，我们就可以恢复出目标时间点之前的数据状态了。

使用 Binlog 实时更新/删除 Redis 缓存。利用 Canal，即将负责更新缓存的服务伪装成一个 MySQL 的从节点，从 MySQL 接收 Binlog，解析 Binlog 之后，得到实时的数据变更信息，然后根据变更信息去更新/删除 Redis 缓存；
MQ+Canal 策略，将 Canal Server 接收到的 Binlog 数据直接投递到 MQ 进行解耦，使用 MQ 异步消费 Binlog 日志，以此进行数据同步；RocketMQ实现最终一致性；比如基于 RocketMQ 的可靠性消息通信，来实现最终一致性；Canal 组件还可以直接通过 Canal 组件，监控 Mysql 中 binlog 的日志，把更新后的数据同步到 Redis 里面。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/从前慢现在也慢/article/detail/165155