【分布式技术专题】「缓存解决方案」一文带领你好好认识一下企业级别的缓存技术解决方案的运作原理和开发实战(数据缓存不一致分析)

简介: 【分布式技术专题】「缓存解决方案」一文带领你好好认识一下企业级别的缓存技术解决方案的运作原理和开发实战(数据缓存不一致分析)

数据不一致的原因

在引入缓存后,数据就会分散在两个不同的数据源中。由于数据的更新是实时的,因此很难保持数据的一致性,除非采用强一致性方案。在探索适当的解决方案之前,我们需要分析导致数据不一致的主要原因,并针对性地解决这些问题:



逻辑失败导致的数据不一致

之前我们详细分析了三种更新策略。在并发的情况下,无论是先删除缓存再更新数据库,还是先更新数据库再使缓存过期,都可能导致数据不一致的情况。这主要是因为在并发操作下,异步读写请求的时序可能导致了数据不一致,我们将其称为“逻辑失败”。解决这种由并发操作时序导致的问题的核心思想是将异步操作串行化执行。

物理失败导致的数据不一致

Cache Aside 模式中,先更新数据库再删除缓存以及异步双删策略等在同一个事务中,通常情况下,当使用分布式缓存时,如果缓存服务耗时较长,将更新数据库和使缓存失效操作放在同一个事务中,会导致大量的数据库连接挂起,严重降低系统性能,甚至可能因为数据库连接数过多而导致系统崩溃。这种由于缓存操作失败而导致的数据不一致称为"物理失败"。大多数情况下,我们会采用重试的方式解决物理失败的情况。

数据一致性的解决方案

  • 物理失败导致的数据不一致:在绝大部分业务场景中,我们通常追求的是最终一致性。为了解决因物理失败而导致的数据不一致,常见的解决方案包括消费消息异步删除缓存和订阅Binlog。
  • 逻辑失败导致的数据不一致:而对于逻辑失败导致的数据不一致,常用的解决方案则是通过队列实现异步操作的同步化。



消费消息异步删除缓存

当涉及到消费消息异步删除缓存时,需要考虑数据一致性的问题。在这种情况下,如果缓存的删除操作是在消息消费后异步进行的,那么存在以下两种可能的数据一致性问题:

消息处理失败导致的数据不一致:如果消息消费过程中发生了错误,导致缓存删除操作未能正确执行,数据就会出现不一致。为了解决这个问题,可以采取一些措施,如记录消费状态、定期检查未完成的消息、重试消费等。

延迟删除导致的数据不一致:由于异步删除缓存的操作通常需要一定的时间,因此在缓存删除完成之前,可能会出现查询时获取到已经被删除的数据的情况。这种延迟删除可能会导致短暂的数据不一致。为了解决这个问题,可以采用一些方法,如使用合适的缓存过期时间、添加版本控制或标记来跟踪数据更新状态等。

主要流程如下图所示



为了确保数据一致性,可以考虑以下几点建议:

使用事务:如果可能的话,在消费消息和删除缓存的操作之间使用事务,确保它们要么都成功,要么都失败。这可以减少数据不一致的可能性。

监控和日志记录:设置监控机制来检测消息消费和缓存删除的状态,并记录日志以便排查问题和进行故障恢复。

定期校验和修复:定期检查数据一致性,并在发现问题时进行修复。可以编写一些脚本或工具来扫描数据并修复不一致性。

综上所述,要确保消费消息异步删除缓存的数据一致性,需要采取适当的措施来处理潜在的问题,并实施监控和修复机制来确保数据的准确性和一致性。

订阅Binlog

主要流程如下图所示:



利用队列串行化

在分析缓存旁路模式(cache aside pattern)时,我们发现在高并发情况下可能会发生数据不一致的情况,尽管这种情况发生的概率很低。

此外,在并发读写的情况下,如果我们先删除缓存再更新数据库,也可能导致数据不一致的问题。这些问题都是由于并发时序导致的,即写请求还未完成时,读请求就会读取到旧数据。

然而,如果我们能够确保请求的处理能够串行化,即读请求在写请求之后处理,那么就能保证读请求能够读取到最新的数据,从而避免数据不一致的问题。综上所述,我们在处理数据一致性的问题时需要考虑并发场景下请求处理的时序关系。

具体分析

采用队列将请求进行串行化。每个队列只对应一个工作线程。对于更新数据的写请求,我们将其放入队列中,等待异步处理;对于读请求,如果可以从缓存中获取数据,则直接返回;如果缓存中没有数据,我们将读请求放入队列中,等待写请求完成数据更新后再处理。

