南京模板建网站哪家好,电子商务网站的定义,外部门户网站首页,seo站长提示#xff1a;文章写完后#xff0c;目录可以自动生成#xff0c;如何生成可参考右边的帮助文档 文章目录 缓存一致性问题1、先更新缓存#xff0c;再更新DB方案二#xff1a;先更新DB#xff0c;再更新缓存方案三#xff1a;先删缓存#xff0c;再写数据库推荐1文章写完后目录可以自动生成如何生成可参考右边的帮助文档 文章目录 缓存一致性问题1、先更新缓存再更新DB方案二先更新DB再更新缓存方案三先删缓存再写数据库推荐1延迟双删 方案四先写数据库再删缓存 删除缓存失败怎么办方案一设置过期时间方案二同步重试方案三消息队列方案四订阅mysql的binlog总结 缓存一致性问题
通常情况下我们使用缓存的主要目的是为了提升查询的性能。大多数情况下是这样使用缓存的 当数据库有数据更新时在很长的一段时间内决定于缓存的过期时间用户请求从缓存中获取到的都可能是旧值而非数据库的最新值。那么该如何更新缓存呢目前有以下四种解决方案 先更新缓存再更新数据库差 先更新数据库再更新缓存差 先删除缓存后更新数据库一般 先更新数据库后删除缓存推荐
讨论四种方案前先统一两个认知以便更好理解四种方案
缓存一致性问题没有绝对可靠的方案我们只能让两者尽量接近但无论如何也不能百分百达到一致性效果。缓存和数据库无论先处理谁只要后者有延迟/失败都会导致不一致的情况这也正是缓存不一致的根本原因所在。所有解决方案和讨论都是围绕这一点来进行的。
1、先更新缓存再更新DB 缺点如果刚写完缓存突然网络出现了异常导致写数据库失败了。这样缓存中的数据就变成脏数据这个问题非常严重也是最差的一种解决
方案二先更新DB再更新缓存 缺点一问题又来了写数据库成功但写缓存失败了依然会造成缓存脏数据的问题。但写缓存失败比写数据库失败的概率要小很多了(因为数据库可能有加锁、外键约束、超时等机制限制)所以此方案要比第一种方案好一点。
如果对接口性能要求不高还可以把写数据库和写缓存放到一个事务中写缓存失败就回滚数据库。
缺点二然而高并发场景下还会有个棘手问题
请求a先过来刚写完了数据库。但由于网络原因卡顿了一下还没来得及写缓存。这时候请求b过来了先写了数据库。接下来请求b顺利写了缓存。此时请求a卡顿结束也写了缓存。
很显然在这个过程当中请求b在缓存中的新数据被请求a的旧数据覆盖了。
也就是说在高并发场景中如果多个线程同时执行先写数据库再写缓存的操作可能会出现数据库是新值而缓存中是旧值两边数据不一致的情况。
缺点三浪费系统资源
写的缓存的内容并不是简单的数据而是要经过非常复杂的计算或者查询筛选得出的结果这样每写一次缓存都要计算一次这是非常浪费系统资源的尤其对那些写多读少的业务场景更是雪上加霜。 删除缓存类 方案三先删缓存再写数据库
方案一
嗯看起来还不错。即使写数据库失败了下个请求也会重新触发写缓存操作基本上避免更新缓存的所有弊端然而也不是十全十美。
缺点 请求d先过来把缓存删除了。但由于网络原因卡顿了一下还没来得及写数据库。这时请求c过来了先查缓存发现没数据再查数据库有数据但是旧值。请求c将数据库中的旧值更新到缓存中。此时请求d卡顿结束把新值写入数据库。
这种极端情况下依然会导致写入的缓存为旧值。 推荐1延迟双删 为了避免方案1的避免写完数据库后再删除一次。
该方案有个非常关键的地方是第二次删除缓存并非立马就删而是要在一定的时间间隔之后。
sleep的时间要对业务读写缓存的时间做出评估sleep时间大于读写缓存的时间即可。
那么为什么一定要间隔一段时间之后才能删除缓存呢
请求d卡顿结束把新值写入数据库后请求c将数据库中的旧值更新到缓存中。此时如果请求d删除太快在请求c将数据库中的旧值更新到缓存之前就已经把缓存删除了这次删除就没任何意义。必须要在请求c更新缓存之后再删除缓存才能把旧值及时删除了。
还是mysql读写分离的问题
方案四先写数据库再删缓存 就怕一种情况缓存失效。
缓存自动失效。请求f查询缓存发缓存中没有数据查询数据库的旧值但由于网络原因卡顿了没有来得及更新缓存。请求e先写数据库接着删除了缓存。请求f更新旧值到缓存中。
这时缓存和数据库的数据同样出现不一致的情况了。但这种情况还是比较少的需要同时满足以下条件
缓存刚好自动失效。请求f从数据库查出旧值更新缓存的耗时比请求e写数据库并且删除缓存的耗时还长。
缓存失效。只有可能是查询比删除慢的情况而这种情况相对来说会少很多。同时结合延时双删的处理可以有效的避免缓存不一致的情况。
删除缓存失败怎么办
其实先写数据库再删缓存的方案跟缓存双删的方案一样有一个共同的风险点即如果缓存删除失败了怎么办
方案一设置过期时间
缓存设置一个过期时间比如5分钟。当然这种方案只适合数据更新不是太频繁的业务。
方案二同步重试
在接口中判断是否删除成功如果失败就重试直到成功或超过最大重试次数为止返回数据。当然这种方案的缺点就是可能影响接口性能。
方案三消息队列
将删除缓存任务写入mq等消息中间件中在mq的consumer中处理。但问题也很多
引入消息中间件之后问题更复杂了对业务代码有一定侵入性、消息丢失怎么办 消息本身的延迟也会带来短暂的不一致性不过这个延迟相对来说还是可以接受的
比如基于 RocketMQ 的可靠性消息通信来实现最终一致性。
方案四订阅mysql的binlog
当一条数据发生修改时MySQL 就会产生一条变更日志binlog我们可以订阅这个日志拿到具体操作的数据然后再根据这条数据去删除对应的缓存。 意思就是我们的业务应用在修改数据时「只需」修改数据库无需操作缓存。步骤如下
在业务接口中写数据库之后直接返回成功。mysql服务器会自动把变更的数据写入binlog中。binlog订阅者消费者获取变更的数据然后删除缓存 总结 缓存删除比更新效果更好 举个例子如果数据库1小时内更新了1000次那么缓存也要更新1000次但是这个缓存可能只在最后一次更新后被读取了1次那么前999次的更新有必要吗
反过来如果是删除的话就算数据库更新了1000次那么也只是做了1次缓存删除删除前判断key是否存在只有当缓存真正被读取的时候才去数据库加载 删除缓存有两种方式 先删除缓存再更新数据库。解决方案是使用延迟双删。先更新数据库再删除缓存。解决方案是消息队列或者监听binlog同步引入消息队列会带来更多的问题对业务代码有一定侵入性并不推荐直接使用。 针对缓存一致性要求不是很高的场景那么只通过设置超时时间就可以了。
