【后端面经】【缓存】33|缓存模式:缓存模式能不能解决缓存一致性问题?-02 Write Through + Write Back

简介: 【5月更文挑战第10天】`Write Through`是一种缓存策略,写操作仅需写入缓存,缓存负责更新数据库。异步版本可能丢失数据,而同步变种先写数据库再异步刷新缓存,减少丢数据风险。`Write Back`模式数据先写入缓存,过期时才写入数据库,可能导致数据丢失,但若使用Redis并确保高可用,可部分解决一致性问题。在特定条件下,如使用SETNX命令,能缓解一致性挑战。

Write Through

这个说法也叫做写穿透,是指当业务方写入数据的时候,只需要写入缓存,缓存会代替业务方去更新数据库。
2024-05-12-10-19-33-image.png

Write Through读数据的步骤跟Cache Aside是一样的

Write Through就是在写入数据的时候,只写入缓存,缓存会代替我们去更新数据库。但是Write Through没有要求先写数据库还是先写缓存,不过一般也是先写数据库。

其次,Write Through也没有讨论如果缓存中原本没有数据,那么写入数据的时候,要不要更新缓存。一般来说,如果预期写入的数据很快就会读到,那么就会刷新缓存中的数据。

Write Through也有对应的异步变种方案。当然,这些变种也都没有解决缓存一致性的问题。

在刚刚的回答里,提到了写入顺序的问题,那么面试官就可能会追问写入一致性的问题。显然,Write Through也没有解决一致性的问题,你同样可以参考Cache Aside中的分析。

亮点:异步方案

类似的,Write Through也可以考虑异步,也就是写入缓存以后,缓存立刻返回结果。
2024-05-12-10-37-05-image.png

但是这种模式是有可能丢数据的,也就是当业务代码收到成功响应之后,缓存崩溃了,那么数据其实并没有写入数据库中。

另一个比较可行的变种是同步写到数据库里,但是会异步刷新缓存。
2024-05-12-10-38-31-image.png

在缓存收到写请求之后,可以直接返回成功响应,然后异步写入数据库和刷新缓存。但是这种方案比较危险,存在数据丢失的风险。

缓存也只可以考虑只写入数据库,然后返回成功响应,后面可以异步刷新缓存。

基本上前者很少用,要用的也是和它很像的Write Back方案。变种二则适合用于缓存写入操作且代价高昂的场景。比如前者提到的,写入大对象或者需要序列化大对象再写入缓存。

Write Back

在这个模式下,当你写入数据的时候,只是写到了缓存,当缓存过期的时候,才会被刷新到数据库。
2024-05-12-10-51-26-image.png

Write Back模式是指我们在更新数据的时候,只把数据更新到缓存中就返回。后续会有一个组件监听缓存中过期的key,在过期的时候将数据刷新到数据库中。显然,只是监听过期key的话还是有问题,比如关闭缓存的时候还是需要把缓存中的数据全部刷新到数据库里。

但是如果数据还在缓存中的时候,缓存突然崩溃了,那数据就直接丢了。

Write Back有一个硬伤,就是如果缓存突然宕机,那么还没有刷新到数据库的数据就彻底丢失了。这也限制了Write Back模式在现实中的应用。不过要是缓存能够做到高可用,也就不容易崩溃,也可以考虑使用。

到这里还可以进一步刷亮点,深入讨论Write Back和数据一致性的问题,所以可以稍微你可以稍微总结一下。

Write Back 最大的优点是排除数据丢失这一点,它能解决数据一致性的问题。

亮点:能否解决数据一致性问题

这里要分成两种情况讨论,使用本地缓存还是使用Redis这种缓存。你可以肯定的是,如果使用的是本地缓存,那么Write Back也会有不一致的问题,毕竟你的数据缓存在多个节点上。但是如果你使用的是Redis,在不考虑缓存丢失的情况下,你就可以做到数据一致性了。

首先,在使用Redis更新数据的时候业务代码只更新缓存,所以对于业务方来说必然是一致的。也就是说,虽然数据库的数据和缓存的数据不一致,但是对于业务方来说,它只能读写到缓存的数据,对业务方来说,数据是一致的。
2024-05-12-11-10-34-image.png

这是第一个前提,也就是写操作不会带来不一致的问题。紧接着你要解释读操作。

当业务方读数据的时候,如果缓存没有数据,就要去数据库里面加载。这个时候,就可能会产生不一致的问题。比如数据库中a=3,读出来以后还没写到缓存里,这个时候来了一个写请求,在缓存中写入了a=4。如果这时候读请求回写缓存,就会用数据库里的老数据覆盖新数据。
2024-05-12-11-13-40-image.png

