Redis缓存与数据库如何保证一致性?同步删除+延时双删+异步监听+多重保障方案

简介: 根据对一致性的要求程度,提出多种解决方案:同步删除、同步删除+可靠消息、延时双删、异步监听+可靠消息、多重保障方案

导航:

【Java笔记+踩坑汇总】Java基础+JavaWeb+SSM+SpringBoot+SpringCloud+瑞吉外卖/谷粒商城/学成在线+设计模式+面试题汇总+性能调优/架构设计+源码解析

目录

一、四种基础同步策略

1.1 同步策略

1.2 更新缓存还是删除缓存?

1.2.1 更新缓存的优缺点

1.2.2 删除缓存的优缺点(推荐)

1.3 先操作数据库还是先删除缓存?

1.3.1 先删除缓存再操作数据库的优缺点

1.3.2 先操作数据库再删除缓存的优缺点(推荐)

1.4 最优同步策略:先更新数据库、再删除缓存

二、同步删除+可靠消息方案

三、延时双删:更高一致性方案

四、异步监听+可靠消息删除方案

五、多重保障:最终强一致方案


一、四种基础同步策略

1.1 同步策略

保证缓存和数据库的双写一致性,共有四种同步策略,即先更新缓存再更新数据库、先更新数据库再更新缓存、先删除缓存再更新数据库、先更新数据库再删除缓存。

  • 先更新缓存再更新数据库:第二步失败缓存库是脏数据
  • 先更新数据库再更新缓存:第二步失败缓存库是旧数据
  • 先删除缓存再更新数据库:第二步失败缓存库是空数据
  • 先更新数据库、再删除缓存(推荐):第二步失败缓存库是旧数据

1.2 更新缓存还是删除缓存?

1.2.1 更新缓存的优缺点

更新缓存的优点是每次数据变化时都能及时地更新缓存,这样不容易出现查询未命中的情况,但这种操作的消耗很大,如果数据需要经过复杂的计算再写入缓存的话,频繁的更新缓存会影响到服务器的性能。如果是写入数据比较频繁的场景,可能会导致频繁的更新缓存却没有业务来读取该数据。

1.2.2 删除缓存的优缺点(推荐)

删除缓存的优点是操作简单,无论更新的操作复杂与否,都是直接删除缓存中的数据。这种做法的缺点则是,当删除了缓存之后,下一次容易出现未命中的情况,那么这时就需要再次读取数据库。

那么对比而言,删除缓存无疑是更好的选择

1.3 先操作数据库还是先删除缓存?

1.3.1 先删除缓存再操作数据库的优缺点

情况1:数据库和缓存内容不一致

线程1删除缓存后还没有来得及更新数据库时,线程2读缓存,由于缓存中的数据已经被线程1清空了所以线程2需要去数据库读数据,然后把读到的结果保存到缓存中。此时线程1更新更新数据库成功。就会出现数据库和缓存内容不一致。

情况2:缓存击穿,数据库卡死

线程1删除缓存后还没有来得及更新数据库时,来了大量的读请求,由于缓存中没有数据,导致缓存击穿直接将大量请求访问到数据库,导致数据库崩溃。

1.3.2 先操作数据库再删除缓存的优缺点(推荐)

脏数据问题:先操作数据库但删除缓存失败的话,导致缓存库里一直存留着旧数据,而我们数据库里存的是新数据。

解决办法:异步重试机制

出现上述问题的时候,我们一般采用重试机制解决,而为了避免重试机制影响主要业务的执行,一般建议重试机制采用异步的方式执行。当我们采用重试机制之后由于存在并发,先删除缓存依然可能存在缓存中存储了旧的数据,而数据库中存储了新的数据,二者数据不一致的情况。

1.4 最优同步策略:先更新数据库、再删除缓存

所以我们得到结论:先更新数据库、再删除缓存是影响更小的方案。如果第二步出现失败的情况,则可以采用重试机制解决问题。

同步删除方案: 先更新数据库、再删除缓存。适用于不强制要求数据一致性的情景

流程:先更新数据库、再删除缓存。

问题:

  • 并发时脏数据:在查询数据库到写缓存期间其他线程执行了一次更新删除,导致缓存的数据是旧数据
  • 缓存删除失败:删除失败导致缓存库还是旧数据

二、同步删除+可靠消息方案

同步删除+可靠消息删除: 适用于不强制要求数据一致性的情景

流程:先更新数据库、再删除缓存,如果删除失败就发可靠MQ不断重试删除缓存,直到删除成功或重试5次。

问题:MQ多次重试失败,导致长期脏数据。

三、延时双删:更高一致性方案

延时双删方案:比同步删除策略一致性更高的方案。

流程:先删除缓存再更新数据库,大约在数据库从库更新后再删一次。

问题:时间无法控制,不能保证在数据库从库更新后删除缓存。如果在从库更新前删除,用户再在更新前查从库又把脏数据写在缓存里了。

四、异步监听+可靠消息删除方案

异步监听+可靠消息删除:很多大厂正在使用的方案。

流程:

  1. 更新数据库后不做操作;
  2. Canal等组件监听binlog发现有更新时就发可靠MQ删除缓存;
  3. 如果删除缓存失败,就基于手动ack、retry等机制,让消息在有限次数之内不断重试。

