在高并发场景下,往往会出现大量请求同时访问同一个接口的情况。 当然,可以通过缓存、消息队列等机制来缓解被请求方压力。 不过缓存是通过将结果存在访问速度更快的内存中,而消息队列则以降低并发量来减轻压力。 除此之外还有一种策略可以缓解这种情况:请求合并。
业界已经有的请求合并方案: Hystrix
PS:Redis也有pipeline技术来合并请求
本文主要是通过一个简单地例子,来完成一个请求合并的demo,帮助理解这一概念。
没有合并的请求
在合并之前,先看一个简单地无合并的接口,以查询数据库中的记录为例:
1 |
|
每来一个请求就访问一次数据库,请求量大的情况下数据库将不堪重负。
请求合并
构建一个请求类
1 |
|
请求合并服务
1 |
|
测试
测试发送1000个请求
1 |
|
测试结果:
1 |
|
关于时间
请求合并除了能降低被请求方的访问压力,在一些情况下还能提升效率。 在测试中,通过调整线程池的核心线程数来控制同时请求数,得出一些数据,仅供参考:
线程数:32 时间:400~600ms
线程数:100 时间:150~200ms
但是对于某一个请求来说,由于批量处理的定时任务周期执行,其响应时间会变成(周期+原响应时间)