存在的问题



  • 读请求长时间阻塞:确实,如果队列中有多个写请求,读请求可能会长时间阻塞。为了解决这个问题,可以设置一个适当的超时时间,并在超时后直接从数据库中读取数据返回。这可以确保系统在高并发情况下的响应性。同时,在进行压力测试时,应注意队列中累积的写请求数量,如果积压过多,可以考虑队列的优化措施或相应解决方案。
  • 多个队列分散压力:是的,通过根据数据项进行哈希等路由方式,创建多个队列并行执行可以提高系统的吞吐量。这样可以将负载均衡到多个队列上,降低单个队列的压力,从而提高整体性能。
  • 操作复杂需要考虑全面:确实,将请求进行串行化通过队列是一种有效的数据一致性方案,但也需要考虑到队列的可用性、阻塞情况以及容灾恢复策略等问题。确保队列的稳定性和可靠性非常重要,尽量避免单点故障,并建立相应的容灾方案。

最终一致性

除了提到的三种通用方法,为缓存设置过期时间并定期进行全量同步也是一种接近最终一致性的简单有效方式。通过设置合理的过期时间,可以在缓存中保持数据的一致性,并定期进行全量同步,以确保缓存中的数据与数据库中的数据保持一致。这种方法可以在一定程度上提高系统的性能,并减少对队列串行化的依赖。

总结而言,选择适合业务场景的技术方案非常重要。在决策时,请综合考虑系统性能、数据一致性要求以及资源的限制,并进行权衡和优化。

相关文章
|
8月前
|
Web App开发 存储 缓存
如何精准清除特定类型或标签的缓存数据?
如何精准清除特定类型或标签的缓存数据?
639 57
|
10月前
|
缓存 NoSQL 关系型数据库
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
|
5月前
|
存储 监控 算法
117_LLM训练的高效分布式策略:从数据并行到ZeRO优化
在2025年,大型语言模型(LLM)的规模已经达到了数千亿甚至数万亿参数,训练这样的庞然大物需要先进的分布式训练技术支持。本文将深入探讨LLM训练中的高效分布式策略,从基础的数据并行到最先进的ZeRO优化技术,为读者提供全面且实用的技术指南。
|
7月前
|
存储 缓存 监控
一次缓存引发的文件系统数据不一致问题排查与深度解析
本文详述了一次由自研分布式文件系统客户端 EFC 的缓存架构更新所引发的严重数据不一致问题的完整排查过程。
一次缓存引发的文件系统数据不一致问题排查与深度解析
|
10月前
|
数据采集 存储 NoSQL
基于Scrapy-Redis的分布式景点数据爬取与热力图生成
基于Scrapy-Redis的分布式景点数据爬取与热力图生成
640 67
|
10月前
|
消息中间件 缓存 NoSQL
基于Spring Data Redis与RabbitMQ实现字符串缓存和计数功能(数据同步)
总的来说,借助Spring Data Redis和RabbitMQ,我们可以轻松实现字符串缓存和计数的功能。而关键的部分不过是一些"厨房的套路",一旦你掌握了这些套路,那么你就像厨师一样可以准备出一道道饕餮美食了。通过这种方式促进数据处理效率无疑将大大提高我们的生产力。
318 32
|
11月前
|
负载均衡 NoSQL 算法
Redisson分布式锁数据一致性解决方案
通过以上的设计和实现, Redisson能够有效地解决分布式环境下数据一致性问题。但是, 任何技术都不可能万无一失, 在使用过程中还需要根据实际业务需求进行逻辑屏障的设计和错误处理机制的建立。
480 48
|
7月前
|
存储 负载均衡 NoSQL
【赵渝强老师】Redis Cluster分布式集群
Redis Cluster是Redis的分布式存储解决方案,通过哈希槽(slot)实现数据分片,支持水平扩展,具备高可用性和负载均衡能力,适用于大规模数据场景。
485 2
|
7月前
|
存储 缓存 NoSQL
【📕分布式锁通关指南 12】源码剖析redisson如何利用Redis数据结构实现Semaphore和CountDownLatch
本文解析 Redisson 如何通过 Redis 实现分布式信号量(RSemaphore)与倒数闩(RCountDownLatch),利用 Lua 脚本与原子操作保障分布式环境下的同步控制,帮助开发者更好地理解其原理与应用。
433 6