为了提高数据库的效率,常采用数据库+缓存的方式;
对于数据的获取都是先查询缓存,如果缓存中没有再去查数据库,将数据库查询结果返回并进行缓存;
但是对于写的部分,执行顺序就会困扰许多朋友们,顺序不当会导致缓存中数据与数据库中的不一致,到底是先写缓存还是还是先写数据库表呢?您往下看:
旁路缓存策略
基本读取方式
先来看读取方式:先读缓存,缓存中没有数据的话就去数据库读取,然后再存入缓存中,同时返回响应。这没啥好说的,看图说话:
先更新数据库,后删除缓存
再来看写的部分,出于本能反应,你可能会问,为什么不在更新完数据库后,采取更新缓存的方案,而是将其删除,确实,这样做在许多业务场景下也是可以的。但是遇到以下场景你就要小心了。
(1)频繁更新浪费资源
不妨思考一下,如果一段时间内频繁更新库中的某个字段。那么更新多少次,缓存也跟着更新多少次。但是这个缓存数据在这段时间内也就被偶尔查询了几次。那么是不是就会导致资源浪费了呢?
(2)缓存数据计算复杂
有一种情况,如果这个缓存的数据计算成本比较高。比如为了一个数据,要通过多张表来计算才能得到结果。那么每修改一次,为了更新缓存还要再查询多张表来算一次,岂不是得不偿失。
(3)两种情况都具备
这种情况最为致命,不但修改频繁,同时缓存数据还要经过复杂计算。
既然更新缓存的方式不可行,那么换个思路,删除掉呢?
还是按照上边的步骤,先更新数据库,只是把更新缓存的操作换成了删除缓存。
在这种情况下,读请求过来的时候,因为更新操作时缓存中数据被删除了,就会去数据库里读取,然后写入缓存中。这是一种懒加载方式,只有缓存被需要的时候才会去计算。这样可以避免大量计算及频繁更新。
是不是看着没什么毛病。你在仔细想想,如果数据更新成功,但是删除缓存失败会怎样?
如图所示,初始状态数据库和缓存中的数据是一致的,但是在写请求过来后,数据库更新成功,而缓存删除失败。这就导致数据库中的数据是最新的,但缓存中却依然存着旧数据。这时,如果读请求过来,就会直接读取缓存中的旧数据返回。
双写一致性解决方案
1、先删除缓存,后更新数据库
既然问题的原因是删除缓存失败了,那么我们先确保把缓存删除成功了,再去更新数据库。也就是说我们先删除缓存,后更新数据库。
此时你可能会从脑子里迸发出一个想法,如果数据库更新失败了呢?不妨来看一下这种情况:
缓存删除成功后为空了,但是数据库却失败了,还是原来的旧数据。如果这时候有请求过来的话,一看缓存中没有数据,于是就到数据库读取了旧数据更新到缓存中。
你是不是觉得已经“万事大吉”,收工吃饭去了?别急,看看还有什么问题。
2、缓存延时双删策略
如果项目并发量很低的话,每天访问量就那么点,那这么用“先删除缓存,后更新数据库”的方法没毛病,很少情况下才会出现数据不一致的问题。但这种策略只能算作初级的解决方案,为什么这么说呢?
并发量高的情况下,很有可能如果同时来了两个请求,一个写请求,一个读请求。
写请求先删除缓存中的数据,然后去数据库进行更新操作。但是,写请求此时并没有更新成功,或者执行了一个事务还没有成功。
就在此时,读请求判断缓存中有没有数据,就去请求数据库,拿到数据后写入缓存中。
这样的话,读请求拿到未修改的旧数据并写入缓存。过了一会儿,写请求将数据库更新成功了,那么此时缓存与库中的数据就不一致了。
可能你有点乱,我用图来解释一下:
解决方案
写请求过来先把 Redis缓存删掉,等数据库更新成功后,异步等待一段时间再次把缓存删掉。
这种方案读取速度快,但是会出现短时间的脏数据。
总结
旁路缓存策略
读的时候,先读缓存,缓存没有的话,再去读数据库,然后取出来放入缓存中,同时返回响应。
更新的时候,先更新数据库,再删除缓存。
双写一致方案
先删除缓存,后更新数据库:
解决了缓存删除失败导致库与缓存不一致的问题,适用于并发量不高的业务场景。
缓存延时双删策略:
这种方案解决了高并发情况下,同时有读请求与写请求时导致的不一致问题。读取速度快,但是可能会出现短时间的脏数据。
注意
每种方案各有利弊,对于不同的业务来说没有通用的技术方案。在选择技术方案时需要根据业务自身来定。没有最好的,只有最合适的。