图解数据库和Redis缓存的一致性（延时双删与延时后删的区别及重要性）

问题来源

使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问MySQL等数据库：

读取缓存步骤一般没有什么问题，但是一旦涉及到数据更新：数据库和缓存更新，就容易出现缓存(Redis)和数据库（MySQL）间的数据一致性问题。

不管是先写MySQL数据库，再删除Redis缓存，再更新缓存；还是先删除缓存，再写库，再更新缓存。都有可能出现数据不一致的情况。举一个例子：

1.如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。

2.如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况。

因为写和读是并发的，没法保证顺序，就会出现缓存和数据库的数据不一致的问题。

情况一：只先删除缓存

第一步删除原先的旧缓存0，使缓存为空，第二步再将新数据 1 插入数据库。但是问题在于，第一步和第二步之间，若有一个B事务去读取缓存时，发现缓存为空，B事务自然会去数据库中查数据，此时查到的数据为0，然后再把 0 放到缓存中，紧接着A事务继续进行它的第二步，将数据库的数据0改为1。这就导致了缓存为0，数据库为1，以后再有事务C来查数据时，查到的缓存一直是0，即一直为脏数据。

情况二：只后删除缓存

此情况又分为两种，一种是A事务更新数据库和删除旧缓存之间的一段时间内，B事务查询了旧缓存，这就导致了若干次脏数据；另一种是更新数据库数据为1后，将要去删除旧缓存0的时候线程宕掉了，缓存更新失败，仍为0，所以B事务要去查数据的时候查到的缓存0为旧数据，这就导致了一直为脏数据。

普通双删

针对以上两种情况，若采用普通双删，B事务有一定的几率在A事务删除缓存之后才更新缓存为0，这样就导致了缓存为0，数据库为1，其他事务查询时导致了结果一直为脏数据。

延时双删

如上所述，既然B事务有一定的几率在A事务删除缓存之后才更新缓存为0，那么为了降低这种几率，我们可以将A事务更新数据库和删除就缓存之间的这段时间延长，使得B事务把旧的数据更新到缓存之后，才将缓存删除，这就保证了其他事务（C）查询时的数据一致。

显然，以上延时双删的方法仍然有一些局限性。其一，在a时间段内，也就是缓存仍为旧数据且来不及删除就缓存事件内，仍然会有事务查询得到就缓存，存在若干次脏数据；其二，b时间段内，我们可以尽可能缩短b时间段，以保证A事务尽快更新完数据库后，B事务查询数据库能拿到真数据。

总结

以上解决方案适用于对数据一致性比较大、请求量不是特别高的业务场景下。若是在高并发和查询数据量比较大的情况下 ，对若干次数据一致性要求不高，更需要提高缓存的命中率，这就使得第一次删除缓存的必要性降低，因为我们引入缓存的目的是降低数据库压力，如果因为一些不必要的第一次删除而降低了缓存的命中率，在高并发场景下显然会对数据库带来大的压力。当然第一次删除在情况一也有其带来数据一致的好处，只看我们的业务场景下是否需要牺牲部分数据一致的情况。

参考：redis缓存为什么要延时双删