K:缓存数据库双写数据一致性方案

对于缓存和数据库双写,其存在着数据一致性的问题。对于数据一致性要求较高的业务场景,我们通常会选择使用分布式事务(2pc、paxos等)来保证缓存与数据库之间的数据强一致性,但分布式事务的复杂性与对资源的占用问题,使得该处理方式会造成系统性能的降低。对于数据一致性要求没那么高的业务场景,选择分布式事务的处理方式就会显得不是那么必要。为此,在一般情况下,对于数据一致性要求没那么高的业务场景,会选择使用cache-aside-pattern方案来保证缓存与数据库之间,数据的最终一致性,以下文章便是介绍并整理该cache-aside-pattern方案的内容。

对于缓存中的数据,我们提出三个目标

  1. 尽可能不将数据库中的旧数据存入缓存中
  2. 允许缓存中的数据与数据库中的数据存在一小段时间的不一致
  3. 缓存中的数据与数据库中的数据存在数据不一致的时间应尽量短

对于缓存与数据库的双写问题,无外乎“增删改查” 这四个过程,再考虑进并发的“读读,写写,读写”情况,所有可能的情况组合并不多。为此,我们可以采用穷举的方式对该方案进行说明。

查:

对于数据的查找,该方案的过程与cpu中查找数据的过程是一致的,其过程如下:

  1. 先查找缓存中的数据,当命中缓存的时候返回数据,查找结束。
  2. 当没有命中缓存时,查找数据库,对数据库中查找出的相关数据进行处理,之后将相关的数据存入缓存中,查找结束。

其示意图如下:

在考虑高并发查询的情况下,对于该处理过程,如下示意图所示。

当客户端1、客户端2、....、客户端n查询同一数据,且该数据不存在于缓存中时,所有的客户端请求都会去访问数据库,此时会出现缓存击穿的情况,对于缓存击穿的相关问题及解决方案,我们留到下一篇文章再进行讲解。

增:

对于新增数据的情况,我们将数据直接添加进数据库中,且不将新增的数据加载入缓存中,其过程如下示意图所示:

在考虑高并发之时,其过程如下示意图所示:

通过示意图,我们了解到,当采用该种方式新增数据时,在并发情况下,并未出现与我们的目标相违背的问题。

删:

当需要对数据进行删除时,我们有两种删除的方案可供选择。

第一种: 先删除缓存中的数据,再删除数据库中的数据

第二种: 先删除数据库中的数据,再删除缓存中的数据

我们对这两种方案分别进行分析:

先删缓存:

对于先删除缓存中的数据,后删除数据库中的数据这种方案,其示意图如下:

考虑进高并发的情况,当存在读请求和删除数据的请求并发时,由于网络的不可靠和延时问题,其可能出现如下示意图所示的情况:

通过示意图我们了解到,存在着缓存中缓存进已删除的旧数据的情况,这违背了我们提出的第一个目标。

那么,先删除数据库中的数据的情况呢?会出现这样的问题吗?我们接着分析。

先删数据库:

对于先删除数据库中的数据,后删除缓存中的数据这种方案,其示意图如下。

同样考虑进高并发的情况,当存在读请求和删除数据的请求并发时,其发生的情况如下示意图所示:

此时,并未出现与我们的目标相违背的问题。综上,我们在删除数据时,应选择先删除数据库中的数据再删除缓存中的数据的这一方案。

但是该方案仍存在着问题。我们再往下思考,当删除了缓存中的相关数据,此时来了大量读取该数据的请求。这时,就会导致“缓存穿透”问题的出现(该问题同样在下一篇文章中进行讲解)。

改:

当需要对数据进行变更的时候,我们有三种方案可供选择。

第一种: 先更新数据库,后更新缓存

第二种: 先删除缓存,后更新数据库

第三种: 先更新数据库,后删除缓存

我们对这三种方案逐一进行分析。

先更新数据库,后更新缓存:

对于先更新数据库,后更新缓存这种方案,其示意图如下:

考虑高并发的情况,当存在两个更新操作的并发请求时,由于网络的延时问题,其可能会出现如下这种情况:

