缓存一致性解决方案

原创 已于 2022-12-12 23:25:55 修改 · 924 阅读 · 2 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#redis #缓存 #分布式

于 2022-12-12 23:06:53 首次发布

文章目录

常见的缓存一致性解决方案

这里的缓存一致性其实就是缓存中的数据和数据库中的数据如何保持一致.
   这个问题根据具体的业务场景和需要解决起来略有差异,但是总体看以分为两类,双写模式和失效模式,那他们是怎样工作的呢?有什么缺点以及怎样进行改进呢? 这里总结说明一下.

双写模式

总的流程就是先写数据库,数据库写成功了,去更新缓存.

在这里插入图片描述
在大并发下可能会产生的问题:
   有两个更新请求, 请求1先去写数据库,写完数据库再写缓存的时候因为卡段等某些原因,导致请求2优先完成了另一个写数据库,写缓存的操作,这时候请求1再去写缓存,缓存里的数据就和数据库中的数据不一致了.
在这里插入图片描述

失效模式

总体流程:
   更新的时候先更新数据库,然后直接删除缓存,等后面有查询操作的时候,会自动将最新数据放到缓存中
注意:
    在将数据库里的数据查出来放入到缓存中时,首先要判断缓存中是否有,如果有的话,说明在这个期间有别的请求对缓存做了操作,此时就不应该再去处理了.否则很容易造成不一致问题.
在这里插入图片描述
并发下存在的问题:
   假如某一条数据因为过期或者被删除了,在缓存中并没有.
   此时有两个请求,请求2先去读缓存,缓存中没有,然后去数据库中查询出来,在准备去更新缓存的时候,因为gc或者cpu切换等原因,请求1先完成了更新数据库删除缓存的操作,这个时候请求2将查询出来的数据放入缓存.缓存里面的数据就变成了一个旧数据.

在这里插入图片描述

两种模式的总结

保持数据一致性的解决方案:
上述两种模式在大并发下都会产生数据不一致情况,其实解决方案也趋于一致.主要就是两种

  1. 加锁,上述问题产生的根本原因是写数据库,更新缓存的操作不是一个整体,不是原子性的,那我们可以通过加锁,将其变成一个整体.
    那加锁又有不同的方式,如果是读多写少的情况,可以加分布式读写锁,来规避读读之间的互斥,提高并发量,如果是写多读少的情况,说实话本身就没有必要放到缓存中了.
  2. 加过期时间,如果我们的业务允许可以有短暂性的不一致的话,这种场景都不用再纠结了.直接加一个短暂的过期时间就好了, 比如说一天,当数据过期后,又会从数据库加载最新的数据.

主要区别:

   这两种模式最主要的区别在于一个是更新缓存,一个是删除缓存,那要怎样选择呢?

   最主要的区分点在于这个数据会不会被频繁的访问到?

   一般来讲,访问数据也遵循28法则,即20%的数据占据了80%的访问量,那如果这个数据需要被非常频繁的访问到,并且不涉及到什么复杂计算,那应该更新缓存, 否则则应该采用更简单的删除缓存.

上述模式的改进

   上面两种模式及解决方案可能还是会存在一些小问题,比如说加锁肯定会影响性能,那还有一种更好的方式,只是复杂度会高一些.
   上述产生并发问题的最关键一点就是最新的数据没有更新到redis中,那我们可以使用阿里开源的canal,它其实是将自己伪装成mysql的从服务器,通过监听变更日志(binlog)的方式,将数据库的更新按序同步到redis中.
   这种方式的另一个好处就是在编码期间只需要更新数据库,都不需要去更新缓存,
在这里插入图片描述

今天的分享就到这里了,有问题可以在评论区留言,均会及时回复呀.
我是bling,未来不会太差,只要我们不要太懒就行, 咱们下期见.
在这里插入图片描述

