Redis：缓存（双写）一致性问题

参考资料：

《缓存更新的套路》

《分布式之数据库和缓存双写一致性方案解析》

《主从DB与cache一致性》

《如何保证数据库和缓存双写一致性》

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

        写在开头：本文为学习后的总结，可能有不到位的地方，错误的地方，欢迎各位指正。

目录

一、起因

二、解决方案

        弱一致性方案

        强一致性方案

        先写缓存，再写数据库

         先写数据库，再写缓存

        写缓存失败了

        局部性原理的弊端

        先删缓存，再写数据库

        高并发下的问题

        延时双删

        拓展

        先写数据库，再删缓存

        缓存删除失败的解决方案

        思路

        定时任务

        消息队列

        binlog

---

一、起因

        在高并发的业务场景下，数据库大多数情况都是用户并发访问最薄弱的环节。所以，就需要使用 redis 做一个缓冲操作，让请求先访问到 redis，而不是直接访问 MySQL 等数据库。

        

         这个业务场景，主要是解决读数据从 Redis 缓存，一般都是按照下图的流程来进行业务操作。

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

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

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

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

        因为写和读是并发的，没法保证顺序，就会出现缓存和数据库的数据不一致的问题。那么，我们该如何更新缓存呢？下面我们介绍下几种常见的方案。

二、解决方案

        弱一致性方案

        从理论上来说，给缓存设置过期时间，是保证最终一致性的解决方案。这种方案下，我们可以对存入缓存的数据设置过期时间，所有的写操作以数据库为准，对缓存操作只是尽最大努力即可。也就是说只要数据库写成功，即使缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存。

        但是这个方案并不适用于有较强一致性要求的场景，因此需要针对自己的业务做出选择。

        强一致性方案

        一般有以下四种具体方案：

• 先写缓存，再写数据库
• 先写数据库，再写缓存
• 先删缓存，再写数据库
• 先写数据库，再删缓存

        先写缓存，再写数据库

        该方案是问题最大的模式，该模式下，先更新缓存，再写数据库，一旦出现写数据库异常（网络延迟、数据库宕机等）情况，将导致缓存中的数据变为脏数据，这个状况将一直持续到该条数据被正确写回数据库，造成的影响无疑是巨大的。

                                                 

         先写数据库，再写缓存

        既然上面的方案行不通，我们换个思路，先写数据库，再更新缓存。

                                               

         先写数据库，再写缓存，可以避免之前“假数据”的问题。但它却带来了新的问题。

        写缓存失败了

        如果出现了写缓存失败的场景，必然导致缓存中的数据为脏数据，和先写数据库，再写缓存方案一样，需要等到下一次缓存更新才能恢复到正常状态。

                                                

         此时有人提出，可以把写数据库和写缓存操作，放在同一个事务当中，当写缓存失败了，我们可以把写入数据库的数据进行回滚，这样就保证了数据库与缓存中数据的一致性。

        如果是并发量比较小，对接口性能要求不太高的系统，可以这么玩。但如果在高并发的业务场景中，为了防止出现大事务，造成的死锁问题，通常建议写数据库和写缓存不要放在同一个事务中。

        局部性原理的弊端

        一般局部性原理包括时间局部性与空间局部性：

• 时间局部性（Temporal Locality）：如果一个信息项正在被访问，那么在近期它很可能还会被再次访问。
• 空间局部性（Spatial Locality）：在最近的将来将用到的信息很可能与正在使用的信息在空间地址上是临近的。

        而缓存正是利用了时间局部性的原理，我们认为一个数据被访问后还会被多次访问，因此将这个数据从磁盘中直接存储到内存中，加快访问速度。但这其实只是一个推测，我们并不能确保刚刚被访问的这个数据真的是热点数据，需要缓存，这一点我在《MySQL：更新过程》中的冷热分离LRU有具体解释。

        如果是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能。亦或者如果你写入数据库的值，并不是直接写入缓存的，而是要经过一系列复杂的计算再写入缓存。那么，每次写入数据库后，都再次计算写入缓存的值，无疑也会导致性能的浪费。

        由此可见，在高并发的场景中，先写数据库，再写缓存，这套方案问题挺多的，也不太建议使用。

        先删缓存，再写数据库

        通过上面的内容我们得知，如果直接更新缓存的问题很多。我们换一个思路，为什么如果不更新缓存，而直接删除呢？删除缓存方案，同样有两种：

