java培训要好多钱,Java面试题及解析
2021/5/20 12:27:45
本文主要是介绍java培训要好多钱,Java面试题及解析,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
一、背景
我们日常在电商网站购物时经常会遇到一些高并发的场景,例如电商 App 上经常出现的秒杀活动、限量优惠券抢购,还有我们去哪儿网的火车票抢票系统等,这些场景有一个共同特点就是访问量激增,虽然在系统设计时会通过限流、异步、排队等方式优化,但整体的并发还是平时的数倍以上,为了避免并发问题,防止库存超卖,给用户提供一个良好的购物体验,这些系统中都会用到锁的机制。
对于单进程的并发场景,可以使用编程语言及相应的类库提供的锁,如 Java 中的 synchronized 语法以及 ReentrantLock 类等,避免并发问题。
Cache aside
Cache aside
也就是旁路缓存
,是比较常用的缓存策略。
(1)读请求
常见流程
应用首先会判断缓存是否有该数据,缓存命中直接返回数据,缓存未命中即缓存穿透到数据库,从数据库查询数据然后回写到缓存中,最后返回数据给客户端。
(2)写请求
常见流程
首先更新数据库,然后从缓存中删除该数据。
看了写请求的图之后,有些同学可能要问了:为什么要删除缓存,直接更新不就行了?这里涉及到几个坑,我们一步一步踩下去。
Cache aside踩坑
Cache aside策略如果用错就会遇到深坑,下面我们来逐个踩。
踩坑一:先更新数据库,再更新缓存
如果同时有两个写请求
需要更新数据,每个写请求都先更新数据库再更新缓存,在并发场景可能会出现数据不一致的情况。
如上图的执行过程:
(1)写请求1
更新数据库,将 age 字段更新为18;
(2)写请求2
更新数据库,将 age 字段更新为20;
(3)写请求2
更新缓存,缓存 age 设置为20;
(4)写请求1
更新缓存,缓存 age 设置为18;
执行完预期结果是数据库 age 为20,缓存 age 为20,结果缓存 age为18,这就造成了缓存数据不是最新的,出现了脏数据。
踩坑二:先删缓存,再更新数据库
如果写请求
的处理流程是先删缓存再更新数据库
,在一个读请求
和一个写请求
并发场景下可能会出现数据不一致情况。
如上图的执行过程:
(1)写请求
删除缓存数据;
(2)读请求
查询缓存未击中(Hit Miss),紧接着查询数据库,将返回的数据回写到缓存中;
(3)写请求
更新数据库。
整个流程下来发现数据库
中age为20,缓存
中age为18,缓存和数据库数据不一致,缓存出现了脏数据。
踩坑三:先更新数据库,再删除缓存
在实际的系统中针对写请求
还是推荐先更新数据库再删除缓存
,但是在理论上还是存在问题,以下面这个例子说明。
如上图的执行过程:
(1)读请求
先查询缓存,缓存未击中,查询数据库返回数据;
(2)写请求
更新数据库,删除缓存;
(3)读请求
回写缓存;
整个流程操作下来发现数据库age为20
,缓存age为18
,即数据库与缓存不一致,导致应用程序从缓存中读到的数据都为旧数据。
但我们仔细想一下,上述问题发生的概率其实非常低,因为通常数据库更新操作比内存操作耗时多出几个数量级,上图中最后一步回写缓存(set age 18)速度非常快,通常会在更新数据库之前完成。
如果这种极端场景出现了怎么办?我们得想一个兜底的办法:缓存数据设置过期时间
。通常在系统中是可以允许少量的数据短时间不一致的场景出现。
Read through
在 Cache Aside 更新模式中,应用代码需要维护两个数据源头:一个是缓存,一个是数据库。而在 Read-Through
策略下,应用程序无需管理缓存和数据库,只需要将数据库的同步委托给缓存提供程序 Cache Provider
即可。所有数据交互都是通过抽象缓存层
完成的。
如上图,应用程序只需要与Cache Provider
交互,不用关心是从缓存取还是数据库。
在进行大量读取时,Read-Through
可以减少数据源上的负载,也对缓存服务的故障具备一定的弹性。如果缓存服务挂了,则缓存提供程序仍然可以通过直接转到数据源来进行操作。
Read-Through 适用于多次请求相同数据的场景
,这与 Cache-Aside 策略非常相似,但是二者还是存在一些差别,这里再次强调一下:
- 在 Cache-Aside 中,应用程序负责从数据源中获取数据并更新到缓存。
- 在 Read-Through 中,此逻辑通常是由独立的缓存提供程序(Cache Provider)支持。
Write through
Write-Through
策略下,当发生数据更新(Write)时,缓存提供程序 Cache Provider
负责更新底层数据源和缓存。
缓存与数据源保持一致,并且写入时始终通过抽象缓存层
到达数据源。
Cache Provider
类似一个代理的作用。
Write behind
Write behind
在一些地方也被成为Write back
, 简单理解就是:应用程序更新数据时只更新缓存, Cache Provider
每隔一段时间将数据刷新到数据库中。说白了就是延迟写入
。
如上图,应用程序更新两个数据,Cache Provider 会立即写入缓存中,但是隔一段时间才会批量写入数据库中。
这种方式有优点也有缺点:
-
优点
是数据写入速度非常快,适用于频繁写的场景。 -
缺点
是缓存和数据库不是强一致性,对一致性要求高的系统慎用。
最后
针对以上面试题,小编已经把面试题+答案整理好了,想要获取这份面试题+答案的朋友帮忙点赞后,戳这里免费领取就可以了
面试专题
除了以上面试题+答案,小编同时还整理了微服务相关的实战文档也可以分享给大家学习
8874683)]
除了以上面试题+答案,小编同时还整理了微服务相关的实战文档也可以分享给大家学习
[外链图片转存中…(img-LQHVmNcY-1621478874684)]
[外链图片转存中…(img-cOzTib2u-1621478874685)]
这篇关于java培训要好多钱,Java面试题及解析的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-06-19《2023版Java工程师》课程升级公告
- 2024-06-15matplotlib作图不显示3D图,怎么办?
- 2024-06-1503-Loki 日志监控
- 2024-06-1504-让LLM理解知识 -Prompt
- 2024-06-05做软件测试需要懂代码吗?
- 2024-06-0514-ShardingSphere的分布式主键实现
- 2024-06-03为什么以及如何要进行架构设计权衡?
- 2024-05-31全网首发第二弹!软考2024年5月《软件设计师》真题+解析+答案!(11-20题)
- 2024-05-31全网首发!软考2024年5月《软件设计师》真题+解析+答案!(21-30题)
- 2024-05-30【Java】百万数据excel导出功能如何实现