image.gif

优点:

  • 异步删除,性能更高;
  • 可靠消息重试机制,多次删除保证删除成功。

问题:要求canal等binlog抓取组件高可用,如果canal故障,会导致长期脏数据。

五、多重保障:最终强一致方案

多重保障方案:同步删除+ 异步监听+可靠消息删除,缓存时设置过期时间,查询时强制主库查;适合于强制要求数据一致性的情况

  1. 同步删除:先更新数据库、再删除缓存;之后本链路禁止再查该数据,防止没来得及删缓存就又查到旧缓存数据。
  2. Canal监听:Canal等组件监听binlog发现有更新时就发可靠MQ删除缓存;第二重保证删缓存成功;
  3. 延迟消息校验一致性:Canal等组件监听binlog,发延迟MQ,N秒后校验缓存一致性;
  4. 缓存过期时间:每次缓存时设置过期时间;第三重保证删缓存成功;
  5. 强制Redis主库查:以后查缓存时强制从缓存主库查;因为主从同步有延迟,同时不用担心主库压力大,因为分片集群机制。
相关实践学习
消息队列RocketMQ版:基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能,涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
目录
打赏
0
5
5
0
79
分享
相关文章
解决Redis缓存数据类型丢失问题
解决Redis缓存数据类型丢失问题
178 85
云端问道21期方案教学-应对高并发,利用云数据库 Tair(兼容 Redis®*)缓存实现极速响应
云端问道21期方案教学-应对高并发,利用云数据库 Tair(兼容 Redis®*)缓存实现极速响应
云端问道21期实操教学-应对高并发,利用云数据库 Tair(兼容 Redis®)缓存实现极速响应
本文介绍了如何通过云端问道21期实操教学,利用云数据库 Tair(兼容 Redis®)缓存实现高并发场景下的极速响应。主要内容分为四部分:方案概览、部署准备、一键部署和完成及清理。方案概览中,展示了如何使用 Redis 提升业务性能,降低响应时间;部署准备介绍了账号注册与充值步骤;一键部署详细讲解了创建 ECS、RDS 和 Redis 实例的过程;最后,通过对比测试验证了 Redis 缓存的有效性,并指导用户清理资源以避免额外费用。
云数据库Tair:从稳定低延时缓存到 Serverless KV
本次分享聚焦云数据库Tair的使用,涵盖三部分内容:1) Tair概览,介绍其作为稳定低延时缓存及KV数据库服务的特点和优势;2) 稳定低延迟缓存技术,探讨如何通过多线程处理、优化内核等手段提升性能与稳定性;3) 从缓存到Serverless KV的演进,特别是在AI大模型时代,Tair如何助力在线服务和推理缓存加速。Tair在兼容性、性能优化、扩缩容及AI推理加速方面表现出色,满足不同场景需求。
Redis经典问题:缓存穿透
本文详细探讨了分布式系统和缓存应用中的经典问题——缓存穿透。缓存穿透是指用户请求的数据在缓存和数据库中都不存在,导致大量请求直接落到数据库上,可能引发数据库崩溃或性能下降。文章介绍了几种有效的解决方案,包括接口层增加校验、缓存空值、使用布隆过滤器、优化数据库查询以及加强监控报警机制。通过这些方法,可以有效缓解缓存穿透对系统的影响,提升系统的稳定性和性能。
InfluxDB vs TDengine :2025 年了,谁家用的数据库还不能高效读缓存?
在工业互联网和物联网的大数据应用场景中,实时数据的写入和查询性能至关重要。如何快速获取最新设备状态并实时处理数据,直接影响到业务的高效运转。本文将深入分析 TDengine 和 InfluxDB 在缓存机制上的差异,帮助读者更好地理解这两款主流时序数据库在性能优化方面的优劣。
136 1
Redis集群方案汇总:概念性介绍
本文介绍了Redis的三种高可用和分布式解决方案:**Redis Replication(主从复制)**、**Redis Sentinel(哨兵模式)** 和 **Redis Cluster(集群模式)**。Redis Replication实现数据备份和读写分离,适合数据安全和负载均衡场景;Redis Sentinel提供自动故障转移和监控功能,适用于读写分离架构;Redis Cluster通过分布式存储和自动故障转移,解决单点性能瓶颈,适合大规模数据和高并发场景。文中还详细描述了各方案的工作原理、优缺点及适用场景。
39 0
【深入了解MySQL】优化查询性能与数据库设计的深度总结
本文详细介绍了MySQL查询优化和数据库设计技巧,涵盖基础优化、高级技巧及性能监控。
83 0
数据库传奇:MySQL创世之父的两千金My、Maria
《数据库传奇:MySQL创世之父的两千金My、Maria》介绍了MySQL的发展历程及其分支MariaDB。MySQL由Michael Widenius等人于1994年创建,现归Oracle所有,广泛应用于阿里巴巴、腾讯等企业。2009年,Widenius因担心Oracle收购影响MySQL的开源性,创建了MariaDB,提供额外功能和改进。维基百科、Google等已逐步替换为MariaDB,以确保更好的性能和社区支持。掌握MariaDB作为备用方案,对未来发展至关重要。
64 3
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等