Redis缓存和数据库一致性方案
发布于 2022-05-19 00:17
Redis缓存和数据库一致性方案
如果将Redis运用到生产中,那么Redis肯定会保存一部分数据库中的数据来缓解数据库的压力,如果请求只读那么只需要命中Redis中的数据就返回,没有命中就从数据库中读取后写入到Redis中,这样的运用场景十分普遍,但如果是写操作为了保证Redis缓存和数据库一致性第一反应是不是需要更新缓存和数据库,但这样做能保证一致性吗?如果不能保证有什么解决办法呢?
对于同时更新缓存和数据库无非是两种方案
先更新缓存、再更新数据库。 先更新数据库、后更新缓存。
对于这两种方案在第一步成功,第二步失败的时候就可能造成缓存和数据库的数据不一致,下面按照异常场景分析。
更新缓存一致性分析
先更新缓存后更新数据库
当缓存更新成功数据库更新失败,那么缓存中的数据是最新值,数据库中的值是旧值,对于普通读请求其实短时间并没有影响,因为请求会命中缓存中的数据,但如果出现内存淘汰等情况,那么后续请求将无法命中缓存,需要从数据库中读取但数据库中的值是旧值,这将影响业务正常流转。
先更新数据库后更新缓存
先更新数据库成功那么数据库中的值是新值,缓存中的值是旧值,如果请求命中缓存那么用户读取的数据就是旧数据,而用户实际已经修改,只有等缓存中的值失效后才会从数据库中读取新值,显然这对业务流转也是有影响。
并发场景下的一致性分析
除了考虑普通异常的场景外,我们还需要考虑并发场景下其实存在的问题更多,如下四个方面。
先更新缓存再更新数据库,写+读并发,线程A更新缓存,线程B读请求命中缓存,返回新值,线程A再更新数据库,虽然缓存和数据库有短暂的不一致情况,但影响较小,因为读请求可以在缓存中命中。 先更新数据库再更新缓存,写+读并发,线程A更新数据库,线程B读取缓存,这时线程B读取的是旧缓存的数据返回,线程A更新缓存,后续读请求命中缓存就是新值,虽然有较短的缓存不一致情况,对业务影响也是较小。 先更新缓存再更新数据库,写+写并发,线程A,B更新同一个数据,线程A更新缓存,线程B更新缓存,线程B更新数据库,线程A更新数据库,这样的执行顺序也有可能造成数据不一致。 先更新数据库后更新缓存,写+写并发,和第三点情况类似,执行顺序不同就会造成数据不一致的情况。
除了并发一致性问题,其实我们还可以从缓存的利用率上面思考,我们更新缓存的数据可能经过一系列的计算得出结果,而这个更新的计算结果可能直到缓存淘汰都还未被使用,那这样不仅仅占用CPU资源还占用内存资源,所以这种方案并不友好,我们可以使用另外一种方案如删除缓存。
删除缓存一致性分析
删除方案同样对应两种
先更新数据库后删除缓存。 先删除缓存后更新数据库。
同样在进行第二步失败后就会造成数据不一致的情况,如下
先更新数据库成功,后删除缓存失败,那么后续请求访问命中缓存返回的就是旧数据,只有当缓存数据淘汰后才有能加载更新后的数据。 先删除缓存成功,后更新数据库失败,那么请求在缓存中没有命中,就去数据库中查询这时数据库中就是旧数据,这将对业务影响巨大。
并发场景删除缓存会有什么影响呢?
并发场景下的一致性分析
假设缓存中存在值X=1,线程A需要将X改为2,线程B读取X的值(并发写写这种场景没有数据一致性问题)。
先删除缓存后更新数据库,并发读写,线程A先删除值X的缓存,线程B读取X的值发现缓存中不存在从数据库中读取旧值X=1,线程B将X=1写入缓存中,线程A将X=2的值更新到数据库,这时数据库中最新值为X=2,而缓存中为X=1。 先更新数据库后删除缓存,并发读写,缓存失效X值不在缓存中,线程B从数据库中读取X的旧值,线程A将X的值改为X=2,线程A删除缓存X的值,线程B写入旧值到缓存中,这时缓存和数据库才不一致。
第一点发生的机率较大,第二点发生的几率极小,需要满足这么几点
缓存中的X值刚好失效。 发生并发读写的操作。 线程A执行更新数据库和删除缓存操作的时间要比线程B从数据库中查询数据的时间和将值写入缓存的时间短。
所以采用更新数据库和删除缓存的方案可以尽量保证数据的一致性。
那先删除缓存后更新数据库有数据不一致的情况如何避免呢?这里就可以使用延时双删
延时双删
延时双删从字面理解就是删除两次,在更新数据库之前删除一次,更新数据库完毕后再删除一次。
因为先删除缓存后更新数据库其实就是旧的缓存被回写了,最好的办法就是等待一段时间后再删除一次。
如何保证缓存操作和数据库操作都成功
消息队列
无论是更新缓存还是删除缓存,在同时操作缓存和数据库时,都无法保证两者都能一次性操作成功,所以我们最好的办法就是重试,这个重试并不是立即重试,因为缓存和数据库可能因为网络或者其它原因停止服务了,立即重试成功率极低,而且重试会占用线程资源,显然不合理,所以我们需要采用异步重试机制。
异步重试我们可以使用消息队列来完成,因为消息队列可以保证消息的可靠性,消息不会丢失,也可以保证正确消费,当且仅当消息消费成功后才会将消息从消息队列中删除。
这个方案是近几年比较流行的方案,也就是说业务修改数据时,我们只需要更新数据库,无需修改缓存,那什么时候修改缓存呢?
本文来自网络或网友投稿,如有侵犯您的权益,请发邮件至:aisoutu@outlook.com 我们将第一时间删除。
相关素材