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

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

数据不一致的原因

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



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

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

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

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

数据一致性的解决方案

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



消费消息异步删除缓存

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

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

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

主要流程如下图所示



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

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

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

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

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

订阅Binlog

主要流程如下图所示:



利用队列串行化

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

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

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

具体分析

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

存在的问题



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

最终一致性

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

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

相关文章
|
29天前
|
存储 消息中间件 缓存
Redis缓存技术详解
【5月更文挑战第6天】Redis是一款高性能内存数据结构存储系统,常用于缓存、消息队列、分布式锁等场景。其特点包括速度快(全内存存储)、丰富数据类型、持久化、发布/订阅、主从复制和分布式锁。优化策略包括选择合适数据类型、设置过期时间、使用Pipeline、开启持久化、监控调优及使用集群。通过这些手段,Redis能为系统提供高效稳定的服务。
|
3天前
|
存储 消息中间件 缓存
Redis:内存数据存储与缓存系统的技术探索
**Redis 概述与最佳实践** Redis,全称Remote Dictionary Server,是流行的内存数据结构存储系统,常用于数据库、缓存和消息中介。它支持字符串、哈希、列表等数据结构,并具备持久化、主从复制、集群部署及发布/订阅功能。Redis适用于缓存系统、计数器、消息队列、分布式锁和实时系统等场景。最佳实践包括选择合适的数据结构、优化缓存策略、监控调优、主从复制与集群部署以及确保安全配置。
12 3
|
7天前
|
缓存 监控 JavaScript
使用 keep-alive 时,监控和分析组件的缓存行为
使用 keep-alive 时,监控和分析组件的缓存行为
|
7天前
|
存储 缓存 NoSQL
了解Redis,第一弹,什么是RedisRedis主要适用于分布式系统,用来用缓存,存储数据,在内存中存储那么为什么说是分布式呢?什么叫分布式什么是单机架构微服务架构微服务的本质
了解Redis,第一弹,什么是RedisRedis主要适用于分布式系统,用来用缓存,存储数据,在内存中存储那么为什么说是分布式呢?什么叫分布式什么是单机架构微服务架构微服务的本质
|
8天前
|
缓存 NoSQL 中间件
应对数据库不断膨胀的数据:缓存和队列中间件
【6月更文挑战第5天】该文探讨了优化数据库使用以提升应用系统性能的策略。文中建议利用Redis缓存和MQ消息队列作为辅助工具,以进一步优化性能和减少资源消耗。
13 2
应对数据库不断膨胀的数据:缓存和队列中间件
|
24天前
|
消息中间件 缓存 监控
中间件如果缓存中存在所需的数据(缓存命中)
【5月更文挑战第12天】中间件如果缓存中存在所需的数据(缓存命中)
35 3
|
24天前
|
存储 缓存 监控
|
27天前
|
存储 缓存 JavaScript
vue中缓存页面数据(刷新不丢失)
vue中缓存页面数据(刷新不丢失)
|
29天前
|
存储 缓存 NoSQL
数据缓存,可以尝试用RocksDB了
`shigen`,一个专注于Java、Python、Vue和Shell的博主,探讨了为何在学习阿里云DRM产品时选择RocksDB而非Redis或Guava。RocksDB是一个高速、可配置的存储系统,适用于Flash和HDFS,支持数据压缩。与Redis相比,RocksDB在高速存储和灵活性上更具优势。在尝试使用RocksDB与SpringBoot集成时遇到问题,目前尚未解决。他还对比了RocksDB、Redis和Guava Cache的特性,强调RocksDB适合大规模、高性能场景,而Redis适合内存存储和实时性需求。
27 0
数据缓存,可以尝试用RocksDB了