面试官问我:什么是高并发下的请求合并? (中)

简介: 面试官问我:什么是高并发下的请求合并? (中)

高并发的请求合并


理解了请求合并,那我们再来说说当他前面加上高并发这三个字之后,会发生什么变化。

首先不论是在请求合并的前面加上多么狂拽炫酷吊炸天的形容词,说的多么的天花乱坠,它也还是一个请求合并。

那么队列和定时任务的这个基础结构肯定是不会变的。

高并发的情况下,就是请求量非常的大嘛,那我们把定时任务的频率调高一点不就行了?

以前 100ms 内就会过来 50 笔请求,我每收到一笔就是立即处理了。

现在我们把请求先放到队列里面缓存着,然后每 100ms 就执行一次定时任务。

100ms 到了之后,就会有定时任务把这 100ms 内的所有请求取走,统一处理。

同时,我们还可以控制队列的长度,比如只要 50ms 队列的长度就达到了 50,这个时候我也进行合并处理。不需要等待到 100ms 之后。

其实写到这里,高并发的请求合并的答案已经出来了。关键点就三个:

一是需要借助队列加定时任务实现。

二是控制定时任务的执行时间.

三是控制缓冲队列的任务长度。

方案都想到了,把代码写出来岂不是很容易的事情。而且对于这种面试的场景图,一般都是讨论技术方案,而不太会去讨论具体的代码。

当讨论到具体的代码的时候,要么是对你的方案存疑,想具体的探讨一下落地的可行性。要么就是你答对了,他要准备从代码的交易开始衍生另外的面试题了。

总之,大部分情况下,不会在你给了一个面试官觉得错误的方案之后,他还和你讨论代码细节。你们都不在一个频道了,赶紧换题吧,还聊啥啊。

实在要往代码实现上聊,那么大概率他是在等着你说出一个框架:Hystrix。


Hystrix框架


其实这题,你要是知道 Hystrix,很容易就能给出一个比较完美的回答。

因为 Hystrix 就有请求合并的功能。给大家演示一下。

假设我们有一个学生信息查询接口,调用频率非常的高。对于这个接口我们需要做请求合并处理。

做请求合并,我们至少对应着两个接口,一个是接收单个请求的接口,一个处理把单个请求汇总之后的请求接口。

所以我们需要先提供两个 service:


image.png


其中根据指定 id 查询的接口,对应的 Controller 是这样的:


image.png


服务启动起来后,我们用线程池结合 CountDownLatch 模拟 20 个并发请求:


image.png


从控制台可以看到,瞬间接受到了 20 个请求,执行了 20 次查询 sql:


image.png

很明显,这个时候我们就可以做请求合并。每收到 10 次请求,合并为一次处理,结合 Hystrix 代码就是这样的,为了代码的简洁性,我采用的是注解方式:


image.png

在上面的图片中,有两个方法,一个是 getUserId,直接返回的是null,因为这个方法体不重要,根本就不会执行。

在 @HystrixCollapser 里面可以看到有一个 batchMethod 的属性,其值是 getUserBatchById。

也就是说这个方法对应的批量处理方法就是 getUserBatchById。当我们请求 getUserById 方法的时候,Hystrix 会通过一定的逻辑,帮我们转发到 getUserBatchById 上。

所以我们调用的还是 getUserById 方法:

image.png

同样,我们用线程池结合 CountDownLatch 模拟 20 个并发请求,只是变换了请求地址:

image.png

同样是接受到了 20 个请求,但是每 10 个一批,只执行了两个sql语句。

从 20 个 sql 到 2 个 sql,这就是请求合并的威力。请求合并的处理速度甚至比单个处理还快,这也是性能的提升。

那假设我们只有 5 个请求过来,不满足 10 个这个条件呢?

别忘了,我们还有定时任务呢。

在 Hystrix 中,定时任务默认是每 10ms 执行一次:

image.png

同时我们可以看到,如果不设置 maxRequestsInBatch,那么默认是 Integer.MAX_VALUE。

也就是说,在 Hystrix 中做请求合并,它更加侧重的是时间方面。

功能演示,其实就这么简单,代码量也不多,有兴趣的朋友可以直接搭个 Demo 跑跑看。看看 Hystrix 的源码。

我这里只是给大家指几个关键点吧。

第一个肯定是我们需要找到方法入口。

你想,我们的 getUserById 方法的方法体里面直接是 return null,也就是说这个方法体是什么根本就不重要,因为不会去执行方法体中的代码。它只需要拦截到方法入参,并缓存起来,然后转发到批量方法中去即可。

然后方法体上面有一个 @HystrixCollapser 注解。

那么其对应的实现方式你能想到什么?

肯定是 AOP 了嘛。

所以,我们拿着这个注解的全路径,进行搜索,啪的一下,很快啊,就能找到方法的入口:

com.netflix.hystrix.contrib.javanica.aop.aspectj.HystrixCommandAspect#methodsAnnotatedWithHystrixCommand

image.png

在入口处打上断点,就可以开始调试了:


image.png

目录
相关文章
|
3月前
|
缓存 NoSQL 关系型数据库
|
4月前
|
消息中间件 安全 NoSQL
2023春招面试专题:高并发解决方案(三)
2023春招面试专题:高并发解决方案
|
4月前
|
存储 前端开发 JavaScript
【面试题】面试官问:如果有100个请求,你如何使用Promise控制并发?
【面试题】面试官问:如果有100个请求,你如何使用Promise控制并发?
|
5月前
|
缓存 NoSQL 数据库
2023春招面试专题:高并发解决方案
2023春招面试专题:高并发解决方案
|
3月前
|
缓存 安全 API
【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的API网关设计实现
公司对外开放的OpenAPI-Server服务,作为核心内部系统与外部系统之间的重要通讯枢纽,每天处理数百万次的API调用、亿级别的消息推送以及TB/PB级别的数据同步。经过多年流量的持续增长,该服务体系依然稳固可靠,展现出强大的负载能力。
73 9
【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的API网关设计实现
|
4月前
|
存储 前端开发 JavaScript
面试官问:如果有100个请求,你如何使用Promise控制并发?
面试官问:如果有100个请求,你如何使用Promise控制并发?
|
3月前
|
存储 前端开发 JavaScript
前端面试:如何实现并发请求数量控制?
前端面试:如何实现并发请求数量控制?
100 0
|
3月前
|
存储 消息中间件 Java
【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的高可靠消息服务设计实现
在深入研究了 **“【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的API网关设计实现”** 设计实现后,我们意识到,尽管API网关为服务商提供了高效的数据获取手段,但实时数据的获取仍然是一个亟待解决的问题。
45 1
【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的高可靠消息服务设计实现
|
4月前
|
负载均衡 前端开发 Java
字节后端面试题(前端发送请求到后端的过程(MVC),网关gateway作用,怎么解决跨域,各微服务组件作用)
字节后端面试题(前端发送请求到后端的过程(MVC),网关gateway作用,怎么解决跨域,各微服务组件作用)
144 0
|
4月前
|
SQL 缓存 NoSQL
2023春招面试专题:高并发解决方案(二)
2023春招面试专题:高并发解决方案
144 0

热门文章

最新文章