。

客户端查询数据时#xff0c;如果能直接命中缓存#xff0c;就不用再去查数据库#xff0c;从而减轻数据库的压力#xff0c;而且redis是基于内存的数据库#xff0c;读取速度比数据库要快很多。

更新…

背景为了提高查询效率一般会用redis作为缓存。

客户端查询数据时如果能直接命中缓存就不用再去查数据库从而减轻数据库的压力而且redis是基于内存的数据库读取速度比数据库要快很多。

更新数据库更新缓存

由于引入了缓存那么在数据更新时不仅要更新数据库而且要更新缓存这两个更新操作存在前后的问题

先更新数据库再更新缓存

请求A先将数据库更新为1然后因为网络原因缓存更新延迟了在这之间请求B将数据库更新为2并且把缓存更新为2了之后缓存更新为1才更新成功那么此时数据库中数据是2缓存中数据为1出现了数据不一致现象。

先更新缓存再更新数据库

所以无论是「先更新数据库再更新缓存」还是「先更新缓存再更新数据库」这两个方案都存在并发问题当两个请求并发更新同一条数据的时候可能会出现缓存和数据库中的数据不一致的现象。

更新数据库删除缓存

在更新数据时不更新缓存而是删除缓存中的数据。

然后到读取数据时发现缓存中没了数据之后再从数据库中读取数据更新到缓存中。

这个策略叫

Cache

如果读取的数据命中了缓存则直接返回数据如果读取的数据没有命中缓存则从数据库中读取数据然后将数据写入到缓存并且返回给用户。

先删除缓存再更新数据库

要读取这个用户的年龄它查询缓存发现未命中后会从数据库中读取到年龄为

20并且写入到缓存中然后请求

redis.delKey(X)加了个睡眠时间主要是为了确保请求

能够在这这一段时间完成「从数据库读取数据再把缺失的缓存写入缓存」的操作然后请求

「从数据库读取数据

从上面的理论上分析先更新数据库再删除缓存也是会出现数据不一致性的问题但是在实际中这个问题出现的概率并不高。

因为缓存的写入通常要远远快于数据库的写入所以在实际中很难出现请求

而一旦请求

删除缓存之前更新了缓存那么接下来的请求就会因为缓存不命中而从数据库中重新读取数据所以不会出现这种不一致的情况。

为了确保万无一失还可以给缓存数据加上了「过期时间」就算在这期间存在缓存数据不一致有过期时间来兜底这样也能达到最终一致。

「先更新数据库

再删除缓存」其实是两个操作前面的所有分析都是建立在这两个操作都能同时执行成功但是删除缓存第二个操作的时候失败了导致缓存中的数据是旧值。

怎么解决

我们可以引入消息队列将第二个操作删除缓存要操作的数据加入到消息队列由消费者来操作数据。

如果应用删除缓存失败可以从消息队列中重新读取数据然后再次删除缓存这个就是重试机制。

当然如果重试超过的一定次数还是没有成功我们就需要向业务层发送报错信息了。

如果删除缓存成功就要把数据从消息队列中移除避免重复操作否则就继续重试。

删除一个数据相比更新一个数据更加轻量级出问题的概率更小。

在实际业务中缓存的数据可能不是直接来自数据库表也许来自多张底层数据表的聚合。

比如商品详情信息在底层可能会关联商品表、价格表、库存表等如果更新了一个价格字段那么就要更新整个数据库还要关联的去查询和汇总各个周边业务系统的数据这个操作会非常耗时。

从另外一个角度不是所有的缓存数据都是频繁访问的更新后的缓存可能会长时间不被访问所以说从计算资源和整体性能的考虑更新的时候删除缓存等到下次查询命中再填充缓存是一个更好的方案。

系统设计中有一个思想叫

Loading适用于那些加载代价大的操作删除缓存而不是更新缓存就是懒加载思想的一个应用。