数据缓存一致性方案
seanme的专栏
02-27 544
数据缓存一致性方案 内容要点 背景介绍 缓存系统目标 缓存写一致性方案分析 缓存读一致性方案分析 总结 背景介绍 背景介绍：1.使用Redis缓存数据，MySQL为DB持久储存层。在DB中有一些关键性表的读请求量大，而更新不是很频繁(但是更新的内容都是关键性的) 2.MySQL底层暂时没有能力修改，所以不讨论在MSQYL层监听数据改动时触发缓存的同步更新;另外一个原因是，公司还有其它系统使用E...
浅析缓存一致性的解析方案
weixin_29634843的博客
07-17 642
通过6种分布式一致性方案的解读，了解其中的优劣
缓存一致性问题与解决方案
09-06
在高并发下，由于时许的问题导致缓存中的数据与数据库中的数据不一致那么我们应该如何解决呢？ 1、 锁能解决这种问题吗，不行为什么呢。 锁解决的是竞争问题。 2、单纯的消息中间件能解决吗，中间件可以保证时序，但是不能判断是否存在该消息 3、数据库的事务是否能解决呢？ 事务解决的也是数据一致性的问题（业务层与数据库层面的一致性），看来这个也跟数据库的事务没有关系。 4、我们可以采用队列来实现，read的时候判断当前队列中是否存在删除操作，如果存在直接等待，如果没有直接执行，这个看样子是可以解决问题，当前这样会出现大量的线程阻塞、有可能还是出现timeout。
关于缓存数据一致性的解决方案
一起交流，一起进步
01-31 2342
解决缓存和数据库数据不一致的问题
缓存一致性问题解决方案
热门推荐
bocai_xiaodaidai的博客
04-07 1万+
四种方案： 先写缓存，再写数据库（差） 先写数据库，再写缓存（一般） 先删缓存，再写数据库（能接受） 先写数据库，再删缓存（比较优秀）
精选资源
springboot缓存一致性解决
09-03
本文将深入探讨Spring Boot中如何处理和解决缓存一致性问题。 首先，我们需要理解缓存的一致性模型。常见的有三种：强一致性、最终一致性和读已写一致性（Read-Your-Writes Consistency）。在分布式系统中，强一致...
缓存一致性解决方案之svg图
05-30
双写与更新+删除的区别在于更新缓存的更新方。 双写是更新操作主动更新缓存。 更新+删除是读取放更新缓存。 得出所有非原子性的问题都可以通过加锁来解决
万字长文！说清缓存一致性解决方案，从入门到精通的架构师指南
最新发布
ly853602的博客
03-30 1155
万字长文！说清缓存一致性解决方案
数据库缓存一致性解决方案
长舒的博客
04-06 1978
最近在面试的过程中，有遇到面试官问我这个问题，觉得还是有必要看一下，那就是缓存与数据库的一致性问题 在自己开发单体应用的时候，往往是一个后端服务加一个数据库服务就ok了，但是，在实际开发中，还需要根据真实的业务需求，考虑上缓存，这就带来了上面的问题 我们通常会使用Redis作为缓存中间件，因为他是基于内存的，速度很快，那如果现在我们不仅要把数据放在数据库中，还要放入缓存中，这种具体过程要怎么存呢 最简单的方法是全量数据刷到缓存中 数据库的数据，全量刷入缓存(不设置过期时间) 写请求只更新数据库，不更新缓存
缓存数据一致性-解决方案
m0_56466015的博客
03-10 6895
缓存数据一致性-解决方案
对于缓存数据一致性的解决方案
刘刘刘刘刘牛皮的博客
02-23 389
1：操作缓存时，先写数据库，再写缓存。 2：对于缓存的并发性问题 由于卡顿等原因，导致了缓存2走到了缓存1的前面，这样数据库的数据得到的和缓存中查询的不一致 脏数据的问题，在数据稳定之后，缓存过期后，重新查询数据库便可以达到正常的数据，达到数据的一致性。 失效模式： 先进行写数据库，再删除缓存 对于缓存双写模式还是失效模式，都会导致缓存不一致的问题 1：缓存数据加上过期时间，隔一段时间触发进行主动更新即可。 2：缓存数据+过期时间可以解决大部分业务对于缓存的要求。 ..
缓存一致性解决
Jak的博客
03-21 1203
一、缓存一致性问题 我们现在读所有的数据，都是先来看缓存，缓存中没有我们就来读数据库。假如我们第一次读取，缓存中没有，然后，来查数据库，是一条新值。 现在来考虑一个问题，如果数据库修改了一个数据，而这个数据缓存中也有，我们再来从缓存中拿数据，就是一条旧数据。 所以，就牵扯到另外一个问题，缓存数据一致性问题，缓存里面的数据如何和数据库保持一致。 解决缓存一致性问题，比较常用的两种模式有 1.双写模式 2.失效模式 这两种方式再大并发下，都会产生一些漏洞 二、双写模式 首先，我们使用双写模
数据库与缓存数据一致性解决方案
Java知识图谱的博客
03-15 1119
一、序言 在分布式并发系统中，数据库与缓存数据一致性是一项富有挑战性的技术难点。本文将讨论数据库与缓存数据一致性问题，并提供通用的解决方案。 假设有完善的工业级分布式事务解决方案，那么数据库与缓存数据一致性便迎刃而解，实际上，目前分布式事务不成熟。 二、不同的声音 在数据库与缓存数据一致解决方式中，有各种声音。 先操作数据库后缓存还是先缓存后数据库 缓存是更新还是删除 1、操作的先后顺序 在并发系统中，数据库与缓存双写场景下，为了追求更大的并发量，操作数据库与缓存显而易见不会同步进行。前者操作成功后者以
【解决方案】缓存一致性解决方案
慢行的蜗牛
12-03 345
缓存一致性解决方案
缓存一致性解决方法
hanhan的博客
10-08 1211
对于缓存 + 数据库读写，有个经典的Cache Aside Pattern： 读取：先读取缓存，缓存里没有，读取数据库，然后返回响应，顺便保存缓存： 更新：先更新数据库，然后删除缓存 为什么是删除缓存而不是更新缓存？ 并发情况下更新缓存可能会带来更多问题，直接删除缓存更加稳妥 缓存更新消耗更多资源，直接删除，用时再从数据库读取，写进缓存，更省性能 一致性问题 假设更新数据库成功，接下来还没来得及删除缓存，或者删除缓存失败，此时其他线程进来读的就是脏数据。既然删除缓存失败会导致脏数据，那么就得想办法能让它
db缓存一致性解决方案
03-29
<think>好的，用户正在寻找关于数据库缓存一致性的解决方案。我需要先理解数据库缓存一致性是什么，然后结合现有的引用资料来给出解决方案。 首先，数据库缓存一致性指的是在使用缓存（如Redis、Memcached）时，如何确保缓存中的数据与底层数据库的数据保持一致。当数据在数据库中被修改后，如果缓存没有相应更新，就会出现不一致的情况，导致应用程序读取到过期的数据。 根据用户提供的引用资料，引用[4]提到要确保数据库在系统故障和事务失败时保持一致性，并发控制管理器需要控制并发事务的交互。这可能涉及到事务管理和锁机制，保证在更新数据库和缓存时的原子性。比如，使用事务来同时更新数据库和缓存，或者采用两阶段提交协议。 引用[1]指出，涉及关键业务数据如金钱、密钥等不应放在缓存中，这可能影响到缓存策略的设计，比如对于关键数据，可能需要更严格的一致性保证，或者避免缓存这类数据。但这和缓存一致性解决方案也有关系，比如哪些数据需要缓存，如何保证它们的同步。 引用[3]提到内存数据库缓存的高性能优势，但高性能的同时需要一致性，可能涉及到缓存失效策略，如写穿透（Write-Through）或延迟写入（Write-Behind）。例如，写穿透会在更新数据库的同时更新缓存，确保数据一致性，但可能增加延迟。 引用[2]讨论了MySQL在线备份的并发处理、缓冲池效率等，虽然没有直接讲缓存一致性，但处理并发和缓冲池效率的方法可能对缓存策略有参考价值，比如如何在高并发下保证缓存和数据库的数据同步。 接下来需要考虑常见的解决方案，比如缓存失效策略、双写策略、使用消息队列异步更新、分布式锁等。此外，还有基于日志的解决方案，如MySQL的binlog监听，当数据库变更时，通过解析binlog来更新缓存，这样可以保证缓存的及时更新。 另外，需要考虑在分布式系统中，缓存一致性可能面临的挑战，比如网络延迟、分区容忍性等，这时候可能需要权衡一致性和可用性，采用最终一致性模型。例如，设置缓存的过期时间，确保即使出现不一致，也能在一定时间后自动刷新。 还要注意在更新数据库和缓存时的顺序问题，比如先更新数据库再删除缓存（Cache-Aside模式），或者先删除缓存再更新数据库，不同的顺序可能带来不同的并发问题，需要根据场景选择合适的方法。 最后，结合用户提供的引用，需要将解决方案与这些资料关联起来，比如事务控制、并发管理、缓存策略的选择等，确保回答有依据，并且引用正确的来源。</think>### 数据库缓存一致性解决方案 数据库缓存一致性是分布式系统中常见的核心问题，主要解决缓存与底层数据库的数据同步和一致性保障。以下是常见的解决方案及其技术原理： --- #### 1. **缓存失效策略（Cache Invalidation）** - **原理**：通过主动或被动方式使缓存数据失效，强制下次读取时从数据库加载最新数据。 - **方法**： - **写穿透（Write-Through）**：更新数据库时同步更新缓存。例如，若更新数据库字段$A$，则同时更新缓存中的$A$[^3]。 - **延迟写入（Write-Behind）**：先更新缓存，再异步批量更新数据库。适用于高吞吐场景，但需容忍短暂不一致。 - **缓存删除（Cache-Aside）**：更新数据库后直接删除缓存，下次查询时重新加载。例如： ```sql UPDATE users SET name = 'Alice' WHERE id = 1; -- 更新数据库 DELETE user:1 FROM cache; -- 删除缓存 ``` --- #### 2. **基于事务的原子操作** - **原理**：利用数据库事务的原子性，确保缓存与数据库操作的原子提交。 - **方法**： - **两阶段提交（2PC）**：将缓存更新和数据库修改绑定为事务，任一失败则回滚。例如： ```python with db.transaction(): db.execute("UPDATE accounts SET balance = 100 WHERE id = 1") cache.set("account:1", 100) # 事务提交时同步执行 ``` - **缺点**：性能开销较大，适用于强一致性要求的场景[^4]。 --- #### 3. **基于日志的增量同步** - **原理**：通过数据库日志（如MySQL的binlog）捕获数据变更，触发缓存更新。 - **流程**： 1. 监听数据库的变更日志。 2. 解析日志中的操作（如INSERT/UPDATE/DELETE）。 3. 根据操作更新或删除缓存。 - **优势**：解耦数据库与缓存，支持最终一致性[^2]。 --- #### 4. **版本控制与乐观锁** - **原理**：为数据添加版本号，确保仅当缓存版本与数据库一致时才更新。 - **实现**： - 数据库表中增加`version`字段，例如： $$ \text{表结构: } (id, data, version) $$ - 更新时检查版本号： ```sql UPDATE table SET data = 'new_data', version = version + 1 WHERE id = 1 AND version = 2; ``` - 若更新成功，则同步更新缓存中的数据和版本号。 --- #### 5. **分布式锁控制并发** - **原理**：在并发写操作时，通过锁机制避免缓存与数据库的竞争。 - **示例**： ```python lock = acquire_lock("user:1") # 获取分布式锁（如Redis RedLock） try: data = db.query("SELECT * FROM users WHERE id = 1") cache.set("user:1", data) finally: release_lock(lock) ``` - **适用场景**：高并发写操作（如秒杀系统）。 --- #### 6. **最终一致性模型** - **原理**：允许短暂的不一致，通过异步机制最终达到一致状态。 - **方法**： - 设置缓存过期时间（TTL），例如：`cache.set(key, value, ttl=60)`。 - 结合消息队列（如Kafka）异步处理缓存更新。 --- ### 关键挑战与权衡 - **性能 vs 一致性**：强一致性（如2PC）牺牲性能，最终一致性（如TTL）牺牲实时性。 - **关键数据限制**：涉及财务、密钥等敏感数据时，需避免缓存或使用强一致性方案[^1]。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

程序员bling

义父,感谢支持

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值