缓存和 DB 的一致性保证（一）

最新推荐文章于 2023-05-31 15:30:10 发布

章绍龙

最新推荐文章于 2023-05-31 15:30:10 发布

阅读量534

点赞数 1

CC 4.0 BY-SA版权

分类专栏：高并发架构

本文链接：https://blog.youkuaiyun.com/shaolong1013/article/details/88358461

高并发架构专栏收录该内容

9 篇文章

订阅专栏

本文探讨了在高并发场景下，如何通过分布式锁解决缓存与数据库间的一致性问题，介绍了弱一致性和强一致性的实现策略，并对比了Redis与Zookeeper作为分布式锁的优劣。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

先看业务，业务是不是需要强一致：

弱一致：缓存设定过期时间，过期后自动从db中更新缓存；

强一致：使用分布式锁；

1、线程A先对该key加上分布式锁（锁一定要设置过期时间！！！）

2、线程A删除缓存

（其他线程在查询到缓存数据为空时，尝试去获取分布式锁，获取不到锁，说明有线程正在更新缓存数据，则等待锁或者直接查询数据库）

3、线程A更新数据库

4、线程A更新缓存

5、线程A解锁（如果是redis分布式锁，那么谁加的锁谁来解，使用lua先判断是不是自己加的，然后删除锁）

分布式锁：

1、redis：性能好，redis主从架构本身也存在数据一致性问题

2、zookeeper：大量并发情况下，性能会成为瓶颈

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

章绍龙

关注关注

1
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

数据库和缓存强一致性设计

依旧灬清风的博客

04-18

440

目录单库多库分库分表读写分离数据库+缓存本地缓存+请求路由外部缓存读请求写请求数据库操作和缓存操作具备原子性一般来说，一个业务会经历一下几个阶段单库刚开始流量较小，读写请求都落到同一个库无压力。多库随着业务发展,单库QPS逐渐变高,甚至出现读瓶颈。这时候可以将数据库读写流量分发到多个节点。分库分表 ...

数据库和缓存如何保证一致性？

m0_67698950的博客

06-28

1250

有了这个想法后，就准备开始着手优化服务器，但是挡在在他前面的是这样的一个问题。由于引入了缓存，那么在数据更新时，不仅要更新数据库，而且要更新缓存，这两个更新操作存在前后的问题：没想到太多，他觉得最新的数据肯定要先更新数据库，这样才可以确保数据库里的数据是最新的，于是他就采用了「先更新数据库，再更新缓存」的方案。经过几个夜晚的折腾，终于「优化好了服务器」，然后就直接上线了，自信心满满跑去跟老板汇报。老板不懂技术，自然也没多虑，就让后续阿旺观察下服务器的情况，如果效果不错，就谈画饼的事情。观察了好几天，发现

参与评论您还未登录，请先登录后发表或查看评论

缓存\DB数据一致性

liming0025的专栏

02-09

1238

数据库、缓存数据一致性的问题一直是生产中一直存在的，有一些程序直接忽略这个问题，有些自己编写程序去处理。但是还是存在一下问题：先更新数据库，更新缓存先删除缓存，在更新数据库先更新数据库，在删除缓存一、中间件Canal 其实在工作中不论遇到什么问题，尽量要想到是否有成熟的中间件可以处理，这要比自己造轮子强很多，毕竟经过大部分人验证没问题的中间件是很香的。 1、canal介绍 canal是阿里开发并开源的用于Mysql增量日志数据的订阅、消费和解析的。是要原理是模拟一个Mysql的备机去监听

如何保证db与缓存的数据一致性

技术进阶之路

10-28

7135

为了提升性能，缓存在系统开发中具有普遍的应用。常见的模式是先查询/更新db后再去更新缓存，那么如何保证db和缓存的数据一致性的问题是实际开发中经常遇到的问题。这种场景下容易造成数据不一致的问题主要是缓存双写。一、缓存双写问题先查询或者更新db，然后再更新缓存，这里可能出现的一种不一致的情况是db更新或查询成功，但是缓存更新失败了，这个不一致的问题可以通过重试更新缓存的方...

缓存和DB的一致性

帅东's Blog

07-31

886