• 先删缓存，再写数据库
• 先写数据库，再删缓存

        我们先来看看先删缓存，再写数据库的情况

                                                

         在用户的写操作中，先执行删除缓存操作，再去写数据库。这套方案，可以是可以，但当并发量一旦上升就容易出现问题。

        高并发下的问题

        假设在高并发的场景中，同一个用户的同一条数据，有一个读数据请求c，还有另一个写数据请求d（一个更新操作），同时请求到业务系统。如下图所示：

        （1）请求d先过来，把缓存删除了。但由于网络原因，卡顿了一下，还没来得及写数据库。
        （2）这时请求c过来了，先查缓存发现没数据，再查数据库，有数据，但是旧值。
        （3）请求c将数据库中的旧值，更新到缓存中。
        （4）此时，请求d卡顿结束，把新值写入数据库。

        在这个过程当中，请求d的新值并没有被请求c写入缓存，同样会导致缓存和数据库的数据不一致的情况。

        延时双删

        在上面的业务场景中，一个读数据请求，一个写数据请求。当写数据请求把缓存删了之后，读数据请求，可能把当时从数据库查询出来的旧值，写入缓存当中。

        为了避免这一情况，我们可以在请求d在写完数据库之后，把缓存重新删一次。

                                        

         这就是我们所说的延时双删，即在写数据库之前删除一次，写完数据库后，间隔一段时间再删除一次。该方案有个非常关键的地方是：第二次删除缓存，并非立马就删，而是要在一定的时间间隔之后。

public void write(String key,Object data){
		redis.delKey(key);
	    db.updateData(data);
	    Thread.sleep(1000);
	    redis.delKey(key);
	}

        之所以要加上时间间隔，是因为我们要删除的是并发的读请求（如有）写入缓存中的旧数据，那么我们的删除操作需要确保是在并发读请求写入缓存之后，如果是立即删除的话，可能旧数据还没进入缓存，这样缓存还是会被并发的读请求更新，产生脏数据。

        拓展

        假如遇到了mysql的读写分离架构，该方案是否还适用呢？我们来分析下：

        （1）请求A进行写操作，删除缓存
        （2）请求A将数据写入数据库了，
        （3）请求B查询缓存发现，缓存没有值
        （4）请求B去从库查询，这时，还没有完成主从同步，因此查询到的是旧值
        （5）请求B将旧值写入缓存
        （6）数据库完成主从同步，从库变为新值

        上述情形，就是数据不一致的原因。还是使用延时双删策略。只是，睡眠时间修改为在主从同步的延时时间基础上，加几百ms。

        先写数据库，再删缓存

        上面的方案中，我们发现在更新数据库前删除缓存，并发的读请求可能读到旧数据，并写入缓存中，导致数据不一致，虽然有延时双删，但也不能保证一定不出现问题。那我们再来看看最后一种方案先写数据库，再删缓存能否解决问题。

                                                

        在高并发的场景中，有一个读数据请求，有一个写数据请求，更新过程如下：

• 正常情况下

        （1）请求f查询缓存，发现缓存中有数据，直接返回该数据。
        （2）请求e先写数据库。
        （3）请求e删除缓存。

        无缓存数据不一致问题，一切正常。

• 非正常情况下

        （1）请求e先写数据库，由于网络原因卡顿了一下，没有来得及删除缓存。
        （2）请求f查询缓存，发现缓存中有数据，直接返回该数据。
        （3）请求e删除缓存。

        在这个过程中，只有请求f读了一次旧数据，后来旧数据被请求e及时删除了，看起来问题不大。

        那么，这种方案还有别的风险了吗？自然是有的。

        （1）缓存过期时间到了，自动失效。
        （2）请求f查询缓存，发缓存中没有数据，查询数据库的旧值，但由于网络原因卡顿了，没有来得及更新缓存。
        （3）请求e先写数据库，接着删除了缓存。
        （4）请求f更新旧值到缓存中。
        这时，缓存和数据库的数据同样出现不一致的情况了。

        但这种情况还是比较少的，需要同时满足以下条件才可以：

