一 面试题引入
- 你只要用缓存,就可能会涉及到redis缓存与数据库双存储双写,你只要是双写,就一定会有数据一致性的问题,那么你如何解决一致性问题?
- 双写一致性,你先动缓存redis还是数据库mysql哪一个?why?
- 延时双删你做过吗?会有哪些问题?
- 有这么一种情况,微服务查询redis无mysql有,为保证数据双写一致性回写redis你需要注意什么?
双检加锁
策略你了解过吗?如何尽量避免缓存击穿? - redis和mysql双写100%会出纰漏,做不到强一致性,你如何保证
最终一致性?
二 缓存双写一致性
- 如果redis中有数据:需要和数据库中的值相同
- 如果redis中无数据:数据库中的值要是最新值,且准备回写redis
- 缓存按照操作来分,细分2种
- 只读缓存:
- 读写缓存:
同步直写策略:
- 写数据库后也同步写redis缓存,缓存和数据库中的数据一致。
- 对于读写缓存来说,要想保证缓存和数据库中的数据一致,就要采用同步只写策略。
异步缓写策略:
- 正常业务允许中,mysql数据变动了,但是可以在业务上容许出现一定时间后才作用于redis,比如仓库、物流系统。
- 异常情况出现了,不得不将失败的动作重新修补,有可能需要借助Kafka或者RabbitMQ等消息中间件,实现重试重写。
三 双写双检加锁策略
当高并发的情况下,采用双检加锁策略:
多个线程同时去查询数据库的这条记录,那么我们可以在第一个查询数据的请求上使用一个互斥锁来锁住它
。其他的线程走到这一步拿不到锁就等着,等第一个线程查询到了数据,然后做缓存。后面的线程进来发现已经有缓存了,就直接走缓存。
public String get(String key){
String value = redis.get(key);//查询缓存
if(value != null){
//缓存存在直接返回
return value;
}else{
//缓存不存在则对方法加锁
//加锁请求量很大,缓存过期(对于高QPS的优化)
synchronized(TestFuture.class){
value = redis.get(key);//再查一遍redis
if(value != null){
//查到数据直接返回
return value;
}else{
//二次查询缓存也不存在,直接查DB
value = dao.get(key);
//数据缓存
redis.setnx(key,value,time);
//返回
return value;
}
}
}
}
四 数据库和缓存一致性的集中更新策略
4.1 最终一致性
给缓存设置过期时间,定期清理缓存并回写,是保证最终一致性的解决方案。
我们可以对存入缓存的数据设置过期时间,所有的写操作以数据库为准
,对缓存操作只是尽最大努力即可。也就是说如果数据库写成功,缓存更新失败,那么只要到达过期时间,则后面的读请求自然会从数据库中读取新增然后回填缓存,达到一致性。切记,要以mysql的数据库写入库为准。
4.2 可以关机的情况下
挂牌报错、凌晨升级,温馨提示、服务降级
使用单线程,这样重量级的数据操作最好不要多线程。
4.3 不能关机的情况下,四种更新策略
4.3.1 先更新数据库,再更新缓存
- 更新redis失败,导致数据库和缓存redis里面数据不一致,读到redis脏数据。
- 先更新数据库,再更新缓存,A/B两个线程发起调用。
异常情况下:多线程环境下,A/B两个线程有快有慢,导致写入mysql顺序与更新redis顺序不一致,使两端数据不一致。
4.3.2 先更新缓存,再更新数据库
不推荐,业务上一般把mysql作为底单数据库,保证最后解释。
异常情况下:多线程环境下,A/B两个线程有快有慢,导致写入redis顺序与更新mysql顺序不一致,使两端数据不一致。
4.3.3 先删除缓存,再更新数据库
-
异常情况
- A线程先成功删除了redis里面的数据,然后去更新mysql,此时mysql正在更新中,还没有结束(比如网络延迟),B线程突然出现要读取缓存数据。
- 此时redis里面的数据时空的,B线程来读取,此时有2个问题:
- B从mysql中获取到了旧值:B线程发现redis里没有(缓存缺失)马上去mysql里面读取,从数据库里面读取来的是旧值
- B会把获取到的旧值写回redis:获得旧值数据后返回前台并回写进redis(刚被A线程删除的旧数据有极大可能又被写回了)
- A线程更新完mysql,发现redis里面的缓存是脏数据,
-
解决方案:采用延时双删策略
加上sleep的这段时间,就是为了让线程B能够先从数据库读取数据,再把缺失的数据写入缓存。然后,线程A再进行删除。所以,线程A sleep的时间,就需要大于线程B读取数据再写入缓存的时间。这样一来,其它线程读取数据时,会发现缓存缺失,所以会从数据库中读取最新值。因为这个方案会在第一次删除缓存值后,延迟一段时间再次进行删除,所以我们也把它叫做“延迟双删”。 -
延时双删策略问题引入:
- 这个删除该休眠多久呢?
线程A sleep的时间,就需要大于线程B读取数据再写入缓存的时间。
这个时间如何确定呢?
第一种方法:在业务程序运行的时候,统计下线程读数据和写缓存的操作时间,自行评估自己项目的读数据业务逻辑的耗时,以此为基础来进行估算,然后写数据的休眠时间则在数据业务逻辑的耗时基础上加百毫秒
即可。
这么做的目的,就是确保读请求结束,写请求可以删除读请求造成的缓存脏数据。
第二种方法:新启动一个后台监控程序(如:WatchDog) - 这种同步淘汰策略,吞吐量降低怎么办?
- 这个删除该休眠多久呢?
4.3.4 先更新数据库,再删除缓存(主流)–实现最终一致性
- 异常问题:假如缓存删除失败或者来不及,导致请求再次访问redis时缓存命中,读取到的是缓存旧值。
- 解决方案:
- 可以把要删除的缓存值或者是要更新的数据库值暂存到消息队列中(例如使用Kafla/RabbitMQ等)。
- 当程序没有能够成功地删除缓存值或者是更新数据库值时,可以从消息队列中重新读取这些值,然后再次进行删除或者更新。
- 如果能够成功地删除或更新,我们就要把这些值从消息队列中去除,以免重复操作,此时,我们也可以保证数据库和缓存的一致性,否则还需要再次进行重试。
- 如果重试超过了一定次数后还没有成功,我们就需要向业务层发送报错信息了,通知运维人员。
五 总结
5.1 如何选择方案?利弊如何?
优先使用先更新数据库,再删除缓存的方案(先更库–>后删库),理由如下:文章来源:https://www.toymoban.com/news/detail-454407.html
- 先删除缓存值再更新数据库,有可能导致请求因缓存缺失而访问数据库,给数据库带来压力导致打满mysql。
- 如果业务应用中读取数据库和写缓存的时间不好估算,那么延迟双删中的等待时间就不好设置。
文章来源地址https://www.toymoban.com/news/detail-454407.html
到了这里,关于Redis缓存双写一致性之更新策略的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!