缓存与库先写哪个,这十几张图告诉你

Posted IT牧场

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了缓存与库先写哪个,这十几张图告诉你相关的知识,希望对你有一定的参考价值。



技术干货每日送达

作者|莱乌


日常生产场景中,为了避免大量请求同时打在数据库上导致故障,数据库+缓存的方式已经成了日常标配。


对于读取的部分,大家都很熟悉。但是对于写的部分,到底是先写库还是先写缓存,这点可能困扰着很多人。


各位看官请跟随小莱往下看:


缓存与库先写哪个,这十几张图告诉你

- 思维导图 -




旁路缓存策略


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


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


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

  • 基本读取方式;

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


1、基本读取方式


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


这没什么可说的,平时都这么用。如果还不清楚,看下小莱为大家画的图:


缓存与库先写哪个,这十几张图告诉你

那我们再看写的部分。


2、先更新数据库,后删除缓存


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


  • 频繁更新浪费资源


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


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


  • 缓存数据计算复杂


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


  • 两种情况都具备


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


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


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


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


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


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


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


缓存与库先写哪个,这十几张图告诉你

缓存与库先写哪个,这十几张图告诉你

缓存与库先写哪个,这十几张图告诉你


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


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




双写一致方案

1、先删除缓存,后更新数据库


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


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


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


缓存与库先写哪个,这十几张图告诉你

缓存与库先写哪个,这十几张图告诉你

缓存与库先写哪个,这十几张图告诉你


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


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


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


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


2、缓存延时双删策略


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


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


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


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


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


缓存与库先写哪个,这十几张图告诉你


解决方案呢?延时双删策略:



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


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




总结


旁路缓存策略


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

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


双写一致方案


  • 先删除缓存,后更新数据库:


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


  • 缓存延时双删策略:


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


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

干货分享

001:《Java并发与高并发解决方案》学习笔记;002:《深入JVM内核——原理、诊断与优化》学习笔记;003:《Java面试宝典》004:《Docker开源书》005:《Kubernetes开源书》006:《DDD速成(领域驱动设计速成)》007:全部008:加技术群讨论

近期热文

关注我

喜欢就点个"在看"呗^_^

以上是关于缓存与库先写哪个,这十几张图告诉你的主要内容,如果未能解决你的问题,请参考以下文章

6张图为你分析Kafka Producer 消息缓存模型

6张图为你分析Kafka Producer 消息缓存模型

魔兽争霸3地图编辑器中游戏缓存怎么用?

用十张图帮你解析RecyclerView的缓存复用机制了~

[转] 通俗讲解:缓存缓存算法和缓存框架

腾讯云布道师贺嘉详解“小程序”:6张图告诉你新机会是什么