这个说的就是删除缓存失败后造成的问题

还在更新中，这个读到老数据应该是可以的

按道理来说，数据库已经开始执行更新了，不应该由于并发问题在把缓存设置成旧的值。
推荐一种策略是双删缓存： 删缓存 修改数据库 删缓存

我觉得可以，这样数据就一致了

推荐一种策略是双删缓存： 删缓存 修改数据库 删缓存

这种也有比较大的问题，比如再高并发的情况下 ：

1-delete cache

                       ### 2-query DB

3-update DB

4-delete cache

                       ### 5-set cache

134是一个线程
25是另一个线程

这种场景下不一致出现了，cache中还是旧的值，DB中是新的值。

所以双删策略，是不是 应该更新完数据库后，删除缓存，然后为了避免删除失败，在通过MQ延迟删除兜底啊，这种才能保证最终一致性吧

有删除缓存失败的可能，就会有放入MQ失败的可能性，却增加系统的复杂度，考虑数据丢失问题

你没理解到延迟双删，第二次删除是发送MQ去做延迟删除，压根不会和 1 3 在同一个线程，保证了第二次删除一定是最后一步了

为了稳健性不能搞预计数据库更新时间吧。。。

如果是分布式的服务，这个读写锁就没办法保证了，单机服务还是可以的

是的，如果系统允许短时间内的数据不一致，这种方案肯定是好的，而且是简单的。但是如何要求有请求存在时redis和数据库的数据必须一致，那就只能把请求串行化了。

这不是原不原子操作关系不大吧，要解决的是删除缓存到更新完数据库这个时间段内其他请求又请求缓存接口导致回源的是老数据的问题吧

这不是原不原子操作关系不大吧，要解决的是删除缓存到更新完数据库这个时间段内其他请求又请求缓存接口导致回源的是老数据的问题吧

他文章里面忽略了一个问题， 高并发的情况下，用队列 你怎么保证你 版本1的更新消息 一定会在 版本2的更新消息 之前进入队列？不还是得加悲观锁？ 数据库拿到行锁 然后把更新丢进队列，如果数据库不拿到行锁 就去投递消息进队列 队列的顺序肯定没法保证， 这个问题我之前做消息队列高并发 demo时候 早就研究过，双写要保证完全一致性 一定要竞争单条数据的全局锁，否则没法保证原子性。

而且双写一致性 大部分时候都是一个伪命题，没有什么业务需要这么强一致性的缓存的读，而更新的话 直接用数据库的行锁就能保证触发一次当前读。

这不是原不原子操作关系不大吧，要解决的是删除缓存到更新完数据库这个时间段内其他请求又请求缓存接口导致回源的是老数据的问题吧

而且他文章里面的队列还要去维护更新，例如后续的更新来了，要自动忽略掉前面的老版本，这个操作本身也是很费时间的。

另外还要涉及到消息路由的问题， 你是让集群里面的所有的JVM虚拟机 都接受所有的读请求 ，还是要做hash分片，对部分读请求只会hash路由到特定的JVM，如果是前者，那么你需要更新数个JVM的队列，数据行的写操作的性能会急剧下降，如果是后者，你特定的JVM挂逼了，那么你服务就会缺失一大块的响应，因为特定的请求只会路由到特定的JVM实例上。

哈哈。这样代价好大啊

又得保证mq的一致性

整个业务流程是串行的，如果删除缓存失败，就进行后续加入MQ延迟队列的步骤？
是否可以这样做： 删除缓存失败原因（缓存宕机，网络抖动，项目停止）
1、前两种通过补偿策略，加入到MQ延迟队列，或者回滚数据。
2、项目停止（优雅停止时长少于业务时间），这种不可控因素，有个补偿策略（rabbitMQ），但代价很大。
a、在第一次删除时，异步MQ（CompletableFuture里创建一临时队列，ttl 可以根据优雅停止时长）。
b、第二次删除时，根据返回的临时队列异步消费，若项目停止则加入死信队列，延迟消费。

如果只是在意空档期的话，那先更新数据库再删除缓存不是反而不存在空档期了吗？先删除缓存的目的应该是为了确保如果缓存删除失败，就停止数据库的更新。你通过异步的方法来操作，如果缓存删除失败，还是更新了数据库，那就还需要保证缓存的最终删除

好久了，=- -，我之前讨论的场景是先删除缓存再更新数据库的场景，这个是前提。
其次，针对于缓存删除失败的问题，缓存删除是前置操作，所以，删除操作的成功是可以保证的。