五种更新缓存的组合方式

简介: 【4月更文挑战第19天】更新缓存的步骤特别简单,共两步:更新数据库和更新缓存。但这简单的两步中需要考虑很多问题。

更新缓存的步骤特别简单,共两步:更新数据库更新缓存。但这简单的两步中需要考虑很多问题。

  • 先更新数据库还是先更新缓存?更新缓存时先删除还是直接更新?
  • 假设第一步成功了,第二步失败了怎么办?
  • 假设两个线程同时更新同一个数据,A线程先完成第一步,B线程先完成第二步怎么办?


其中第一步就有五种组合:

1、先更新缓存,再更新数据库

对于这个组合,会遇到这种情况:假设第二步更新数据库失败了,要求回滚缓存的更新,这时该怎么办呢?Redis不支持事务回滚,除非采用手工回滚的方式,先保存原有数据,然后再将缓存更新回原来的数据,这种解决方案有些缺陷。


这里简单举个例子。


1)原来缓存中的值是a,两个线程同时更新库存。

2)线程A将缓存中的值更新成b,且保存了原来的值a,然后更新数据库。

3)线程B将缓存中的值更新成c,且保存了原来的值b,然后更新数据库。

4)线程A更新数据库时失败了,它必须回滚,那现在缓存中的值更新成什么呢?


理论上应该更新成c,因为数据库中的值是c,但是,线程A里面无从获得c这个值。如果在线程A更新缓存与数据库的整个过程中,先把缓存及数据库都锁上,确保别的线程不能更新,是否可行?当然是可行的。


但是其他线程能不能读取?假设线程A更新数据库失败回滚缓存时,线程C也加入进来,它需要先读取缓存中的值,这时又返回什么值?不错,这就是典型的事务隔离级别场景。所以就不推荐这个组合,因为此处只是需要使用一下缓存,而这个组合就要考虑事务隔离级别的一些逻辑,成本太大。接着考虑别的组合。


2、先删除缓存,再更新数据库

使用这种方案,即使更新数据库失败了也不需要回滚缓存。这种做法虽然巧妙规避了失败回滚的问题,却引出了两个更大的问题。


1)假设线程A先删除缓存,再更新数据库。在线程A完成更新数据库之前,后执行的线程B反而超前完成了操作,读取Key发现没有数据后,将数据库中的旧值存放到了缓存中。线程A在线程B都完成后再更新数据库,这样就会出现缓存(旧值)与数据库的值(新值)不一致的问题。

2)为了解决一致性问题,可以让线程A给Key加锁,因为写操作特别耗时,这种处理方法会导致大量的读请求卡在锁中。


以上描述的是典型的高可用和一致性难以两全的问题。

3、先更新数据库,再更新缓存

对于这个方案,同样需要考虑两个问题。


1)假设第一步(更新数据库)成功,第二步(更新缓存)失败了怎么办?因为缓存不是主流程,数据库才是,所以不会因为更新缓存失败而回滚第一步对数据库的更新。此时一般采取的做法是重试机制,但重试机制如果存在延时还是会出现数据库与缓存不一致的情况,不好处理。


2)假设两个线程同时更新同一个数据,线程A先完成了第一步,线程B先完成了第二步怎么办?线程A把值更新成a,线程B把值更新成b,此时数据库中的最新值是b,因为线程A先完成了第一步,后完成第二步,所以缓存中的最新值是a,数据库与缓存的值还是不一致,这个逻辑还是有问题的。


因此,也不建议采用这个组合。


4、先更新数据库,再删除缓存

针对组合4,先看看它能不能解决组合3的第二个问题。


假设两个线程同时更新同一个数据,线程A先完成第一步,线程B先完成第二步怎么办?


线程A把值更新成a,线程B把值更新成b,此时数据库中的最新值是b,因为线程A先完成了第一步,所以第二步谁先完成已经不重要了,因为都是直接删除缓存数据。这个问题解决了。


