数据管理《一》——缓存和数据库的数据一致性

日常生产场景中，为了避免大量请求同时打在数据库上导致故障，数据库+缓存的方式已经成了日常标配。现在简单分析一下几种常用的策略。

一、旁路缓存策略

 提到这个有逼格的名词你可能不是很熟悉，但是说到它的使用方式，你肯定用过。

 这是一种最经典的缓存+数据库读写的模式，英文是这样 Cache Aside Pattern，可能你见过。

 这种模式对应的使用方式有两种情况，一读一写：

• 基本读取方式；

• 先更新数据库，后删除缓存。

1.1、基本读取方式

这部分相信大家已经轻车熟路：先读缓存，缓存中没有数据的话就去数据库读取，然后再存入缓存中，同时返回响应。

1.2、先更新数据库，后删除缓存

你可能会问了，为什么不在更新完数据库后，采取更新缓存的方案，而是将其删除。原因有这么几点：

• 频繁更新浪费资源

你想想，如果修改库中的某个字段，一段时间内频繁进行更新。那么你修改多少次，缓存也跟着更新多少次。但是这个缓存数据在这段时间内也就被偶尔使用了几次。

那么你看，是不是就会导致资源浪费了。

• 缓存数据计算复杂

还有一种情况，如果这个缓存的数据计算成本比较高。比如为了一个数据，要通过多张表来计算才能得到结果。那么每修改一次，为了更新缓存还要再查询多张表来算一次，我的天。

• 两种情况都具备

这种情况最为致命，不但修改频繁，同时缓存数据还要经过复杂计算。

生产环境里要是这么搞的话，那估计你就可以准备简历了。

既然更新缓存的方式不可行，那么我们换个思路，删除掉呢？

还是按照上边的步骤，先更新数据库，只是我们把更新缓存的操作换成了删除。

在这种情况下，读请求过来的时候，发现 Redis 中没有数据，就会去数据库里读取，然后写入缓存中。

这也是一种懒加载方式，只有缓存被需要的时候才会去计算。这样可以避免大量计算及频繁更新。

但是，这样会有什么隐患的问题？是不是看着没什么毛病。你想想，如果数据更新成功，但是删除缓存失败怎么办？

 

 

如图中所示，刚开始时（初始），数据库和缓存中的数据是一致的，但是在写请求过来后，数据库更新成功，而缓存删除失败。这就导致数据库中的数据是最新的，但缓存中却依然存着旧数据。 

这时，如果读请求过来，就会直接读取缓存中的旧数据返回了。

二、双写一致方案

2.1、先删除缓存，后更新数据库

既然问题的原因是删除缓存失败了，那么我们先确保把缓存删除成功了，再去更新数据库。也就是说我们先删除缓存，后更新数据库。

可能你会问了，如果我数据库更新失败了呢？

我们不妨通过图来看下这种情况：

 

 

缓存删除成功后为空了，但是数据库却失败了，还是原来的旧数据。

如果这时候有请求过来的话，一看缓存中没有数据，于是就到数据库读取了旧数据更新到缓存中。

如果你的项目并发量很低的话，每天访问量就那么点，那这么用没毛病，很少情况下才会出现数据不一致的问题。

这种策略只能算作初级的解决方案，为什么这么说呢？

2.2、缓存延时双删策略

如果同时来了两个请求，一个写请求，一个读请求。

写请求先删除Redis中的数据，然后去数据库进行更新操作。

读请求判断Redis中有没有数据，没有数据时去请求数据库，拿到数据后写入缓存中。

但是写请求此时并没有更新成功，或者执行了一个事务还没有成功。

这样的话，读请求拿到未修改的旧数据写入缓存。过了一会儿，写请求将数据库更新成功了，那么此时缓存与库中的数据就不一致了。

 

解决方案呢？延时双删策略：

 

写请求过来先把 Redis缓存删掉，等数据库更新成功后，异步等待一段时间再次把缓存删掉。

这种方案读取速度快，但是会出现短时间的脏数据。

 

public void write(String key,Object data){

redis.delKey(key);

db.updateData(data);

Thread.sleep(1000);

redis.delKey(key);

}

 