打发时间-东如何保证缓存和DB的一致性问题什么时候需要使用缓存？为什么是高可用？什么时候清理缓存？定时清理缓存DB数据有修改如何正确使用缓存（今天的重点）方案1（先删除缓存，再去修改DB）方案2（队列+锁）方案3（DB行锁）方案4（半事务）方案5（自研）总结如何保证缓存和DB的一致性问题在公司还碰见有人竟然不知道这个问题，或者是想的太简单了。简单的提几个问题，如果你都知道了就不用往下看了一定要保证缓存和DB一致性么？缓存一定要设置超时时间么？更新数据，先更新缓存还是DB？查询数据，先查缓存，

如何保证缓存与 DB 的“高”一致性

BigBug_500的博客

01-18

557

无论是本地做缓存还是使用 Redis 做缓存，都会存在数据同步的问题，因为配置信息缓存在内存中，而内存无法感知到数据在数据库的修改。这样就会造成数据库中的数据与缓存中数据不一致的问题。先删除缓存，后更新数据库理想处理流程：可能出现的问题： B 用户可能会得到脏数据 B 用户查询数据时，可能会把获取到的脏数据设置到缓存中，带来其他更加严重的影响。可以使用延时双删来解决对于使用主从复制的数据库而言，B 读取数据时可能会出现延迟的现象。实时性要求高的数据要走主库查询，避免延迟。延时双删在写

第一个保证最终一致性和与DB强一致性的Redis缓存库 .zip

12-04

English |简体中文RocksCache第一个保证最终一致性和与DB强一致性的Redis缓存库。特征最终一致性即使在极端情况下也能确保缓存的最终一致性强一致性为应用程序提供强一致的访问防崩溃缓存崩溃的更好解决方案防渗透防...

如何保证数据库与缓存的数据一致性

lanleihhh的博客

11-04

1438

数据不一致的情况:一、线程A修改数据时，需先执行删除缓存操作二、其他线程只要在线程A删除缓存和执行update期间，查询数据库得到了旧的数据，此时就有极大的概率会出现数据不一致的情况。

高并发下如何保证数据库和缓存双写一致性？

04-01

4238

前言数据库和缓存（比如：redis）双写数据一致性问题，是一个跟开发语言无关的公共问题。尤其在高并发的场景下，这个问题变得更加严重。我很负责的告诉你，该问题无论在面试，还是工作中遇到的概率非常大，所以非常有必要跟大家一起探讨一下。今天这篇文章我会从浅入深，跟大家一起聊聊，数据库和缓存双写数据一致性问题常见的解决方案，这些方案中可能存在的坑，以及最优方案是什么。 1. 常见方案通常情况下，我们使用缓存的主要目的是为了提升查询的性能。大多数情况下，我们是这样使用缓存的：用户请求过来之后，先查缓存

Redis 与 DB 的数据一致 / 双写一致性问题

Java Punk

08-31

2367

缓存提升性能就会有数据更新的延迟，就无法使数据库和缓存数据保持强一致，所以上树的各种优化方案，都是以保证弱一致性，最终一致性为前提的。

db与缓存一致性

哇哦~

01-21

422

背景：我们项目里的代码大量使用了redis缓存，数据更新时，都是先操作db再淘汰缓存，好像也没有遇到什么问题，但心中还是不解，先操作db再淘汰缓存，不是会有数据不一致的情况吗？ db是新的了，再淘汰缓存之前，缓存还是旧的。于是网上查阅记下笔记正确的姿势先要讨论几个问题？ 1.是淘汰缓存还是更新缓存 1.淘汰缓存，会增加cache miss。理论上我们应该倾向于更新缓存。 2.但是...

缓存和DB中数据一致性

Huangy远

12-26

301

缓存和DB中数据一致性 淘汰还是更新一般来说，是淘汰。一般来说，修改的成本会高于淘汰的成本修改的话，假如存的是json字符串，需要先将数据反序列化，然后修改数据，然后序列化，再存入redis。修改的代价高，但是少一次cache miss 淘汰的话，就将数据置为无效，但是多一次cache miss 修改缓存，在并发写的时候，可能出现数据不一致比如说请求1 先写数据库，然后请求2写数...

缓存与db一致性问题

terranhu的博客

05-19

867

缓存和数据库架构：主流方案：用数据service屏蔽缓存和db,读写都走service 非主流方案：异步缓存更新，通过binlog 一缓存与db一致性问题原则：先淘汰缓存，再修改db。如果使用更新缓存在修改DB的方案不会出现下列问题缓存+主库：缓存+主从：双淘汰法（同步，异步timer,binlog分析）二db主从一致性问题不一致原因，主从

