缓存双写一致性

置顶 已于 2022-04-22 12:57:00 修改
阅读量1.7k 收藏 5
点赞数 1
分类专栏： java 框架 文章标签： java redis
于 2022-04-12 15:49:20 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/weixin_44981707/article/details/124125964
版权

缓存双写一致性

前言：

在开头有必要说明，如果对数据一致性要求比较高就不要存缓存，因为只要涉及到双写就一定存在一致性问题。

1. 缓存基本使用方式

  如果可以容忍数据不一致话，我们可以给缓存设置一个过期时间，所有写操作以数据库为基准，缓存过期后就会去数据库中取新值，保证了数据的最终一致性

在这里插入图片描述

  过期时间也就是我们能容忍数据最大不一致的时间。过期时间太短，数据不一致时间短，但是读数据库频繁；过期时间太长，数据不一致时间也就越长。

1.1 增大缓存过期时间，数据变更主动更新缓存

  增大缓存过期时间，能有效减少读DB频繁问题，但是会造成数据不一致时间过长，这时候我们得再数据变更后主动更新缓存，来减少不一致时间。

这里我们讨论三种更新策略：

  • 先更新数据库，再更新缓存
  • 先删除缓存，再更新数据库
  • 先更新数据库。再删除缓存

2. 先更新数据库，再更新缓存

  假设我们采用【先更新数据库，再更新缓存】策略，并且这两步都可以成功执行前提下。如果存在并发，问题会咋样？

2.1 线程安全问题

  现有2个并发请求，请求A和请求B。

  1. 请求A更新数据库（x = 1）
  2. 请求B更新数据库（x = 2）
  3. 请求B更新缓存（x = 2）
  4. 请求A更新缓存（x = 1）

  最后我们发现，数据库中的 x 是2，而缓存中是1。显然是不一致的，缓存中的数据是“脏”的。

2.2 从业务场景角度考虑

  1. 如果业务是写多读少，每次对数据库写操作后，都去做一次缓存更新操作，显然产生了不必要的开销

该缓存策略暂不考虑

3. 先删除缓存，再更新数据库

  假设我们采用【先删除缓存，再更新数据库】策略，并且这两步都可以成功执行前提下。如果存在并发，问题会咋样？

3.1 线程安全问题

  现有2个并发请求，请求A和请求B。

  1. 请求A删除缓存
  2. 请求B发现缓存不存在
  3. 请求B去数据库读取旧值（x = 1）
  4. 请求B将旧值写入缓存（x = 1）
  5. 请求A更新数据库（x = 2）

  上述情况就会导致数据库的值已经被更新，而缓存中的值仍然是旧值的情况。如果不给缓存设置过期时间的话，缓存中的数据永远是“脏”的数据。

3.2 延时双删策略

那么有什么解决办法吗？

  可以采用延时双删策略。其实就是请求A在更新完数据库后，延迟一会时间，然后进行删除缓存操作。具体延迟多久得看具体的业务耗时来定。同步的去淘汰缓存，只会导致吞吐量降低，因此可以将第二次删除以异步的方式来处理。

问题一：

  即便是采取了双删策略，延时时间过短，也不能保证数据一定会一致。

  1. 请求A删除缓存
  2. 请求B发现缓存不存在
  3. 请求B去数据库读取旧值（x = 1）
  4. 请求A更新数据库（x = 2）
  5. 请求A删除缓存（此时请求B还没写入缓存）
  6. 请求B将旧值写入缓存（x = 1）

  发生这种情况主要原因：延时时间过短。

问题二：

  数据库采用了读写分离架构，且同步方案是半同步机制 or 异步复制机制，那么这个延迟时间就要设置更长了

  1. 请求A删除缓存

  2. 请求A更新数据主库（x = 2）

  3. 请求B发现缓存不存在

  4. 请求B去数据从库读取旧值（x = 1）

  5. 数据库完成主从同步，数据从库数据更新（x = 2）

  6. 请求B将旧值写入缓存（x = 1）

  为了解决不一致的问题，可以简单粗暴的增长延时时间。或者数据库采用全同步机制，当然生产环境一般不这样做，mysql性能会受到严重影响。或者读写都在主库，也会影响数据库性能。