转化为中文描述就是
（1）先淘汰缓存
（2）再写数据库（这两步和原来一样）
（3）休眠1秒，再次淘汰缓存
这么做，可以将1秒内所造成的缓存脏数据，再次删除。

那么，这个1秒怎么确定的，具体该休眠多久呢？
针对上面的情形，读者应该自行评估自己的项目的读数据业务逻辑的耗时。然后写数据的休眠时间则在读数据业务逻辑的耗时基础上，加几百ms即可。这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。

如果你用了mysql的读写分离架构怎么办？
ok，在这种情况下，造成数据不一致的原因如下，还是两个请求，一个请求A进行更新操作，另一个请求B进行查询操作。
（1）请求A进行写操作，删除缓存
（2）请求A将数据写入数据库了，
（3）请求B查询缓存发现，缓存没有值
（4）请求B去从库查询，这时，还没有完成主从同步，因此查询到的是旧值
（5）请求B将旧值写入缓存
（6）数据库完成主从同步，从库变为新值
上述情形，就是数据不一致的原因。还是使用双删延时策略。只是，睡眠时间修改为在主从同步的延时时间基础上，加几百ms。

采用这种同步淘汰策略，吞吐量降低怎么办？
ok，那就将第二次删除作为异步的。自己起一个线程，异步删除。这样，写的请求就不用沉睡一段时间后了，再返回。这么做，加大吞吐量。

第二次删除,如果删除失败怎么办？
这是个非常好的问题，因为第二次删除失败，就会出现如下情形。还是有两个请求，一个请求A进行更新操作，另一个请求B进行查询操作，为了方便，假设是单库：
（1）请求A进行写操作，删除缓存
（2）请求B查询发现缓存不存在
（3）请求B去数据库查询得到旧值
（4）请求B将旧值写入缓存
（5）请求A将新值写入数据库
（6）请求A试图去删除请求B写入对缓存值，结果失败了。
ok,这也就是说。如果第二次删除缓存失败，会再次出现缓存和数据库不一致的问题。

 

如何解决？
提供一个保障的重试机制即可，这里给出两套方案。

方案一：如下图所示

流程如下所示
（1）更新数据库数据；
（2）缓存因为种种问题删除失败
（3）将需要删除的key发送至消息队列
（4）自己消费消息，获得需要删除的key
（5）继续重试删除操作，直到成功
然而，该方案有一个缺点，对业务线代码造成大量的侵入。于是有了方案二，在方案二中，启动一个订阅程序去订阅数据库的binlog，获得需要操作的数据。在应用程序中，另起一段程序，获得这个订阅程序传来的信息，进行删除缓存操作。

方案二：

 

流程如下图所示：

更新数据库数据
数据库会将操作信息写入binlog日志当中
订阅程序提取出所需要的数据以及key
另起一段非业务代码，获得该信息
尝试删除缓存操作，发现删除失败
将这些信息发送至消息队列
重新从消息队列中获得该数据，重试操作。
备注说明：上述的订阅binlog程序在mysql中有现成的中间件叫canal，可以完成订阅binlog日志的功能。至于oracle中，博主目前不知道有没有现成中间件可以使用。另外，重试机制，博主是采用的是消息队列的方式。如果对一致性要求不是很高，直接在程序中另起一个线程，每隔一段时间去重试即可，这些大家可以灵活自由发挥，只是提供一个思路。

三、总结

旁路缓存策略

• 读的时候，先读缓存，缓存没有的话，再去读数据库，然后取出来放入缓存中，同时返回响应。

• 更新的时候，先更新数据库，再删除缓存。

双写一致方案

• 先删除缓存，后更新数据库：

解决了缓存删除失败导致库与缓存不一致的问题，适用于并发量不高的业务场景。

• 缓存延时双删策略：

这种方案解决了高并发情况下，同时有读请求与写请求时导致的不一致问题。读取速度快，但是可能会出现短时间的脏数据。

每种方案各有利弊，对于不同的业务来说没有通用的技术方案。在选择技术方案时需要根据业务自身来定。没有最好的，只有最合适的。

 

 

附录

数据库和Redis缓存一致性解决方案