紧接着补充解决方案。

解决这个问题的思路也很简单,当读请求回写的时候,使用SETNX命令。也就是说,只有当缓存中没有数据的时候,才会回写数据。而如果回写失败了,那么读请求就会再次从缓存里获取数据。
2024-05-12-11-16-55-image.png

最后你一锤定音,总结一下。

因此 Write Back 除了有数据丢失的问题,在缓存一致性的表现上,比其他模式要好。

如果你觉得说 Write Back 解决了一致性问题有点夸张,你可以说 **Write Back 极大地缓解了数据不一致的问题。

目录
相关文章
|
3月前
|
canal 缓存 NoSQL
Redis缓存与数据库如何保证一致性?同步删除+延时双删+异步监听+多重保障方案
根据对一致性的要求程度,提出多种解决方案:同步删除、同步删除+可靠消息、延时双删、异步监听+可靠消息、多重保障方案
Redis缓存与数据库如何保证一致性?同步删除+延时双删+异步监听+多重保障方案
|
4月前
|
消息中间件 缓存 监控
如何保证缓存和数据库的一致性?
保证缓存和数据库的一致性的做法
|
27天前
|
缓存 NoSQL 关系型数据库
mysql和缓存一致性问题
本文介绍了五种常见的MySQL与Redis数据同步方法:1. 双写一致性,2. 延迟双删策略,3. 订阅发布模式(使用消息队列),4. 基于事件的缓存更新,5. 缓存预热。每种方法的实现步骤、优缺点均有详细说明。
|
2月前
|
缓存 监控 算法
小米面试题:多级缓存一致性问题怎么解决
【10月更文挑战第23天】在现代分布式系统中,多级缓存架构因其能够显著提高系统性能和响应速度而被广泛应用。
45 3
|
2月前
|
消息中间件 缓存 中间件
缓存一致性问题,这么回答肯定没毛病!
缓存一致性问题,这么回答肯定没毛病!
|
2月前
|
存储 缓存 NoSQL
大数据-38 Redis 高并发下的分布式缓存 Redis简介 缓存场景 读写模式 旁路模式 穿透模式 缓存模式 基本概念等
大数据-38 Redis 高并发下的分布式缓存 Redis简介 缓存场景 读写模式 旁路模式 穿透模式 缓存模式 基本概念等
66 4
|
2月前
|
存储 缓存 NoSQL
深入理解后端缓存机制的重要性与实践
本文将探讨在后端开发中缓存机制的应用及其重要性。缓存,作为提高系统性能和用户体验的关键技术,对于后端开发来说至关重要。通过减少数据库访问次数和缩短响应时间,缓存可以显著提升应用程序的性能。本文将从缓存的基本概念入手,介绍常见的缓存策略和实现方式,并通过实例展示如何在后端开发中有效应用缓存技术。最后,我们将讨论缓存带来的一些挑战及其解决方案,帮助您在实际项目中更好地利用缓存机制。
|
3月前
|
机器学习/深度学习 缓存 NoSQL
深度学习在图像识别中的应用与挑战后端开发中的数据缓存策略
本文深入探讨了深度学习技术在图像识别领域的应用,包括卷积神经网络(CNN)的原理、常见模型如ResNet和VGG的介绍,以及这些模型在实际应用中的表现。同时,文章也讨论了数据增强、模型集成等改进性能的方法,并指出了当前面临的计算资源需求高、数据隐私等挑战。通过综合分析,本文旨在为深度学习在图像识别中的进一步研究和应用提供参考。 本文探讨了后端开发中数据缓存的重要性和实现方法,通过具体案例解析Redis在实际应用中的使用。首先介绍了缓存的基本概念及其在后端系统性能优化中的作用;接着详细讲解了Redis的常见数据类型和应用场景;最后通过一个实际项目展示了如何在Django框架中集成Redis,
|
3月前
|
消息中间件 缓存 NoSQL
奇怪的缓存一致性问题
本文记录了缓存一致性问题的排查过程和解决方案,同时带读者朋友们一起回顾下相关的八股文。
|
3月前
|
缓存 NoSQL 关系型数据库
MySQL与Redis缓存一致性的实现与挑战
在现代软件开发中,MySQL作为关系型数据库管理系统,广泛应用于数据存储;而Redis则以其高性能的内存数据结构存储特性,常被用作缓存层来提升数据访问速度。然而,当MySQL与Redis结合使用时,确保两者之间的数据一致性成为了一个重要且复杂的挑战。本文将从技术角度分享MySQL与Redis缓存一致性的实现方法及其面临的挑战。
152 2

热门文章

最新文章