4. 先更新数据库，再删除缓存

  这种策略也会存在并发问题吗？

  1. 缓存A刚好失效
  2. 请求A查询数据库，得到一个旧值（x = 1）
  3. 请求B将新值写入数据库
  4. 请求B删除缓存
  5. 请求A将旧值写入到缓存（x = 1）

  如果发生上述情况，确实是会有脏数据存在。不过发生的概率很低，比【先删除缓存，再更新数据库】策略要低。

4.1 主动更新缓存，为啥缓存还要过期时间？

这里插入一个问题？

  我都采用主动更新缓存策略了，为啥缓存要设置过期时间，我不设置可以吗？

  • 缓存是非常昂贵的，对于热点 key 转为冷 key，它们没理由还保存在内存中，如果不设置过期时间，它将永远保存在内存中。
  • 当然你的业务都是热点 key，就可以不设置缓存过期时间，也就不会出现上面的并发问题；甚至所有 key 都可以不设置过期时间，当变成冷 key 后，运维去主动监控、删除，请问你公司的运维会答应吗？

  再回到主题，我们知道上述并发情况一般很少出现，但是如果非要解决这个问题，怎么做？

  • 缓存设置过期时间：缓存过期时间后去取新值，保证最终一致性。（我们采用主动更新缓存策略，就是为了增大过期时间，减少对DB读压力，这里缓存过期虽然可以保证最终一致性，但是会导致不一致时间很长）
  • 延时双删策略：在删除缓存后，延迟一段时间，然后再次删除缓存
  • 保障的重试机制：延时双删会有一个问题，如果第二次删除失败，仍然会出现不一致

5. 最终方案

  我们可以采用 【先更新数据库，再删除缓存】+ 【延时双删策略】+ 【缓存过期】+ 【保障重试机制】来保证缓存最终一致性

在这里插入图片描述

  该方案有个缺点，对业务代码造成大量的侵入。每个更新、删除数据的业务代码都得接入。于是有了了另一种方案，启动一个订阅程序去订阅数据库的 binlog，获得需要操作的数据。在应用程序 中，获取该订阅程序传递来的消息，进行删除缓存操作。

在这里插入图片描述
  这里你会想为啥要第一次删除呢？既然第一次删除可能出行数据不一致。

  数据不一致是有个时间间隔，第一次删除的意义在于可以减少这个间隔，修改成功后，第一次删除保证缓存立马失效去读新的数据。

缺点：

  • 不适合“秒杀”这种频繁修改数据和要求数据强一致的场景，多次删除会导致 nsq 消息多，且删除缓存频繁。（甚至可以理解为要求强一致、更新频繁就不应该用缓存）
