番禺区怎么做网站建设,做网站需要买服务器吗,河北邯郸有什么好玩的地方,百度竞价排名什么意思目录
数据不一致问题
数据库和缓存不一致解决方案
1. 先更新缓存#xff0c;再更新数据
该方案数据不一致的原因
2. 先更新数据库#xff0c;再更新缓存
3. 先删除缓存#xff0c;再更新数据库
延时双删
4. 先更新数据库#xff0c;再删除缓存
该方案数据不一致的…目录
数据不一致问题
数据库和缓存不一致解决方案
1. 先更新缓存再更新数据
该方案数据不一致的原因
2. 先更新数据库再更新缓存
3. 先删除缓存再更新数据库
延时双删
4. 先更新数据库再删除缓存
该方案数据不一致的场景和解决办法
缓存删除失败该如何处理
MQ异步重试删除
监控binlog删除
面试中关于Redis双写一致性如何应答
如何实现强一致性 在数据库层和客户端层添加一层缓存可以提高用户的访问性能。
比如一些商品秒杀业务这时并发量高要是所有请求都是打到数据库层(用MySQL举例),那用户的体验可能就不太好因为操作数据库是要操作磁盘性能比较低。而中间加一层缓存(用Redis举例把数据存储在Redis中。Redis是基于内存的操作速度极快那并发量就可以提高了。 数据不一致问题
那就会引出问题出现Redis和MySQL的数据不一致问题。由于缓存和数据库是分开的无法做到原子性的同时进行数据修改可能出现缓存更新失败或者数据库更新失败的情况这时候会出现数据不一致影响业务。
数据库和缓存不一致解决方案
大方向有三种
Cache Aside Pattern 旁路缓存模式也叫人工编码方式需要程序员写代码 同时维系 DB 和 cache。也称作双写方案。Read/Write Through Pattern缓存与数据库整合为一个服务由服务来维护一致性。调用者调用该服务无需关系缓存一致性问题。但是维护这样一个服务很复杂市面上也不容易找到一个这样现成的服务开发成本高。Write Behind Caching Pattern调用者只操作缓存其他线程异步去处理数据库最终实现一致性。但是维护这样的一个异步任务比较复杂需要实时监控缓存中的数据更新而其他线程异步去更新数据库也可能不太及时而且缓存服务器如果宕机那么缓存的数据也就丢失了。
综上所述在企业的实际应用中还是Cache Aside Pattern方案最可靠。现在确定了该方案但是需要程序员去调用缓存和数据库那因为是两个应用那操作就有先后顺序那是应该先操作哪个呢还有是更新缓存还是删除缓存呢
可以分成4种情况
先更新缓存再更新数据先更新数据库再更新缓存先删除缓存再更新数据库先更新数据库再删除缓存
现在来逐个分析下其优缺点和是否可用。
1. 先更新缓存再更新数据 首先给结论——该方案不可行。
场景1事务问题导致数据不一致 在MySQL写入或者其他业务逻辑出现异常错误时候MySQL会进行回滚那MySQL中数据会变回100而Redis就会更新为100这就出现了数据不一致问题。
这个就是因为Redis和MySQL两个数据库写操作不具备事务的ACID特性无法保证这两个写操作的原子性。
发生该问题的场景有如下两个
修改Redis成功修改MySQL失败而Redis不会回滚整个过程其他业务逻辑出现异常MySQL会回滚而Redis却不会回滚。
场景2多并发更新 上图所示线程1修改Redis数据之后线程2抢占了cpu时间那MySQL最终结果是200就和Redis的数据不一致。这就是线程并发导致数据覆盖造成数据不一致。
所以先更新缓存再更新数据库这种方法不可行。
该方案数据不一致的原因
不同数据库之间双写不具备事务原子性造成数据不一致线程并发导致数据覆盖造成数据不一致
2. 先更新数据库再更新缓存 首先给结论——该方案不可行。
原因和先更新缓存再更新数据库是一样的。
场景1修改账户余额整个过程其他业务逻辑出现异常MySQL进行回滚而Redis却不会回滚。 场景二多线程并发更新用户账户余额 也是因为并发线程1修改数据库后线程2抢占了cpu时间最终导致结果不一致。
所以先更新数据库再更新缓存 也不行。
两点原因
不同数据库之间双写不具备事务原子性造成数据不一致线程并发导致数据覆盖造成数据不一致
3. 先删除缓存再更新数据库
场景多线程并发更新用户余额 上图的情况①、②、③都不会导致数据不一致而情况④会导致数据不一致。线程1在Redis中删除之后线程2抢占cpu时间去查询Redis,而Redis数据是空那就需要去查询MySQL 。导致了最终Mysql数据是200而Redis为100。
那使用这个方法还有什么其他策略可以修复情况④吗也是可以的这个就是延时双删。
延时双删 在线程1更新完数据库后再次删除Redis中的数据目的是为了清楚缓存中的脏数据。那么对这个删除执行的时刻是有要求的不能在线程2修改前执行一般其时长是要大于一次业务查询时间所以这个就是延时双删。
其实这个时长不好掌控有时有些业务的查询时间可长可短。
4. 先更新数据库再删除缓存 情况①是正常的。情况②出现了短暂的数据不一致问题那这个就需要业务可以接受。
情况③就出现了较长时间的数据不一致情况。
那其是在什么情况出现的呢要满足下面两个条件其效率是很低的
在读写并发时候缓存刚好失效且数据库查询耗时远大于更新耗时
所以先更新数据库再删除缓存 方案可用。但是要允许读写并发场景下出现短暂不一致情况和极端情况下产生的数据不一致情况但是数据是最终一致的。
该方案数据不一致的场景和解决办法
并发读写情况下产生的短暂不一致场景业务场景要能接受。并发读写情况下缓存正好失效且读操作耗时大于写操作而产生的数据不一致。可以通过延时删除或者给redis设置较短的存活时间。
缓存删除失败该如何处理 MySQL更新失败可以回滚而Redis删除失败却不会回滚。那该如何处理缓存删除失败的情况呢
MQ异步重试删除 其优点就是实现简单容易理解。
缺点就是添加了个组件那整个系统的可用性又要维护多一个组件并且耦合度比较高那每次使用Redis时候都需要写判断是否成功不成功就抛给mq的代码。
监控binlog删除 其优点实现了缓存删除的业务解耦
缺点实现是比较复杂的。
面试中关于Redis双写一致性如何应答
分成4步
摆方案保证Redis与MySQL数据库的双写一致性大方向有三种方案Cache Aside Pattern 旁路缓存模式、Read/Write Through Pattern缓存与数据库整合为一个服务、Write Behind Caching Pattern。而企业中大多数是使用Cache Aside Pattern查询的时候优先从缓存中查缓存中没有数据再从数据库中查然后把数据库中的最新值写入到缓存中保证了数据一致性。 ● 该模式有四种方案①先更新缓存再更新数据库、②先更新数据再更新缓存、③先删除缓存再更新数据库、④先更新数据再删除缓存。排除不合理的方案:两种双更新的方案不可用原因有两个 第一是因为我们不能保证两个数据库之间写操作的事务原子性所以可能有一个成功一个失败造成数据不一致。第二是因为并发写操作会造成数据的覆盖导致数据不一致。列可用方案阐述注意事项目前常用的但是这两个问题对于很多业务场景都可以容忍的方案有两个。 先删除缓存再更新数据库该方案理想情况下是没有问题的。但还是有一个特殊场景是有可能出现数据不一致具体来讲是在发生并发读写时线程A先删除了缓存还没来得及更新数据库线程B此时来查询缓存为空于是查询到了数据库的旧值而后将缓存修改成了旧值解决方案就是采用延时双删在线程A更新完数据库后延时一段时间再删除缓存合理的延长时长需要更具业务而定通常为一次查询业务的耗时。先更新数据库再删除缓存该方案在理想情况下也是没有问题的。但是该方案有两个特殊场景是有可能出现数据不一致问题的第一种是由于并发读写导致的短暂不一致但是最终数据一致。第二种场景出现几率很低要求并发读写时缓存正好失效且数据库查询耗时远远大于更新耗时才有可能发生数据不一致这个当然也是可以通过延时双删或者给Redis数据设置较短的存活时间来达到最终一致。对比这两个方案最终还是使用先更新数据库再删除缓存。补充如何保证缓存成功删除之前两种方案都是通过删除缓存来保证双写一致性的要是缓存删除失败会导致缓存中都是脏数据所以必须保证缓存删除成功方案有两种 第一种使用MQ异步重试删除比较简单缺点是会对业务代码产生入侵耦合度比较高。第二种使用阿里的canal模拟MySQL的从库监听主库的binlog,当数据库发生变更canal可以监听到并通知客户端去删除缓存其优点是对业务代码没有入侵性进行了解耦。
如何实现强一致性
最终我们还有一个问题没有解决不论是以上介绍的哪种方案都会出现数据不一致性只是出现这个问题的时间长短不同或者是出现的概率高低不同。
仔细想想我们加入缓存的初衷是什么不就是提高吞吐量获得更高的性能嘛。作为开发者应该都知道一个非常著名的三角悖论CAP定理即对于一个分布式计算系统来说不可能同时满足以下三点
一致性Consistency) 所有节点在同一时间具有相同的数据可用性Availability保证每个请求不管成功或者失败都有响应分区容错性Partition tolerance系统中任意信息的丢失或失败不会影响系统的继续运作
在分布式系统内P 是必然需要的。不选 P一旦发生分区错误整个分布式系统就完全无法使用了这是不符合实际需要的。所以对于分布式系统我们只能考虑当发生分区错误时如何选择一致性和可用性。即只能从CP、AP中选择。既然选择了高性能和高吞吐量所以我们只能满足AP。由此也可明白以上介绍的所有方案都是为了保证将不一致性尽可能的降低都是保证最终一致性。
如果一定要强一致性就是不加入缓存或者使用分布式锁或者读写锁来锁住一次更新数据库和缓存的操作那这样吞吐量性能有会下载可能是得不偿失。
