实现缓存最终一致性的两种方案

Posted qfjavabd

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了实现缓存最终一致性的两种方案相关的知识,希望对你有一定的参考价值。

  一、重客户端

  写入缓存:

  

技术分享图片

 

  应用同时更新数据库和缓存

  如果数据库更新成功,则开始更新缓存,否则如果数据库更新失败,则整个更新过程失败。

  判断更新缓存是否成功,如果成功则返回

  如果缓存没有更新成功,则将数据发到MQ中

  应用监控MQ通道,收到消息后继续更新Redis。

  问题点:如果更新Redis失败,同时在将数据发到MQ之前的时间,应用重启了,这时候MQ就没有需要更新的数据,如果Redis对所有数据没有设置过期时间,同时在读多写少的场景下,只能通过人工介入来更新缓存。

  读缓存:

  如何来解决这个问题?那么在写入Redis数据的时候,在数据中增加一个时间戳插入到Redis中。在从Redis中读取数据的时候,首先要判断一下当前时间有没有过期,如果没有则从缓存中读取,如果过期了则从数据库中读取最新数据覆盖当前Redis数据并更新时间戳。具体过程如下图所示:

  

技术分享图片

  二、客户端数据库与缓存解耦

  上述方案对于应用的研发人员来讲比较重,需要研发人员同时考虑数据库和Redis是否成功来做不同方案,如何让研发人员只关注数据库层面,而不用关心缓存层呢?请看下图:

  

技术分享图片

 

  应用直接写数据到数据库中。

  数据库更新binlog日志。

  利用Canal中间件读取binlog日志。

  Canal借助于限流组件按频率将数据发到MQ中。

  应用监控MQ通道,将MQ的数据更新到Redis缓存中。

  可以看到这种方案对研发人员来说比较轻量,不用关心缓存层面,而且这个方案虽然比较重,但是却容易形成统一的解决方案。

?

 

以上是关于实现缓存最终一致性的两种方案的主要内容,如果未能解决你的问题,请参考以下文章

浅谈缓存最终一致性的解决方案

4 种数据库缓存最终一致性的优缺点对比?最终选择方案四!

数据库缓存最终一致性的四种方案

浅谈缓存最终一致性的解决方案

使数据缓存最终一致的方法

CPU中的MESI缓存最终一致性---CPU为什么需要缓存