【架构】缓存与数据库：双写一致性、缓存问题
不想睡觉的橘子君的博客
07-26 858
这里我讲的是缓存和数据库，以redis和mysql举例，实际上缓存包括不限于浏览器缓存、redis、memcache、本地缓存guava等等，数据库也有很多种，这里我们仅仅以较常见的redis和mysql举例。
Java17 --- redis7缓存双写一致性
qq_46093575的博客
06-18 1320
读写缓存：①、同步直写策略：写数据库后也同步写redis缓存，缓存和数据库中的数据一致，对于读写缓存来说，要想保证缓存和数据库中的数据一致，就要采用同步直写策略。①、在业务程序运行的时候，统计下线程读数据和写缓存的操作时间，评估出项目的读数据业务逻辑的耗时，以此为基础，然后写数据的休眠时间则在读数据业务的耗时上加百毫秒就行。就是如果数据库写入成功，缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存，达到一致性，要以mysql的数据库写入库为准。4、业务cache刷新。
缓存之双写一致性
main方法
05-30 788
文章目录前言一、数据库、缓存双写问题1.先删除缓存再更新数据库2.先更新数据库再删除缓存二、解决方案1.延时双删2.消息队列总结 前言 今天要写的是缓存之双写一致性问题（双写一致是指：缓存与数据库写入保持一致。），什么情况下会产生双写一致性问题，以及解决问题的方案。 一、数据库、缓存双写问题 1.先删除缓存再更新数据库 在缓存删除之后，数据库更新之前的间隙，又有人读取旧数据更新了缓存，数据库更新完数据库，此时数据库和缓存的数据又不一致了。 2.先更新数据库再删除缓存 通过调换顺序确实可以解决问题1，但是更
Redis高级系列-缓存双写一致性
囚徒之困
01-19 1855
redis缓存双写一致性
缓存数据库双写一致性问题
qq_36042938的博客
10-26 506
先写缓存，再写数据库 先操作缓存，在写数据库成功之前，如果有读请求发生，可能导致旧数据入缓存，引发数据不一致 可以考虑用redisson的读写锁实现 先写数据库，再写缓存 会出现数据库中是新数据，缓存中是旧数据的情况， 所以我们需要保证 DB 和缓存的操作，能够在“同一个事务”中，从而实现最终一致性 方式一：基于Lua脚本实现 // 把数据库原子性操作和redis原子性操作放到同一个事物中 @Transactional(propagation = Propagation.REQUIRED, r
Redis---缓存双写一致性
flyingcloud6的博客
07-12 3062
本文总结了redis的缓存双写一致性的知识点。
分布式之数据库和缓存双写一致性方案解析
01-27
本文由以下三个部分组成1、讲解缓存更新策略2、对每种策略进行缺点分析3、针对缺点给出改进方案先做一个说明，从理论上来说，给缓存设置过期时间，是保证最终一致性的解决方案。这种方案下，我们可以对存入缓存的...
Redis缓存双写一致性、穿透（布隆）、雪崩、击穿的案例总结
一个热爱探索的人
05-15 868
关于查询缓存双写一致性、穿透、雪崩、击穿的总结 1、缓存的作用与成本作用：暂存数据处理结果，并提供下次访问使用。在很多场合，数据的处理或者数据获取可能非常费时，当对这个数据的请求量很大时，频繁的数据处理会消耗大量资源。缓存的作用就是将这些来之不易的数据存储起来，当再次请求此数据时，直接从缓存中获取而省略数据处理流程，从而降低资源的消耗提高响应速度 成本：数据不一致问题，缓存层和数据层有时窗口不一致，和更新策略有关；代码维护成本
Redis（高阶篇）03章——缓存双写一致性之更新策略探讨
最新发布
weixin_74019079的博客
02-18 1176
Redis（高阶篇）03 04章——缓存双写一致性之更新策略探讨、Redis与MySQL数据双写一致性工程落地案例
Redis高阶3-缓存双写一致性
sdrfghb的博客
01-23 1485
如果Redis中有数据需要和数据库中的值相同如果redis中无数据数据库中的值要是最新值，且准备回写redis按照操作分为两种只读缓存读写缓存实现双检加锁策略多个线程同时去查询数据库的这条数据，那么我们可以在第一个查询数据的请求上使用一个 互斥锁来锁住它。其他的线程走到这一步拿不到锁就等着，等第一个线程查询到了数据，然后做缓存。后面的线程进来发现已经有缓存了，就直接走缓存。Code 数据库和缓存一致性的几种更新策略 目的：达到最终一致性 ​ 给缓存设置过期时间，定期清理缓存并回写，是保证最终一致性的
缓存与数据库的双写一致性
weixin_42352733的博客
04-06 349
（这边的一致性一般表示的是最终的一致性，因为很难做到强一致性） 一致性就是数据保持一致，在分布式系统中，可以理解为多个节点中数据的值是一致的。 强一致性：这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大 弱一致性：这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态 最终一致性：最终一致性是弱一致性的一个特例，系
缓存双写一致性方案
u013738122的博客
04-13 1156
原文地址 引言 为什么写这篇文章？ 首先，缓存由于其高并发和高性能的特性，已经在项目中被广泛使用。在读取缓存方面，大家没啥疑问，都是按照下图的流程来进行业务操作。 但是在更新缓存方面，对于更新完数据库，是更新缓存呢，还是删除缓存。又或者是先删除缓存，再更新数据库，其实大家存在很大的争议。目前没有一篇全面的博客，对这几种方案进行解析。于是博主战战兢兢，顶着被大家喷的风险，写了这篇文章。...
Redis（十三）缓存双写一致性策略
热门推荐
爱喝星冰乐的博客
02-06 1万+
缓存一致性
缓存与数据库双写，不一致问题及解决方案
weixin_30235225的博客
04-12 2033
面试题 如何保证缓存与数据库的双写一致性？ 面试官心理分析 你只要用缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么你如何解决一致性问题？ 面试题剖析 一般来说，如果允许缓存可以稍微的跟数据库偶尔有不一致的情况，也就是说如果你的系统不是严格要求“缓存+数据库” 必须保持一致性的话，最好不要做这个方案，即：读请求和写请求串行化，串到一个内存队列里...
使用Redis作缓存时，怎么保证缓存和数据库的一致性？
qq_27198345的博客
09-04 1264
使用Redis作缓存时，怎么保证保证缓存和数据库的一致性？ 面试高频考点 在实习项目中，用了Redis来作为缓存。是怎么保证Reids缓存中的数据和数据库中的数据一直的呢？ Redis因为是单线程的，并且很快的读、写速度，常常用来作为缓存加快读写速度。但是缓存数据和数据库数据之间可能存在不一致，在项目中是重点关注的点。 ...
03_缓存双写一致性
Loser_you的博客
08-19 1510
如何选择方案？利弊如何在大多数业务场景下，优先使用先更新数据库，再删除缓存的方案（先更库→后删缓存）。理由如下：先删除缓存值再更新数据库，有可能导致请求因缓存缺失而访问数据库，给数据库带来压力导致打满nysql。如果业务应用中读取数据库和写缓存的时间不好估算，那么，延迟双删中的等待时间就不好设置。如果使用先更新数据库，再删除缓存的方案。
Day05：缓存双写一致性
m0_45253972的博客
12-01 1119
双写一致性：当修改了数据库的数据也要同时更新缓存的数据，缓存和数据库的数据要保持一致。读操作：缓存命中，直接返回；缓存未命中查询数据库，写入缓存，设置超时时间。延迟双删延迟双删是先删除缓存，数据库修改完成之后，再延迟删除一次缓存，就是为了降低脏数据的出现。一般情况下数据库是主从模式，它是读写分离的。延时删除的目的就是为了让主数据库将数据同步到从数据库，这个延时也会出现问题因为多长时间不好控制，在延时的过程中也可能出现脏数据，做不到绝对的强一致。
redis双写一致性旁路缓存
02-14
### Redis 双写一致性旁路缓存实现方案 #### 1. 缓存读取逻辑 当应用程序尝试获取某个键的数据时，会首先访问缓存。如果缓存命中，则直接返回缓存中的数据[^4]。 ```python def get_data_from_cache(key): data = redis.get(key) if data is not None: return data # Cache miss, read from database and populate cache data = db.query(key) # Check deleteKey to avoid dirty reads during replication delay if check_delete_key(key): data = master_db.query(key) # Force read from master else: data = slave_db.query(key) # Normal read from slave redis.setex(key, ttl, data) # Populate the cache with fresh data return data ``` #### 2. 数据更新逻辑 对于数据更新操作，在修改数据库之前先清除对应的缓存条目，并设置一个`deleteKey`标志位用于处理主从延迟期间可能发生的脏读问题[^3]。 ```python def update_data_in_database(key, value): set_delete_key(key) # Set a flag indicating this key was deleted recently try: result = db.update(key, value) clear_delete_key_after_delay(key) # Clear after estimated replication lag time return result finally: redis.delete(key) # Invalidate stale cached entry immediately ``` #### 3. 处理主从复制延迟 为了避免因MySQL主从同步延迟而导致的脏读现象，可以在删除缓存的同时创建一条带有过期时间(`TTL`)等于预计最大主从延迟周期的特殊标记记录(deleteKey)[^3]。 ```python import threading def set_delete_key(key): """Set a temporary marker that indicates recent deletion.""" redis.set(f'delete:{key}', 'true', ex=replication_lag_time) def check_delete_key(key): """Check whether there's an active delete mark for given key.""" return bool(redis.exists(f'delete:{key}')) def clear_delete_key_after_delay(key): timer = threading.Timer(replication_lag_time, lambda: redis.delete(f'delete:{key}')) timer.start() ``` 通过上述措施可以有效解决Redis作为旁路缓存时可能出现的一致性问题，既保持了良好的性能又确保了数据准确性。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值