缓存与数据库的一致性

chengbinbbs的专栏

04-03

2144

什么是缓存？缓存就是数据交换的缓冲区，针对服务对象的不同（本质就是不同的硬件）都可以构建缓存。目的是，把读写速度慢的介质的数据保存在读写速度快的介质中，从而提高读写速度，减少时间消耗。例如： CPU 高速缓存：高速缓存的读写速度远高于内存。 CPU 读数据时，如果在高速缓存中找到所需数据，就不需要读内存 CPU 写数据时，先写到高速缓存，再回写到内存。磁盘缓存：磁盘缓存其实就...

总算搞懂了！困扰我的Redis缓存与DB一致性问题

weixin_71690375的博客

05-31

613

使用缓存的时候，我们需要关注Redis与DB数据的一致性。如果Redis缓存与DB数据不一致，就可能导致用户一直只能获取到数据错误的缓存，严重影响用户体验。那如何让Redis与DB数据一致性呢？

Redis 之缓存和DB一致性解决

const_

03-26

1613

文章目录缓存数据一致性模式双写模式失效模式缓存数据一致性-解决方案缓存数据一致性模式双写模式失效模式上面两种方案在并发量大的情况下，可能会导致脏数据，为缓存设置过期时间后，数据过期下一次查询会触发更新缓存。缓存数据一致性-解决方案无论是双写模式还是失效模式，都会导致缓存的不一致问题。即多个实例同时更新会出事。怎么办？ 1、如果是用户纬度数据（订单数据、用户数据），这种并发几率非常小，不用考虑这个问题，缓存数据加上过期时间，每隔一段时间触发读的主动更新即可。 2、如果是菜单，商品介绍等基础

缓存和 DB 的数据一致性问题

ProMonkey_chen的博客

10-11

860

缓存和DB的数据不一致主要有两种情况：并发的场景下，导致读取旧的 DB 数据，更新到缓存中。缓存和 DB 的操作，不在一个事务中，可能只有一个操作成功，而另一个操作失败，导致不一致。常用的优化方案，主要是解决两个问题：将缓存可能存在的并行写，实现串行写。实现数据的最终一致性。下面是我们比较常用到的集中优化手段： 1、先淘汰缓存，再写数据库，注意要引入分布式锁，从而实现串行写的...

db和缓存一致性的实现方式

m0_61682705的博客

04-03

493

目录前言 1.方案一 1.1获取缓存逻辑 1.2db更新数据逻辑 1.3存在的问题 2.方案二 2.1获取缓存逻辑 2.2更新db逻辑 3.方案三 3.1获取缓存逻辑 3.2更新db逻辑 3.3存在的问题 4.方案四 4.1获取缓存逻辑 4.2更新db逻辑 4.3消息消费者-清理redis缓存的消费者 4.4存在的问题前言数据存储在数据库中，为了加快业务访问的速度，我们将数据库中的一些数据放在缓存中，那么问题来了，如何确保db和缓存中数据的一致性呢？我们列出了

day111-缓存-分布式锁-缓存一致性解决看这里就够了

JavaCoder_juejue的博客

03-22

351

1.缓存一致性是个啥就是缓存里的数据与数据库里的数据是不是相同的，这种一致性其实也分为实时一致性与最终一致性 2.保证缓存一致性的两种常用方式这两种方式如下图，可以看到都会存在一定的问题双写模式很明显，线程一由于网络或者啥原因，先写库但是却后于线程二刷缓存，缓存内数据自然是有误的失效模式如图，线程一写db然后删缓存，没啥问题，线程二写db，然后还没删缓存的时候，线程三读缓存，线程三此时相当于读的内容中缺少了线程二写入db的内容，也就是此时缓存是少了线程二写的内容的，然后线程

如何保证缓存和数据库的一致性

最新发布

08-01

