【后端面经】【缓存】33|缓存模式:缓存模式能不能解决缓存一致性问题?

简介: 【5月更文挑战第9天】面试准备中,熟悉缓存模式如Cache Aside、Read Through、Write Through、Write Back、Singleflight,以及删除缓存和延迟双删策略,能解决缓存一致性、穿透、击穿和雪崩问题。在自我介绍时展示对缓存模式的理解,例如Cache Aside模式,它是基础模式,读写由业务控制,先写数据库以保证数据准确性,但无法解决所有一致性问题。Read Through模式在缓存未命中时自动从数据库加载数据,可异步加载优化响应时间,但也存在一致性挑战。

面试准备

缓存模式首先要确保自己能够记住这些模式,其次要在公司内部收集一些信息:

  • 公司有没有使用缓存模式,使用了哪些,有没有遇到过缓存一致性的问题,最后如何解决的?

  • 业务使用了缓存后,是如何更新缓存和数据库中的数据的?有没有一致性问题?

缓存模式用的好可以有效缓解数据一致性问题,也可以用于解决缓存穿透、击穿和雪崩的问题。

缓存模式简单来说就是系统里有缓存和数据库,读写数据都要操作这两者。

基本思路

自我介绍的时候提起缓存模式的话题

我对缓存模式有比较深刻的理解,平时会用缓存模式来解决很多问题,比如缓存穿透、雪崩和击穿。

如果面试官问了解哪些缓存模式或用过哪些缓存模式

缓存模式有Cache Aside、Read Through、Write Through、Write Back、Singleflight。除此以外,我还用过删除缓存和延迟双删。

严格意义上,删除缓存和延迟双删不是缓存模式,但是在面试中比较常见,可以顺便提一下。

Cache Aside

什么都不做的时候就是Cache Aside,这个模式把缓存看作一个独立的数据源,当写入的时候,业务方来控制写入顺序。
2024-05-10-21-02-36-image.png

当读取的时候也是由业务方来控制。

2024-05-10-21-02-57-image.png

你先介绍读写的基本操作

Cache Aside是最基本的缓存模式,在这个模式下,业务代码就是把缓存看成是和数据库一样独立的数据源,然后业务代码控制怎么写入缓存,怎么写入数据库。一般情况下,都是优先写入数据库。

最后一句提到了优先写入数据库,那么面试官就会追问为什么先写入数据库

先写数据库是因为大多数业务场景下数据都是以数据库为准的,也就是如果写入数据库成功了,就可以认为这个操作成功了。即使写入缓存失败,但是缓存本身会有过期时间,过期后重新加载,数据就会恢复一致。

最后要加一句总结

不管是先写数据库还是先写缓存,Cache Aside都不能解决数据一致性问题。

如果面试官追问为什么都不能解决,或者有什么不一致的场景,按照图里面的内容来回答就可以。注意观察图里的线程2,是后面开始执行,但是先结束的。
2024-05-10-21-18-35-image.png

Read Through

这个缓存模式叫做读穿透,核心是当缓存里没有数据的时候,缓存会代替你去数据库里面把数据加载出来,并且缓存起来。
2024-05-10-21-22-48-image.png

而写入的时候,就和 Cache Aside 一样。

Read Through 也是一个很常用的缓存模式。Read Through 是指在读缓存的时候,如果缓存未命中,那么缓存会代替业务代码去数据库中加载数据。

这种模式有两个异步变种,一种是异步写回缓存,一种是完全异步加载数据,然后写回缓存。当然,不管是什么变种,Read Through 都不能解决缓存一致性的问题。

可以注意到,Read Through 只管了读的部分,而写的部分是完全没有管的,所以它的写过程和 Cache Aside 是一样的。因此,它一样有缓存一致性的问题。要是面试官追问,你就用 Cache Aside 中的分析来回答。

最后我们提到异步加载数据,也就是为了引出亮点。

亮点:异步方案

Read Through模式在发现缓存里面没有数据的时候,加载数据、缓存起来这两个步骤是可以考虑异步执行的。所以可以先回答第一个变种。

缓存可以在从数据库加载了数据之后,立刻把数据返回业务代码,然后开启一个线程异步更新缓存。
2024-05-10-21-27-22-image.png

