25 | 缓存异常（上）：如何解决缓存和数据库的数据不一致问题？

老是Redis的LFU是做了优化的，访问次数会随着时间而递减，在updateLFU() ->LFUDecrAndReturn()里面

加油！坚持就是胜利

数据在删改操作时，如果不是删除缓存值，而是直接更新缓存的值，你觉得和删除缓存值相比，有什么好处和不足？ 这种情况相当于把Redis当做读写缓存使用，删改操作同时操作数据库和缓存。 1、先更新数据库，再更新缓存：如果更新数据库成功，但缓存更新失败，此时数据库中是最新值，但缓存中是旧值，后续的读请求会直接命中缓存，得到的是旧值。 2、先更新缓存，再更新数据库：如果更新缓存成功，但数据库更新失败，此时缓存中是最新值，数据库中是旧值，后续读请求会直接命中缓存，但得到的是最新值，短期对业务影响不大。但是，一旦缓存过期或者满容后被淘汰，读请求就会从数据库中重新加载旧值到缓存中，之后的读请求会从缓存中得到旧值，对业务产生影响。 同样地，针对这种其中一个操作可能失败的情况，也可以使用重试机制解决，把第二步操作放入到消息队列中，消费者从消息队列取出消息，再更新缓存或数据库，成功后把消息从消息队列删除，否则进行重试，以此达到数据库和缓存的最终一致。 以上是没有并发请求的情况。如果存在并发读写，也会产生不一致，分为以下4种场景。 1、先更新数据库，再更新缓存，写+读并发：线程A先更新数据库，之后线程B读取数据，此时线程B会命中缓存，读取到旧值，之后线程A更新缓存成功，后续的读请求会命中缓存得到最新值。这种场景下，线程A未更新完缓存之前，在这期间的读请求会短暂读到旧值，对业务短暂影响。 2、先更新缓存，再更新数据库，写+读并发：线程A先更新缓存成功，之后线程B读取数据，此时线程B命中缓存，读取到最新值后返回，之后线程A更新数据库成功。这种场景下，虽然线程A还未更新完数据库，数据库会与缓存存在短暂不一致，但在这之前进来的读请求都能直接命中缓存，获取到最新值，所以对业务没影响。 3、先更新数据库，再更新缓存，写+写并发：线程A和线程B同时更新同一条数据，更新数据库的顺序是先A后B，但更新缓存时顺序是先B后A，这会导致数据库和缓存的不一致。 4、先更新缓存，再更新数据库，写+写并发：与场景3类似，线程A和线程B同时更新同一条数据，更新缓存的顺序是先A后B，但是更新数据库的顺序是先B后A，这也会导致数据库和缓存的不一致。 场景1和2对业务影响较小，场景3和4会造成数据库和缓存不一致，影响较大。也就是说，在读写缓存模式下，写+读并发对业务的影响较小，而写+写并发时，会造成数据库和缓存的不一致。 针对场景3和4的解决方案是，对于写请求，需要配合分布式锁使用。写请求进来时，针对同一个资源的修改操作，先加分布式锁，这样同一时间只允许一个线程去更新数据库和缓存，没有拿到锁的线程把操作放入到队列中，延时处理。用这种方式保证多个线程操作同一资源的顺序性，以此保证一致性。 综上，使用读写缓存同时操作数据库和缓存时，因为其中一个操作失败导致不一致的问题，同样可以通过消息队列重试来解决。而在并发的场景下，读+写并发对业务没有影响或者影响较小，而写+写并发时需要配合分布式锁的使用，才能保证缓存和数据库的一致性。 另外，读写缓存模式由于会同时更新数据库和缓存，优点是，缓存中一直会有数据，如果更新操作后会立即再次访问，可以直接命中缓存，能够降低读请求对于数据库的压力（没有了只读缓存的删除缓存导致缓存缺失和再加载的过程）。缺点是，如果更新后的数据，之后很少再被访问到，会导致缓存中保留的不是最热的数据，缓存利用率不高（只读缓存中保留的都是热数据），所以读写缓存比较适合用于读写相当的业务场景。

延时双删根本解决不了一致性问题，高迸发场景线程A根本不知道线程B，线程C的执行开始和结束的时间。 所以sleep跟没sleep没啥区别。。。 感觉唯一的办法就是要让整个事务方法由并行变成串行。 感觉串行呢？要么借助分布式锁，要么借助MYSQL本身的update独占锁

先删除缓存后更新数据库，数据库更新失败了，何来的旧值。只读缓存不是以数据库为准吗？

完全没必要双删，双删比起先DB后删Redis，无非就是防止删除Redis操作失败。但高并发下依旧可能在第一次删期间混进来读操作。 还有基于消息队列的方案，凭啥Redis操作能会失败，DB操作会失败，消息队列就不会了呢？就算能用事务消息，难道不怕旧值覆盖新值的情况发生么？ 对于课后题，这种被称为直接缓存，除了大家说的分布式锁方案保证并发下的正确，还可以考虑基于lua实现cas，有一定性能下降但大多数场景都还能接受。

看了一堆评论，其实会发现讨论的时候，说着说着大家关于一致性的概念理解就发生变化了； 有时说的一致性指的是强一致性，有时说的一致性又是最终一致性，所以大家互觉得对方有问题； (1)只要缓存和数据库更新有先后，就一定达不到强一致性(达到数据库和缓存在同一瞬间都更新的效果)； (2)即便使用最终一致性，也有方法实现： a.尽量降低出现长时间才能达到最终一致性的概率； b.尽量减少达到最终一致性的时间； 所以才会有人认为延迟双删解决不了一致性，因为这个一致性指的是强一致性； 而老师专栏说延迟双删可以保证一致性，也仅仅是指"减少数据库和缓存达到最终一致的时间"；

不用第二种延迟双删, 直接用先DB后删redis不就好了, 延迟双删还要麻烦一点, 感觉没有什么优点啊

老师分析问题的思路很赞，但是我对于结论有一个很大的疑问，按照分析思路 ，既然对于读写缓存同步写回策略可以采用（分布式）事务来保证原子性，那么只读缓存的更新数据库和删除缓存的操作为什么不能采用事务来保证原子性？二者的思路差异在哪里？

更新步骤: 1.先更新缓存，再更新数据库 2.先更新数据库，再更新缓存 并发: 1.读+写 2.写+写 3.读+读 在并发情况下，3是肯定没有影响的。1和2肯定会对数据一致性有影响。这个时候可以利用分布式锁来处理。同一时刻一个key只有一把锁持有。