<think>嗯，用户这次的问题是关于缓存与数据库一致性的系统设计问题，而且特别提到了之前讨论过的Raft算法作为强一致性的解决方案。看来用户正在设计一个分布式系统，需要在性能和一致性之间做权衡。从用户引用的资料来看，ta明显已经做过一些调研，知道强一致性（如Raft）会牺牲性能，也了解了几种常见方案如异步双删、串行化队列等。但ta可能更希望获得系统化的分类和工程实践建议，特别是如何根据业务场景选择方案。用户引用的材料[3]提到银行场景的特殊性，这提示我需要强调业务场景对方案选择的影响。另外引用[2]提到的灰度放量和监控打点很重要，这是工程实践中容易忽略的关键点。在整理方案时，我需要特别注意：第一，避免教科书式的理论堆砌，要突出可落地的技术细节，比如重试机制具体怎么实现第二，给用户提供决策树式的选择逻辑，比如根据业务容忍度区分方案第三，强调监控和灰度的重要性，这是线上系统稳定的关键用户似乎对“最终一致性”和“强一致性”的边界还有些模糊，需要明确说明：使用缓存就意味着不可能做到实时强一致，这是CAP理论的限制。Raft方案虽然能保证强一致，但只适合元数据管理等特定场景。最后要注意示例的实用性，比如延时双删的代码示例要包含重试队列和随机抖动，这是生产环境必备的防雪崩措施。对于金融场景的串行化方案，则要提醒吞吐量会下降到什么程度（比如从万级QPS降到千级）。</think>在分布式系统中保证缓存与数据库的一致性，本质是平衡**性能**与**数据准确性**的矛盾。以下是经过工程验证的完整方案，按一致性强度排序： --- ### 一、强一致性方案（牺牲性能，保证实时一致） #### 1. **Raft/Paxos强一致协议** - **原理**：将缓存与数据库视为整体，通过分布式共识算法（如Raft）保证多副本强一致。 - **适用场景**：金融交易、账户余额等对一致性要求极高的业务。 - **代价**：写入性能下降 30-50%（需多数节点确认）[^1]。 ```mermaid graph LR A[客户端写请求] --> B[Raft Leader] B --> C[同步复制日志到Followers] C --> D[多数节点确认后提交] D --> E[更新数据库+缓存] ``` #### 2. **串行化队列** - **原理**：所有写请求进入单线程队列，严格顺序更新数据库和缓存。 - **实现**： ```python # 伪代码示例：基于Redis的串行化队列 def write_worker(): while True: task = redis_queue.pop() # 阻塞获取任务 db.update(task.data) # 先更新数据库 cache.delete(task.key) # 再删除缓存 ``` - **缺点**：吞吐量骤降（如从10k QPS降至1k QPS），仅适合低频写场景[^3]。 --- ### 二、最终一致性方案（平衡性能与一致性） #### 1. **延时双删（主流方案）** - **流程**： ```mermaid graph LR A[更新数据库] --> B[删除缓存] B --> C[延时几百毫秒] C --> D[再次删除缓存] ``` - **关键优化**： - 第二次删除异步执行，避免阻塞 - 引入重试机制（如失败3次后进入死信队列） - 延时时间 = 主从同步延迟 + 业务读耗时 #### 2. **订阅数据库变更日志（CDC）** - **原理**：监听数据库Binlog（如MySQL的canal），自动更新/删除缓存。 - **优势**： - 缓存与数据库解耦 - 支持多级缓存（如Local Cache + Redis）同步 - **工具**：Debezium, Alibaba Canal, Kafka Connect #### 3. **设置合理的缓存过期时间** - **兜底策略**：所有缓存设置TTL（如30秒），即使出现不一致，也会在过期后自动修复。 - **注意**：需结合业务容忍度设定（如商品详情页可容忍10秒不一致）。 --- ### 三、工程实践关键点 1. **监控与巡检** - 对比DB与缓存的数据差异（抽样率≥0.1%） - 不一致率＞0.01%时触发告警[^2] ```bash # 伪代码：定时巡检脚本 while True: db_data = query_db("SELECT * FROM products WHERE id=1001") cache_data = redis.get("product:1001") if db_data != cache_data: send_alert("数据不一致！") sleep(60) # 每分钟检查一次 ``` 2. **灰度发布与流量控制** - 新策略先作用于5%的流量，验证一致性问题 - 通过限流（如Sentinel）避免缓存雪崩 3. **缓存降级策略** - 当DB压力过大时，短暂允许脏数据 - 记录日志，事后补偿修复 --- ### 四、方案选择决策树 ```mermaid graph TD A[业务需要强一致性？] -->|是| B[使用Raft/串行化队列] A -->|否| C{读多写少？} C -->|是| D[延时双删+TTL兜底] C -->|否| E[CDC日志同步] ``` > **关键结论**： > - 99%场景选择**延时双删+TTL**即可满足需求 > - 强一致性方案仅用于核心金融业务 > - 监控比算法本身更重要[^2][^3]