前言

一道之前的面试题：

如何保证缓存和数据库的一致性？

下面介绍几种方案（大家回答的时候最好根据自己的业务，结合下面的方案）

方案分析

更新缓存策略方式常见的有下面几种：

下面一一介绍！

方案一：更新缓存，更新数据库

这种方式可轻易排除，因为如果先更新缓存成功，但是数据库更新失败，则肯定会造成数据不一致。

方案二：更新数据库，更新缓存

这种缓存更新策略俗称双写，存在问题是：并发更新数据库场景下，会将脏数据刷到缓存

updateDB();
updateRedis();

举例：如果在两个操作之间数据库和缓存又被后面请求修改，此时再去更新缓存已经是过期数据了。

方案三：删除缓存，更新数据库

存在问题：更新数据库之前，若有查询请求，会将脏数据刷到缓存

deleteRedis();
updateDB();

举例：如果在两个操作之间发生了数据查询，那么会有旧数据放入缓存。

该方案会导致请求数据不一致

如果同时有一个请求A进行更新操作，另一个请求B进行查询操作。那么会出现如下情形:

上述情况就会导致不一致的情形出现。而且，如果不采用给缓存设置过期时间策略，该数据永远都是脏数据。

方案四：更新数据库，删除缓存

存在问题：在更新数据库之前有查询请求，并且缓存失效了，会查询数据库，然后更新缓存。如果在查询数据库和更新缓存之间进行了数据库更新的操作，那么就会把脏数据刷到缓存

updateDB();
deleteRedis();

举例：如果在查询数据库和放入缓存这两个操作中间发生了数据更新并且删除缓存，那么会有旧数据放入缓存。

假设有两个请求，一个请求A做查询操作，一个请求B做更新操作，那么会有如下情形产生

如果发生上述情况，确实是会发生脏数据。但是发生上述情况有一个先天性条件，就是写数据库操作比读数据库操作耗时更短

不过数据库的读操作的速度远快于写操作的

因此这一情形很难出现。

方案1和方案2的共同缺点：

并发更新数据库场景下，会将脏数据刷到缓存，但一般并发写的场景概率都相对小一些；

线程安全角度，会产生脏数据，比如：

方案3和方案4的共同缺点：

不管采用哪种顺序，2种方式都是存在一些问题的：

问题解决思路：延迟双删，添加重试机制，下面介绍！

更新缓存还是删除缓存？

1.更新缓存缓存需要有一定的维护成本，而且会存在并发更新的问题

2.写多读少的情况下，读请求还没有来，缓存以及被更新很多次，没有起到缓存的作用

3.放入缓存的值可能是经过复杂计算的，如果每次更新，都计算写入缓存的值，浪费性能的

删除缓存优点：简单、成本低，容易开发；缺点：会造成一次cache miss

如果更新缓存开销较小并且读多写少，基本不会有写并发的时候可以才用更新缓存，否则通用做法还是删除缓存。

方案

问题

问题出现概率

推荐程度


更新缓存 -> 更新数据库	为了保证数据准确性，数据必须以数据库更新结果为准，所以该方案绝不可行	大	不推荐
更新数据库 -> 更新缓存	并发更新数据库场景下，会将脏数据刷到缓存	并发写场景，概率一般	写请求较多时会出现不一致问题，不推荐使用。
删除缓存 -> 更新数据库	更新数据库之前，若有查询请求，会将脏数据刷到缓存	并发读场景，概率较大	读请求较多时会出现不一致问题，不推荐使用
更新数据库 -> 删除缓存	在更新数据库之前有查询请求，并且缓存失效了，会查询数据库，然后更新缓存。如果在查询数据库和更新缓存之间进行了数据库更新的操作，那么就会把脏数据刷到缓存	并发读场景&读操作慢于写操作，概率最小	读操作比写操作更慢的情况较少，相比于其他方式出错的概率小一些。勉强推荐。