失眠网,内容丰富有趣,生活中的好帮手!
失眠网 > Redis 缓存实战——缓存 数据库一致性问题分析与解决方案

Redis 缓存实战——缓存 数据库一致性问题分析与解决方案

时间:2020-10-31 09:49:18

相关推荐

Redis 缓存实战——缓存 数据库一致性问题分析与解决方案

引言

缓存与数据库一致性的问题自从出现了缓存概念后就一直被提及,它是一个缓存方案的先天缺陷,只要存在缓存,就势必会讨论缓存与数据库一致性的问题。

一致性问题还广泛存在于各种分布式存储场景中,如主从一致性等等。

本篇博客讨论和整理了缓存、数据库一致性问题的一些思路,在实际的缓存业务场景中,可以对技术实现的起到一定指导作用。

一、为什么会出现一致性问题

缓存作为应用程序与数据库之间的数据存储池,主要作用就是热数据备份的作用,它的主要目的就是提高热数据的查询效率。因此,在读取缓存方面,普遍的做法是没有疑问的,基本都是按照如下流程执行:

在写数据方面,却存在很多问题,其中一点就是——如何保证数据库的数据与缓存的数据保持一致。

二、强一致性、弱一致性、最终一致性

在一致性问题上,分为事务一致性和数据一致性,而缓存、数据库一致性很明显就是数据一致性。

其实只有两类数据一致性,强一致性和弱一致性。除此之外,所有其他的一致性都是弱一致性的特殊情况。

2.1 强一致性与弱一致性

强一致性又叫线性一致性,顾名思义,就是在多个数据源之间以同步的方式复制数据。

弱一致性,即复制是异步的。在时间中,我们通常使一个从库是同步的,而其他的则是异步的。如果这个的从库出现问题,则使另一个异步从库同步。

这样可以确保永远有两个节点拥有完整数据。主库和同步从库,这种配置成为半同步。

2.2 最终一致性

最终一致性表示不一致的状态可能会出现,但这也只是暂时的,不同的数据源会在未来某个时点保持同步。

而为缓存设置过期时间可以有效的保证最终一致性。

三、缓存更新策略

解决缓存、数据库一致性问题的方法,无非就是在更新数据库时尽可能的减少不一致的情况出现。

但只要存在缓存,就无法保证数据的强一致性,选择不同的缓存更新策略,也只是在弱一致性的前提下,尽可能保证数据的同步,或达到最终一致性。

从理论上来讲,共有四种更新策略:

先更新数据库,再更新缓存先更新数据库,再删除缓存先更新缓存,再更新数据库先删除缓存,再更新数据库

一般情况下,为了保证数据的安全,都会第一时间将数据更新到数据库中,所以先操作缓存的方式往往不被采纳。

对于先更新数据库的情况,到底是选择更新缓存还是删除缓存呢?

3.1 先更库,更缓存

结论是,这种方案普遍不被采纳。

第一点原因,线程安全性,如果同时有请求A 和 请求 B 都要更新数据,那么会出现如下情况:

线程 A 更新了数据库线程 B 更新了数据库线程 B 更新了缓存线程 A 更新了缓存

本来按照先后顺序,A的更新操作在 B 之前,最终也应该是缓存中存放 B 更新的数据,但是由于一些特殊原因,导致后更新数据的 B 先于 A 更新了缓存,就导致了脏数据。

第二点原因,如果是一个写多读少的场景,采用这种方案由于每次更新数据都要去更新缓存,但从缓存中查询的次数却寥寥无几,不仅没有起到提高查询性能的目的,反而还极大的浪费性能。

3.2 先更库,删缓存

该方案同样会导致数据不一致。例如,同时有一个请求 A 查询数据,另一个请求 B 更新数据,会产生如下情形:

缓存刚好失效被清除请求 A 查询数据库,得到一个旧数据请求 B 将新数据写入数据库请求 B 删除缓存请求 A 将查询到的旧数据写入缓存

上面的情况是有可能发生的,它产生的原因是由于A 将取得的旧数据(在 B 更新完数据并执行了删除缓存操作之后)又放入到了缓存,即缓存中的数据是 A 之前取得的旧数据。

但是这种情况发生的概率很低,这是因为写库操作的速度要远低于读库的速度。正因为如此,请求 B 在将新数据写入到数据库后才会大概率在请求 A 将旧数据写入缓存之后执行删除缓存操作。

即大概率发生的情形应该是:

缓存刚好失效被清除请求 A 查询数据库,得到一个旧数据请求 B 将新数据写入数据库请求 A 将查询到的旧数据写入缓存请求 B 删除缓存

由于写库操作要更加缓慢,因此,大概率会在最后,在其他读操作的写入缓存执行后再将缓存删除,从而保证数据的一致性。

另外,更新缓存实际上可以看做是先删除再添加的两步操作,那么对于删缓存的操作,无非就是将添加缓存安排到了下次查询的时候,这也在查询情况较少的时候避免了频繁更新缓存的尴尬。

因此,先更库,再删除缓存是一种较为可行的解决一致性问题的方案。

四、先更库再删缓存的其他问题

如果缓存删除失败了怎么办?

的确,如果更新了数据库之后,由于特殊原因,导致缓存删除失败,缓存中依然保留了旧数据,那么同样存在不一致的问题。

这个时候,我们需要为业务系统增加全局的缓存失效时间,这样可以保证不一致也只是暂时的,即达到最终一致性的效果。

或者使用下面的解决方案,使用消息队列保存数据库更新后失败的缓存删除操作,再某一时点进行重试,其中 binlog 订阅程序可以选择现成的MySQL binlog订阅中间件 “canal”。

鸣谢:

《缓存与数据库的一致性问题解析》

如果觉得《Redis 缓存实战——缓存 数据库一致性问题分析与解决方案》对你有帮助,请点赞、收藏,并留下你的观点哦!

本内容不代表本网观点和政治立场,如有侵犯你的权益请联系我们处理。
网友评论
网友评论仅供其表达个人看法,并不表明网站立场。