• 缓存刚好自动失效。
• 请求f从数据库查出旧值，更新缓存的耗时，比请求e写数据库，并且删除缓存的还长。

        我们都知道查询数据库的速度，一般比写数据库要快，更何况写完数据库，还要删除缓存。所以绝大多数情况下，写数据请求比读数据情况耗时更长。

        由此可见，系统同时满足上述两个条件的概率非常小。因此推荐使用先写数据库，再删缓存的方案，虽说不能100%避免数据不一致问题，但出现该问题的概率，相对于其他方案来说是最小的。

        假设，有人非要抬杠，有强迫症，一定要解决怎么办？

        首先，给缓存设有效时间是一种方案。其次，采用前文里给出的延时双删的策略，保证读请求完成以后，再进行删除操作。

        缓存删除失败的解决方案

        思路

        先写数据库，再删缓存的方案，跟缓存双删的方案一样，有一个共同的风险点，即：如果缓存删除失败了，也会导致缓存和数据库的数据不一致。

        为了解决这个问题，我们可以采用重试机制。如果遇到更新缓存失败，可以立刻重试3次。如果其中有任何一次成功，则直接返回成功。如果3次都失败了，则写入数据库，准备后续再处理。

        当然，如果你在接口中直接同步重试，该接口并发量比较高的时候，可能有点影响接口性能。这时，就需要改成异步重试了。下面我们讲讲可行的几种方法。

        定时任务

        当用户操作写完数据库，但删除缓存失败了，需要将用户数据写入重试表中。                                    

         在定时任务中，异步读取重试表中的用户数据。重试表需要记录一个重试次数字段，初始值为0。然后重试5次，不断删除缓存，每重试一次该字段值+1。如果其中有任意一次成功了，则返回成功。如果重试了5次，还是失败，则我们需要在重试表中记录一个失败的状态，等待后续进一步处理。

        

        使用定时任务重试的话，有个缺点就是实时性没那么高，对于实时性要求特别高的业务场景，该方案不太适用。但是对于一般场景，还是可以用一用的。它有一个很大的优点，即数据是落库的，不会丢数据。

        消息队列

        （1）当用户操作写完数据库，但删除缓存失败了，产生一条mq消息，发送给mq服务器。
        （2）mq消费者读取mq消息，重试5次删除缓存。如果其中有任意一次成功了，则返回成功。如果重试了5次，还是失败，则写入死信队列中。

        该方案中，删除缓存可以采用异步的方式。即用户的写操作，在写完数据库之后，不用立刻删除一次缓存。而直接发送mq消息，到mq服务器，然后有mq消费者全权负责删除缓存的任务。

        binlog

        无论是定时任务，还是mq（消息队列），做重试机制，对业务都有一定的侵入性。在使用定时任务的方案中，需要在业务代码中增加额外逻辑，如果删除缓存失败，需要将数据写入重试表。而使用mq的方案中，如果删除缓存失败了，需要在业务代码中发送mq消息到mq服务器。
        其实，还有一种更优雅的实现，即监听binlog，比如使用：canal等中间件。

        （1）在业务接口中写数据库之后，就不管了，直接返回成功。
        （2）mysql服务器会自动把变更的数据写入binlog中。
        （3）binlog订阅者获取变更的数据，然后删除缓存。

        这套方案中业务接口确实简化了一些流程，只用关心数据库操作即可，而在binlog订阅者中做缓存删除工作。但如果只是按照图中的方案进行删除缓存，只删除了一次，也可能会失败。

         这就需要加上前面聊过的重试机制了。如果删除缓存失败，写入重试表，使用定时任务重试。或者写入mq，让mq自动重试。

         在binlog订阅者中如果删除缓存失败，则发送一条mq消息到mq服务器，在mq消费者中自动重试5次。如果有任意一次成功，则直接返回成功。如果重试5次后还是失败，则该消息自动被放入死信队列，后面可能需要人工介入。

        上文中先写数据库再删除缓存，在缓存更新模式中被称为Cache Aside Pattern（旁路缓存），是使用最广泛的模式，除了旁路缓存还有Read/Write Through Pattern（读/写穿透）与Write Behind Caching Pattern（缓存后写）等，有兴趣的可以看看这篇文章《缓存更新的套路》，这里不做详细介绍了。