两者第二步没成功，都有问题

先更新缓存后更新数据库

用户A把用户B的请求覆盖了

先更新数据库后更新缓存

线程A的缓存把线程B的缓存覆盖了

显然有问题，以上是并发问题，除此之外从缓存利用率来讲，更新的缓存不一定会马上被读取，可能会导致缓存中有很多没有用的数据，浪费资源。

最终 X 的值在缓存中是 1（旧值），在数据库中是 2（新值），发生不一致。

最终 X 的值在缓存中是 1（旧值），在数据库中是 2（新值），也发生不一致。

然而上述条件很难满足，特别是条件三

程序在执行过程中发生异常，最简单的解决办法是什么？

重试

直接重试方案不严谨：

异步重试

把重试请求写到「消息队列」中，然后由专门的消费者来重试，直到成功

或者更直接的做法，为了避免第二步执行失败，我们可以把操作缓存这一步，直接放到消息队列中，由消费者来操作缓存。

问题：

如果在执行失败的线程中一直重试，还没等执行成功，此时如果项目「重启」了，那这次重试请求也就「丢失」了，那这条数据就一直不一致了

解决方法：消息队列特性

至于写队列失败和消息队列的维护成本问题：

订阅数据库变更日志，再操作缓存

们的业务应用在修改数据时，「只需」修改数据库，无需操作缓存。

当一条数据发生修改时，MySQL 就会产生一条变更日志（Binlog），我们可以订阅这个日志，拿到具体操作的数据，然后再根据这条数据，去删除对应的缓存。

订阅变更日志，目前也有了比较成熟的开源中间件，例如阿里的 canal，使用这种方案的优点在于：