由上述示意图可知,当存在两个更新操作时,其有将数据库中的旧数据存入缓存中的情况,这违背了我们的第一个目标。那么,有没有办法解决呢?答案是有的,借助乐观锁的相关思想,我们可以给每个数据加上一个版本号,当数据要存入缓存时,比较一下数据的版本号即可。到目前为止,更新了数据库中的相关数据之后,再更新缓存中的数据这个方案看起来是可以的,但是这个方案存在着一个问题,就是需要去更新缓存中的数据,更新缓存中的数据这个操作会影响系统的性能。特别是在写多读少,且缓存的数据不是直接从数据库中存入,而是经过计算之后再进行缓存的业务场景中时,对系统性能造成的影响会更加明显。为此我们可以借助“懒加载”的思想,在更新数据之时,将缓存中的数据进行删除,等到需要用到的时候,才将数据加载进缓存中。下面我们将讨论在更新时删除缓存的两个可能的方案。

先删除缓存,后更新数据库:

对于先删除缓存,后更新数据库的方案,其示意图如下:

考虑高并发的情况,当存在读请求和更新请求并发的情况,由于存在网络延时,其可能出现如下示意图中的情况:

由示意图中的情况可知,在读写并发的情况下,其存在着将数据库中的旧数据存入缓存中的问题。这违背了我们的第一个目标。

先更新数据库,后删除缓存:

对于先更新数据库,后删除缓存的情况,其如下示意图所示:

考虑并发的情况,当存在读请求和更新请求并发,且此时缓存中的数据恰好失效时,再加上由于网络的延迟问题,则有可能会出现如下示意图所示的情况。

由示意图可知,当缓存中的数据恰好失效时,其是可能存在着缓存中存入数据库中的旧数据的可能性的。但是,发生这种情况的概率是比较低的,因为让该种情况出现的条件较为“苛刻”,需要恰好缓存中的数据失效,且要求“读操作”慢于“写操作”。但在通常情况下,“写操作”是慢于“读操作”的,因为写操作一般会涉及到数据库锁的相关操作。
综上,在对比了以上三种方案之后,对于数据更改的情况,我们采用先更新数据库,后删除缓存的方式。



原文地址:https://www.cnblogs.com/MyStringIsNotNull/p/12117229.html

时间: 2024-10-03 20:30:03

K:缓存数据库双写数据一致性方案的相关文章

高并发场景下缓存+数据库双写不一致问题分析与解决方案设计

Redis是企业级系统高并发.高可用架构中非常重要的一个环节.Redis主要解决了关系型数据库并发量低的问题,有助于缓解关系型数据库在高并发场景下的压力,提高系统的吞吐量(具体Redis是如何提高系统的性能.吞吐量,后面会专门讲). 而我们在Redis的实际使用过程中,难免会遇到缓存与数据库双写时数据不一致的问题,这也是我们必须要考虑的问题.如果还有同学不了解这个问题,可以搬小板凳来听听啦. 一.数据库+缓存双写不一致问题引入 要讲数据库+缓存双写不一致的问题,就需要先讲一下这个问题是怎么发生的

缓存数据库双写一致性问题

引言 在引入缓存系统的项目中,我们需要旧数据进行更新操作时,我们是先淘汰缓存,再更新数据库.还是先更新数据库,再淘汰缓存.亦或是更新数据库,再更新缓存呢?下面,将会讲讲小编对这三种方案的优缺点的一些想法. 目的 整理自己对这方面的知识: 分享自己的看法,和小伙伴们一起学习: 用初学者的角度来浅显的讲解这方面的内容. 缓存更新策略 先更新数据库,再更新缓存: 先更新数据库,再删除缓存: 先删除缓存,再更新数据库: 先更新数据库,再更新缓存 这套方案,小编认为大多数场景不合适.为什么呢?主要从以下几

保证缓存与数据库双写时的数据一致性

缓存与数据库双写时的数据一致性问题:只要用缓存,就可能会涉及到缓存与数据库双存储双写,你只要是双写,就一定会有数据一致性的问题,那么你如何解决一致性问题? 一般来说,就是如果你的系统不是严格要求缓存+数据库必须一致性的话,缓存可以稍微的跟数据库偶尔有不一致的情况,最好不要做这个方案,读请求和写请求串行化,串到一个内存队列里去,这样就可以保证一定不会出现不一致的情况. 串行化之后,就会导致系统的吞吐量会大幅度的降低,用比正常情况下多几倍的机器去支撑线上的一个请求. 原文地址:https://www