既然缓存数据这个步骤可以异步,那么从数据库中加载数据也可以异步。

第二个变种是直接让整个加载和回写缓存的过程都异步执行。也就是说,如果缓存未命中,那么就直接返回一个错误或者默认值,然后缓存异步地去数据库中加载,并且回写缓存。和第一个变种比起来,这种变种的缺陷是业务方在当次调用中只能拿到错误或者默认值。
2024-05-10-21-28-07-image.png

然后你可以总结一下什么场景可以使用这两个变种。

如果业务方对响应时间的要求非常苛刻,那么就可以考虑使用变种二。代价就是业务方会收到错误响应或者默认值。而变种一其实收益很小,只有在缓存操作很慢的时候才会考虑。比如说缓存大对象,又或者要把一个大对象序列化之后再存储到缓存里面。

目录
相关文章
|
2天前
|
NoSQL Redis 缓存
【后端面经】【缓存】36|Redis 单线程:为什么 Redis 用单线程而 Memcached 用多线程?
【5月更文挑战第17天】Redis常被称为单线程,但实际上其在处理命令时采用单线程,但在6.0后IO变为多线程。持久化和数据同步等任务由额外线程处理,因此严格来说Redis是多线程的。面试时需理解Redis的IO模型,如epoll和Reactor模式,以及其内存操作带来的高性能。Redis使用epoll进行高效文件描述符管理,实现高性能的网络IO。在讨论Redis与Memcached的线程模型差异时,应强调Redis的单线程模型如何通过内存操作和高效IO实现高性能。
28 7
【后端面经】【缓存】36|Redis 单线程:为什么 Redis 用单线程而 Memcached 用多线程?
|
3天前
|
缓存 数据库 NoSQL
【后端面经】【缓存】35|缓存问题:怎么解决缓存穿透、击穿和雪崩问题?--主从切换方案
【5月更文挑战第16天】该方案提出了解决Redis缓存穿透、击穿和雪崩问题的策略。通过使用两个或多个互为备份的Redis集群,确保在单个集群故障时,另一个可以接管。在故障发生时,业务会与备用集群保持心跳检测,并根据业务重要性分批转移流量,逐步增加对备用集群的依赖,同时监控系统稳定性。对于成本敏感的小型公司,可以采用低成本的单机或小规模自建Redis备份。此方案强调渐进式流量转移,以保护系统免受突然压力冲击。
13 1
【后端面经】【缓存】35|缓存问题:怎么解决缓存穿透、击穿和雪崩问题?--主从切换方案
|
4天前
|
缓存 数据库 算法
【后端面经】【缓存】35|缓存问题:怎么解决缓存穿透、击穿和雪崩问题?---解决缓存击穿和雪崩、限流
【5月更文挑战第15天】本文介绍了如何解决缓存击穿和雪崩问题。对于缓存击穿,采用singleflight模式,确保即使热点数据导致大量请求未命中缓存,也只允许一个请求真正查询数据,其他请求等待其结果。对于缓存雪崩,解决方案是在设置过期时间时添加随机偏移量,避免所有数据同时过期。偏移量应与过期时间成正比。此外,限流也是一个重要策略,可以在服务层和数据库层实施,以限制请求流量,保护数据库免受高并发压力。
9 0
【后端面经】【缓存】35|缓存问题:怎么解决缓存穿透、击穿和雪崩问题?---解决缓存击穿和雪崩、限流
|
5天前
|
存储 缓存 NoSQL
【后端面经】【缓存】35|缓存问题:怎么解决缓存穿透、击穿和雪崩问题?---解决缓存穿透
【5月更文挑战第14天】解决缓存穿透问题有两种策略。一是回写特殊值,当数据不存在时,在缓存中存储特殊值以标记,避免下次重复查询数据库。但此方法可能被恶意请求利用,浪费内存。二是使用布隆过滤器,预先判断数据是否存在,减少无效数据库查询。布隆过滤器虽有假阳性可能,但概率低,可接受。此外,可先查缓存再查布隆过滤器,优化正常请求的效率。两种方式各有优劣,实际应用需根据场景选择。
17 3
|
5天前
|
缓存 数据库 NoSQL
【后端面经】【缓存】35|缓存问题:怎么解决缓存穿透、击穿和雪崩问题?---缓存穿透、击穿和雪崩
【5月更文挑战第13天】本文讨论了三种常见的缓存问题:穿透、击穿和雪崩。缓存穿透发生时,请求的数据既不在缓存也不在数据库,可能导致数据库崩溃。缓存击穿指数据仅存在于数据库,热点数据的大量未命中请求会压垮数据库。缓存雪崩则是大量缓存在同一时间过期,引发数据库瞬间压力过大。为应对这些问题,需了解Redis部署(如Cluster或Sentinel)、故障恢复策略,以及公司如何保护数据库。解决缓存问题的经验和预防措施是面试中的重要话题。
12 0
【后端面经】【缓存】35|缓存问题:怎么解决缓存穿透、击穿和雪崩问题?---缓存穿透、击穿和雪崩
|
5天前
|
canal 缓存 NoSQL
【后端面经】【缓存】33|缓存模式:缓存模式能不能解决缓存一致性问题?-03 Refresh Ahead + SingleFlight + 删除缓存 + 延迟双删
【5月更文挑战第11天】Refresh Ahead模式通过CDC异步刷新缓存,但面临缓存一致性问题,可借鉴Write Back策略解决。SingleFlight限制并发加载,减少数据库压力,适合热点数据。删除缓存模式在更新数据库后删除缓存,一致性问题源于读写线程冲突。延迟双删模式两次删除,理论上减少不一致,但可能降低缓存命中率。选用模式需权衡优劣,延迟双删在低并发下较优。装饰器模式可用于实现多种缓存模式,无侵入地增强现有缓存系统。
22 2
|
5天前
|
缓存 数据库 NoSQL
【后端面经】【缓存】33|缓存模式:缓存模式能不能解决缓存一致性问题?-02 Write Through + Write Back
【5月更文挑战第10天】`Write Through`是一种缓存策略,写操作仅需写入缓存,缓存负责更新数据库。异步版本可能丢失数据,而同步变种先写数据库再异步刷新缓存,减少丢数据风险。`Write Back`模式数据先写入缓存,过期时才写入数据库,可能导致数据丢失,但若使用Redis并确保高可用,可部分解决一致性问题。在特定条件下,如使用SETNX命令,能缓解一致性挑战。
16 0
【后端面经】【缓存】33|缓存模式:缓存模式能不能解决缓存一致性问题?-02 Write Through + Write Back
|
5天前
|
监控 Java 开发者
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第13天】随着现代应用的复杂性日益增加,传统的单体应用架构已不足以满足快速迭代和可扩展性的需求。本文将探讨如何通过微服务架构来提升后端开发的效率和系统的可靠性,涵盖微服务设计原则、技术栈选择、部署策略以及维护实践。我们将分析微服务的优势与挑战,并提供一系列实施建议,帮助开发者在构建和维护分布式系统时做出明智决策。
|
1天前
|
监控 负载均衡 API
构建高效可靠的微服务架构:后端开发的新趋势
【5月更文挑战第19天】 在当今快速发展的数字时代,微服务架构已经成为了软件开发领域的一大热点。本文将深入探讨如何构建一个高效且可靠的微服务架构,以满足不断变化的业务需求和应对日益增长的用户需求。我们将从微服务的基本概念、优势、关键技术以及实践建议等方面进行详细阐述,为后端开发人员提供一套完整的解决方案。
|
2天前
|
监控 持续交付 开发者
构建高效微服务架构:后端开发的新范式
【5月更文挑战第18天】 随着现代软件开发的复杂性日益增长,传统的单体应用架构已难以满足快速迭代和灵活部署的需求。本文聚焦于一种新兴的解决方案——微服务架构,探讨其如何为后端开发带来革命性的改变。我们将深入分析微服务的核心概念、优势与挑战,并通过具体案例来阐述如何在实际项目中实施微服务架构。文章旨在为开发者提供一种系统化的方法,帮助他们理解并应用微服务架构,以提升系统的可维护性、扩展性和技术敏捷性。
14 2