那么,它能解决组合3的第一个问题吗?假设第一步成功,第二步失败了怎么办?这种情况的出现概率与组合3相比明显低不少,因为删除比更新容易多了。


虽然这个组合方案不完美,但出现一致性问题的概率较低。除了组合3会碰到的问题,组合4还会碰到别的问题吗?


是的。假设线程A要更新数据,先完成第一步更新数据库,在线程A删除缓存之前,线程B要访问缓存,那么取得的就是旧数据。这是一个小小的缺陷。那么,以上问题有办法解决吗?


5、先删除缓存,更新数据库,再删除缓存

还有一个方案,就是先删除缓存,再更新数据库,再删除缓存。这个方案其实和先更新数据库,再删除缓存差不多,因为还是会出现类似的问题:假设线程A要更新数据库,先删除了缓存,这一瞬间线程C要读缓存,先把数据迁移到缓存;然后线程A完成了更新数据库的操作,这一瞬间线程B也要访问缓存,此时它访问到的就是线程C放到缓存里面的旧数据。


不过组合5出现类似问题的概率更低,因为要刚好有3个线程配合才会出现问题(比先更新数据库,再删除缓存的方案多了一个需要配合的线程)。


但是相比于组合4,组合5规避了第二步删除缓存失败的问题——组合5是先删除缓存,再更新数据库,假设它的第三步“再删除缓存”失败了,也没关系,因为缓存已经删除了。


其实没有一个组合是完美的,它们都有读到脏数据(这里指旧数据)的可能性,只不过概率不同。根据以上分析,组合5相对来说是比较好的选择


任何一个方案都不是完美的,但如果剩下1%的问题需要花好几倍的代价去解决,从技术上来讲得不偿失,这就要求架构师去说服业务方,去平衡技术的成本和收益。

相关文章
|
SQL 关系型数据库 MySQL
|
SQL 数据库 流计算
实时计算 Flink版操作报错之采集fink指标写入 InfluxDB 时遇到报错,如何处理
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
前端开发 Java 测试技术
selenium+python自动化测试--登录
selenium+python自动化测试--登录
287 2
|
12月前
|
JavaScript
js---三元表达式详解
js---三元表达式详解
403 0
|
存储 安全 JavaScript
解释 XSS 攻击及其预防措施
【8月更文挑战第31天】
1194 0
|
Kubernetes 关系型数据库 分布式数据库
【PolarDB开源】PolarDB与Kubernetes集成:容器化部署的最佳实践
【5月更文挑战第21天】本文介绍了将阿里云的高性能数据库PolarDB与容器编排工具Kubernetes集成的步骤。首先,需准备Kubernetes集群和PolarDB Docker镜像,安装Helm。然后,通过Helm部署PolarDB,设置存储类和副本数。接着,应用配置PolarDB连接信息,打包成Docker镜像并在K8s集群中部署。此外,调整PolarDB参数以优化性能,并使用Prometheus和Grafana监控。本文为PolarDB在Kubernetes中的最佳实践提供了指导。
404 4
|
XML Java Apache
Apache Flink自定义 logback xml配置
Apache Flink自定义 logback xml配置
435 0
|
监控 算法 安全
中间件数据传输数据加密
中间件数据传输加密涉及对称与非对称算法、混合加密、流与块加密模式、密钥管理、SSL/TLS协议、端到端加密、加密级别、合规性及监控审计。确保数据机密性与安全性需综合考虑多方面因素,并遵循相关法规标准。
188 1
|
NoSQL 关系型数据库 MySQL
【Node系列】连接数据库
在Node.js代码中使用mysql模块来连接MySQL数据库、插入、删除和更新数据
178 2
|
Java Nacos 数据安全/隐私保护
Nacos常见问题之无法工作如何解决
Nacos是一款易于使用的动态服务发现、配置管理和服务管理平台,针对不同版本可能出现的兼容性和功能问题,本汇总贴心整理了用户在使用Nacos时可能遇到的版本相关问题及答案,以便用户能够更顺畅地进行服务治理和配置管理。
1149 0