分布式之数据库和缓存双写一致性方案解析

引言 为什么写这篇文章? 首先,缓存由于其高并发和高性能的特性,已经在项目中被广泛使用.在读取缓存方面,大家没啥疑问,都是按照下图的流程来进行业务操作. 但是在更新缓存方面,对于更新完数据库,是更新缓存呢,还是删除缓存.又或者是先删除缓存,再更新数据库,其实大家存在很大的争议.目前没有一篇全面的博客,对这几种方案进行解析.于是博主战战兢兢,顶着被大家喷的风险,写了这篇文章. 正文 先做一个说明,从理论上来说,给缓存设置过期时间,是保证最终一致性的解决方案.这种方案下,我们可以对存入缓存的数据设置

布式之数据库和缓存双写一致性方案解析(转)

引言 为什么写这篇文章? 首先,缓存由于其高并发和高性能的特性,已经在项目中被广泛使用.在读取缓存方面,大家没啥疑问,都是按照下图的流程来进行业务操作.但是在更新缓存方面,对于更新完数据库,是更新缓存呢,还是删除缓存.又或者是先删除缓存,再更新数据库,其实大家存在很大的争议.目前没有一篇全面的博客,对这几种方案进行解析.于是博主战战兢兢,顶着被大家喷的风险,写了这篇文章. 文章结构 本文由以下三个部分组成1.讲解缓存更新策略2.对每种策略进行缺点分析3.针对缺点给出改进方案 正文 先做一个说明,

【转】分布式之数据库和缓存双写一致性方案解析

转自:https://www.cnblogs.com/rjzheng/p/9041659.html 引言 为什么写这篇文章? 首先,缓存由于其高并发和高性能的特性,已经在项目中被广泛使用.在读取缓存方面,大家没啥疑问,都是按照下图的流程来进行业务操作.但是在更新缓存方面,对于更新完数据库,是更新缓存呢,还是删除缓存.又或者是先删除缓存,再更新数据库,其实大家存在很大的争议.目前没有一篇全面的博客,对这几种方案进行解析.于是博主战战兢兢,顶着被大家喷的风险,写了这篇文章. 文章结构 本文由以下三个

Redis与Mysql双写一致性方案解析

一 前言 首先,缓存由于其高并发和高性能的特性,已经在项目中被广泛使用.在读取缓存方面,大家没啥疑问,都是按照下图的流程来进行业务操作 但是在更新缓存方面,对于更新完数据库,是更新缓存呢,还是删除缓存.又或者是先删除缓存,再更新数据库,其实大家存在很大的争议 本文由以下三个部分组成 1.讲解缓存更新策略 2.对每种策略进行缺点分析 3.针对缺点给出改进方案 二 一致性方案 先做一个说明,从理论上来说,给缓存设置过期时间,是保证最终一致性的解决方案.这种方案下,我们可以对存入缓存的数据设置过期时间

Java进阶面试必问:如何保证缓存与数据库的双写一致性?

面试题 如何保证缓存与数据库的双写一致性? 面试官心理分析 你只要用缓存,就可能会涉及到缓存与数据库双存储双写,你只要是双写,就一定会有数据一致性的问题,那么你如何解决一致性问题? 面试题剖析 一般来说,如果允许缓存可以稍微的跟数据库偶尔有不一致的情况,也就是说如果你的系统不是严格要求 "缓存+数据库" 必须保持一致性的话,最好不要做这个方案,即:读请求和写请求串行化,串到一个内存队列里去. 串行化可以保证一定不会出现不一致的情况,但是它也会导致系统的吞吐量大幅度降低,用比正常情况下多

经典好文--如何保证缓存和数据库的双写一致性

面试题如何保证缓存与数据库的双写一致性? 面试官心理分析你只要用缓存,就可能会涉及到缓存与数据库双存储双写,你只要是双写,就一定会有数据一致性的问题,那么你如何解决一致性问题? 面试题剖析一般来说,如果允许缓存可以稍微的跟数据库偶尔有不一致的情况,也就是说如果你的系统不是严格要求 “缓存+数据库” 必须保持一致性的话,最好不要做这个方案,即:读请求和写请求串行化,串到一个内存队列里去. 串行化可以保证一定不会出现不一致的情况,但是它也会导致系统的吞吐量大幅度降低,用比正常情况下多几倍的机器去支撑