一、缓存一致性问题
我们现在读所有的数据,都是先来看缓存,缓存中没有我们就来读数据库。假如我们第一次读取,缓存中没有,然后,来查数据库,是一条新值。
现在来考虑一个问题,如果数据库修改了一个数据,而这个数据缓存中也有,我们再来从缓存中拿数据,就是一条旧数据。
所以,就牵扯到另外一个问题,缓存数据一致性问题,缓存里面的数据如何和数据库保持一致。
解决缓存一致性问题,比较常用的两种模式有
1.双写模式
2.失效模式
这两种方式再大并发下,都会产生一些漏洞
二、双写模式
2.1 双写模式思想
首先,我们使用双写模式,我们对数据库做了修改,比如我们修改了一个菜单,然后redis里面的数据想要变,我们改完数据库里面的数据以后,把缓存里面的数据也改一下
2.2 双写模式存在的问题
双写模式,我们的想法是写完以后,把缓存里的数据跟着改一下,假设现在我们模拟两个并发,全部进来
比如1号线程先来执行,它先去改数据库,把数据改成了1,它把数据改完了以后,
此时第二个修改请求,还是改这条数据,它想把这个数据改为2,相当于我们最后一次对数据库的修改想改为2。
但是,如果我们采用双写模式,我们第一个线程改完数据库,要改缓存,但是可能由于各种原因,它改完数据库以后 ,CPU没转到它这,或者它卡顿了一下,它想要写缓存,但是,没有2号线程跑的快。
2号线程,改完数据库以后,嗖一下,把缓存改为了2
但此时呢,1号线程,才慢慢吞吞的将数据写到缓存,改为了1。
此时,我们缓存中就将数据保存成了1,但实际上我们数据库的最新数据是2,而不是1,这相当于我们缓存中就出现了一条脏数据。
所以,我们说,双写模式,会有产生脏数据的风险。
怎么解决这个问题呢?
2.2.1 解决方案一
我们可以考虑一个设计方案,就是加锁,比如我们产生并发写的时候,因为你要改数据库,同时要改缓存,那我们就对整个操作来加一个锁,如果1号先进来了,那么1号得到一个锁,只有1号将它的整个流程全走完了,2号才能得到锁,去来写它的整个流程。
这就不会产生我们说的数据不一致性问题了。
2.2.2 解决方案二
看我们业务允不允许我们数据有暂时性的数据不一致性问题,举一个例子,我们商品数据的菜单数据改了,可能我们5分钟20分钟,我们首页里的网站展示才是我们改了的数据,我们允不允许这种操作呢?如果允许,我们就可以不管这个事情。
不管怎么办?就是我们以前将数据放入缓存的时候,给每一个数据都给了一个过期时间,比如是一天,假如这个数据过期了,我们从redis里面就会自动删除,删了以后下次再来查这个数据,就会查一份新的放到redis里面,所以,我们也可以称为这是暂时性的脏数据问题,前提是,我们在设计的时候,为缓存加上了过期时间。
而且,我们最终也发现,无论我们怎么操作,我们写数据库,完了以后写缓存,缓存里面更新,再来读数据,读到的最新数据,肯定跟数据库那一刻刚存的最新数据,有一段延迟时间,也就是说这一段延迟时间,大家容忍有多大,我们容忍1ms,1s还是1天,无论我们怎么容忍,我们都称这种为最终一致性。
就是我们数据库改后的值,到我们最后看到的值,他们之间有一个比较大的延迟时间,但无论怎么延迟,我们最终都会看到数据库最新修改的值。
所以,我们缓存数据的一致性,就是完全满足我们最终一致性的,我们无论怎么设计,我们都保证最终缓存里面读到的数据,就是数据库里面最新的数据。
这是我们说的双写模式容易出现的问题。
三、失效模式
3.1 失效模式思想
失效模式是,我们把数据库改完,我们直接将缓存删掉,这样做的好处是什么 ?
比如我们将数据库改完了,但是我们缓存中还缓存了我们三级分类的所有数据,比如redis.del(key);
删除以后呢,缓存中就相当于没有数据了,下一次再来查这一个菜单,我们查询方法就会判断,缓存中没有数据,主动查一次数据库。
3.2 失效模式存在问题
失效模式同样存在相同的问题,比如我们举一个例子,比如我们更新数据,数据库更新成功以后,我们再来删除缓存,删除缓存以后,缓存中就没有数据了,下次再来查这个数据,缓存中没有,会主动查数据库,主动更新缓存,自动触发了主动更新功能,最终得到最新的数据。
下面有这样一个场景,现在是三个请求,这三个请求顺序是这样子的,首先第一个请求,还是来改1号的菜单数据,将这个数据改为1,改完以后,删缓存,然后执行完了。
接下来,第二个请求,将我们这个数据改为2,但是,它的机器可能比较慢,花的时间比较长
这时来了第三个请求
现在出现这么一个问题,当第一个请求缓存删完了以后,第二个请求进来读,缓存里面确实没数据,然后它就去读数据库,但是数据库,此时2号数据还没改完,还没提交最新的修改
那就相当于3号读到了老的数据1,然后3号读完以后,它要更新缓存
这又是一个问题,如果它的更新缓存比较快还好,它更了一个错误的缓存,然后我们2号线程写操作,又把缓存删了,相当于它没更新。
但如果它更新的比较慢,2号机器更新完以后,立马把缓存删了,那三号机器之前读到的1,就直接放到缓存里面了
所以,最后我们最新的数据2还是没放到缓存,放到的是旧数据1,还是我们说的脏数据问题。
3.2.1 解决方案
这个问题,是我们写和读的并发问题。这个问题我们还是可以通过加锁来解决,但是加了锁以后,系统比较笨重一点。
所以,我们现在考虑另外一个问题,如果我们这个数据经常修改的话,我们还要不要放缓存?
如果数据经常修改,为了保证我们缓存里面的数据一致性,为写数据,和读数据都加了一个锁,就会导致我们整个系统会慢,还不如不加锁,直接查数据库。
所以,对于经常修改的数据,我们还是直接读数据库。
四、总结
所以,这两种模式无论用哪个都行,但是,如果真的要精细的解决缓存一致性问题,可以有以下解决方案
无论是双写模式还是失效模式,都会导致缓存的不一致问题。即多个实例同时更新会出事。怎么办?
1、如果是用户纬度数据(订单数据、用户数据) ,这种并发几率非常小,不用考虑这个问题,缓存数据加上过期时间,每隔一段时间触发读的主动更新即可
.2、如果是菜单,商品介绍等基础数据,也可以去使用canal订阅binlog的方式。
.3、缓存数据+过期时间也足够解决大部分业务对于缓存的要求。
.4、通过加锁保证并发读写,写写的时候按顺序排好队。读读无所谓。所以适合使用读写锁。(业务不关心脏数据,允许临时脏数据可忽略) ;
总结:
我们能放入缓存的数据本就不应该是实时性、一致性要求超高的。所以缓存数据的时候加上过期时间,保证每天拿到当前最新数据即可。
我们不应该过度设计,增加系统的复杂性
遇到实时性、一致性要求高的数据,就应该查数据库,即使慢点。
我们系统的一致性解决方案:
1.缓存的所有数据都有过期时间,数据过期下一次查询触发主动更新
2.读写数据的时候,加上分布式的读写锁
经常写,经常读的数据,对性能肯定会有极大的影响,但是,读多写少的情况下,影响极小,因为对于读写锁,读读情况,相当于无锁。而且需要分布式下的读写锁,因为有多个实例,保证锁住每一台服务器。
文章来源: blog.csdn.net,作者:星夜孤帆,版权归原作者所有,如需转载,请联系作者。
原文链接:blog.csdn.net/qq_38826019/article/details/115047374