谈谈 缓存和数据库一致性的问题

通常来说,在我们的系统中会把数据永久保存在DB中,并且冗余一份数据在缓存中。读请求优先从缓存读取数据,没有再从DB读取,如下图:

这样做的好处是可以减小DB的压力,提高请求的响应速度。

但这种架构在提升系统读请求处理能力的同时,给系统写请求的处理带来了不少的麻烦。因为数据在DB跟缓存中各自保存了一份,如何保证它们之间的数据一致就是需要注意的问题了。

当处理写请求时有两种方式:

一、先写缓存再写DB

  1. 如果第一步写缓存失败,直接返回,无影响。
  2. 如果缓存写成功,DB写失败,此时如果不清除缓存中已写入的数据,则会造成数据不一致(缓存中是新值,DB中是旧值)。
    如果增加清除缓存的逻辑,那么清除操作又失败了该如何处理?

二、先写DB再写缓存

  1. 如果DB写入失败,直接返回,无影响。
  2. 如果DB写入成功,缓存写入失败则会造成数据不一致(即DB中是新值,缓存中是旧值)。
    如果重试写入缓存,那重试也失败该如何处理?

三、问题分析

问题本质上就是一个分布式数据一致性问题,在不要求强一致性的场景下,我们只要开辟一个异步任务去保证最终一致性即可。

就上面所说的场景来说,发生失败时,我们可以开启一个异步线程去做数据回填操作,反复重试直到成功。如果采用异步线程回填数据的方式做最终一致性,那么这个容错性是内存级别的,也就是说如果此时重启服务(线程消失),那么这个重试任务就丢失了,导致数据不一致。

其实宏观上来说,缓存数据设置过期时间就是一种数据最终一致性的方案。这种方案下,我们可以对存入缓存的数据设置过期时间,所有的写操作以DB为准,对缓存操作只是尽最大努力即可。也就是说如果DB写成功,缓存更新失败,那么只要到达过期时间,则后面的读请求自然会从DB中读取新值然后回填缓存,完成数据的最终一致性。

原文地址:https://www.cnblogs.com/chengege/p/11073912.html

时间: 2024-10-10 18:45:18

谈谈 缓存和数据库一致性的问题的相关文章

缓存与数据库一致性保证

本文主要讨论这么几个问题: (1)啥时候数据库和缓存中的数据会不一致 (2)不一致优化思路 (3)如何保证数据库与缓存的一致性 一.需求缘起 上一篇<缓存架构设计细节二三事>引起了广泛的讨论,其中有一个结论:当数据发生变化时,"先淘汰缓存,再修改数据库"这个点是大家讨论的最多的. 上篇文章得出这个结论的依据是,由于操作缓存与操作数据库不是原子的,非常有可能出现执行失败. 假设先写数据库,再淘汰缓存:第一步写数据库操作成功,第二步淘汰缓存失败,则会出现DB中是新数据,Cach

缓存与数据库一致性保证(转)

本文主要讨论这么几个问题: (1)啥时候数据库和缓存中的数据会不一致 (2)不一致优化思路 (3)如何保证数据库与缓存的一致性 一.需求缘起 上一篇<缓存架构设计细节二三事>(点击查看)引起了广泛的讨论,其中有一个结论:当数据发生变化时,"先淘汰缓存,再修改数据库"这个点是大家讨论的最多的. 上篇文章得出这个结论的依据是,由于操作缓存与操作数据库不是原子的,非常有可能出现执行失败. 假设先写数据库,再淘汰缓存:第一步写数据库操作成功,第二步淘汰缓存失败,则会出现DB中是新数

【58沈剑架构系列】缓存与数据库一致性保证

本文主要讨论这么几个问题: (1)啥时候数据库和缓存中的数据会不一致 (2)不一致优化思路 (3)如何保证数据库与缓存的一致性 一.需求缘起 上一篇<缓存架构设计细节二三事>(点击查看)引起了广泛的讨论,其中有一个结论:当数据发生变化时,“先淘汰缓存,再修改数据库”这个点是大家讨论的最多的. 上篇文章得出这个结论的依据是,由于操作缓存与操作数据库不是原子的,非常有可能出现执行失败. 假设先写数据库,再淘汰缓存:第一步写数据库操作成功,第二步淘汰缓存失败,则会出现DB中是新数据,Cache中是旧

Redis缓存和数据库一致性问题

工作中,经常会遇到缓存和数据库数据一致性问题.从理论上设置过期时间,是保证最终一致性的解决方案.这种方案下,我们可以对存入缓存的数据设置过期时间,所有的写操作以数据库为准,对缓存操作只是尽最大努力即可.也就是说如果数据库写成功,缓存更新失败,那么只要到达过期时间,则后面的读请求自然会从数据库中读取新值然后回填缓存.因此,接下来讨论的思路不依赖于给缓存设置过期时间这个方案. 在这里,我们讨论三种更新策略: 1) 先更新数据库,再更新缓存 2) 先删除缓存,再更新数据库 3) 先更新数据库,再删除缓

redis缓存与数据库一致性问题

一般来说,如果允许缓存可以稍微的跟数据库偶尔有不一致的情况,也就是说如果你的系统不是严格要求 “缓存+数据库” 必须保持一致性的话,最好不要做这个方案,即:读请求和写请求串行化,串到一个内存队列里去. 串行化可以保证一定不会出现不一致的情况,但是它也会导致系统的吞吐量大幅度降低,用比正常情况下多几倍的机器去支撑线上的一个请求. Cache Aside Pattern 最经典的缓存+数据库读写的模式,就是 Cache Aside Pattern. 读的时候,先读缓存,缓存没有的话,就读数据库,然后

分布式缓存数据库一致性问题

缓存和数据库一致性问题,有很多解决方案,没有最完美的方案,只有适合自身业务的尽可能完美的方案. 缓存由于其高并发和高性能的特征,已经在项目中被广泛应用. 查询时一般先查询缓存,如果缓存命中的话,那么直接将数据返回. 如果缓存中没有数据(如失效,或者根本没设置数据),那么,应用程序先从数据库中查询数据,如果不为空,则将数据放在缓存中. 那么更新时,怎么处理缓存和数据库呢?先更新数据库后更新缓存?先更新数据库后更新缓存?或者先淘汰缓存后更新数据库? 为什么没有先更新缓存后更新数据库? 1):如果更新

怎么保证缓存和数据库数据的一致性?

参考链接:Redis缓存和数据库一致性问题 缓存与数据库一致性之一:缓存更新设计 原文地址:https://www.cnblogs.com/jxxblogs/p/12243035.html

缓存与数据库的一致性思考

时隔两年,重新启动这个博客.熟悉又有点陌生,这两年我的技术方向有了很大改变,但由于一直在使用为知笔记,因此这些改变没有提现在本博客上.之所以重启这个博客,主要是因为博客是一个开放的东西,可以带来一些交流,而笔记则是个人的东西,缺少思维碰撞.闲话少叙,这就开始. 问题:怎么保持缓存与数据库一致? 要解答这个问题,我们首先来看不一致的几种情况.我将不一致分为三种情况: 1. 数据库有数据,缓存没有数据: 2. 数据库有数据,缓存也有数据,数据不相等: 3. 数据库没有数据,缓存有数据. 在讨论这三种

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

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