dueros模拟测试没有请求后台_【原创】实战 | 用手写一个骚气的请求合并,演绎底层的真实...

点击上方“java进阶架构师”,选择右上角“置顶公众号

20大进阶架构专题每日送达

0c256ec69d511035596fc9de5ac64538.png


  • 冬来冬往,越来越喜欢软绵绵的被窝了。
  • 厌倦了夏天的酷热,秋天的浮躁,来一首冬天的安静。

一、服务器崩溃的思考

老板说,他要做个现场营销活动,线上线下都要参与推广,这个活动参与人数可能很大哦··· 果然,由于不是我写的代码,所以那天服务器就崩了,崩的时候很安静,写代码的那个人一个人走的,走的时候很安详。

?: 当请求量到达百万级时候,为啥会崩溃呢?e9c8510f69fbb135079de0b4716350df.pngc8ab6decff7761366edfae33df1fdd54.pngf6205049efc79613989c4d26e8e08d15.png

微服务中是通过接口去向服务提供者发起http请求或者rpc(tcp)请求去获取数据,事实上大量请求中,服务端能处理的请求数量有限,服务中充斥着大量的线程,以及数据库等的连接也会被占用完,导致请求响应速度也越来越慢。

?:

  • 响应速度和我们的数据层有关系吗?
  • 能不能去添加服务端服务器呢?
  • 如果能减少客户端向服务端的请求就好了?
  • 限流吗?当前场景能限流吗?
  • 每个线程去查询数据,每次都只查询某一个结果,是不是太浪费了?
  • 我们能不能想办法,提升我们系统的调用性能?

二、有人想看请求合并,今天她来了

上面的一些思路可以用加缓存,加MQ的方式去解决。但是缓存有限,MQ是个队列,有限流的效果。那么,如何才能提高系统的调用能力,我们学习一下,请求合并,结果分发。

  • 正常的请求都是一个请求一个线程,到后台触发相关的业务需求,去调用数据获取业务。
  • 当请求合并后,我们要将多个多个请求合并后统一去批量去调用。

大概的设计思路便是如下图所示:

  1. 常规请求0fc39772ddc29ac939f4d16020bffbaa.png

  2. 请求合并68e0e1198a6cdf82cfa3b6e48076e24f.png

  3. 说下我们的思路

  • 解决请求调用多,比如调用商品数据,经过的服务多,调用链很长,所以查询数据库的次数也就非常多,数据库连接池很快就被用光,导致很多请求被阻塞,也导致应用整体线程数非常高。虽然通过增加数据库连接池大小可以缓解问题,并且可以通过压力测试,但这治标不治本。
  • 查询商品信息的时候,如果同一商品同一时刻有100个请求,那么其中的99次查询是多余的,可以把100个请求合并成一个真实的后台接口调用,只要控制好线程安全即可。我的想法是使用并发计数器来实现再配合本地缓存,计数器可直接用JDK提供的AtomicInteger,线程安全又提供原子操作。
  • 以获取商品信息为例,每个商品id对应一个计数器,计数器初始值默认是0,当一个请求过来后通过incrementAndGet()使计数器自增1并返回自增后的值。当该值等于1,表明该线程在这个时间点上是第一个到达的线程,然后就去调用真实的业务逻辑,在查询到结果后放入到本地缓存中。当该值大于1的时候,表明之前已有线程正在调用业务逻辑,则进入等待状态,并循环的查询本地缓存中是否已有数据可用。获取到结果后都调用decrementAndGet()使计数器减1,计数器被减到0的时候就回到了初始状态,并且当减到0(代表最后一个线程)时清除缓存。
  • 那还有在1000次请求中,请求的数据id不同,但是使用的服务接口相同,都是查询商品库的商品id1~1000的数据,都是从表里面查询,queryDataById(dataId),那我也可以合并这些请求,改为批量查询,然后将数据分发返回。思路就是设计每个请求携带一个请求唯一的traceId,有点像链路跟踪的感觉,简单点可以使用查询的id进行最为跟踪id,将请求放入一个队中,使用定时任务,比如每隔10ms去扫描队列,将这些业务合并请求统一去请求数据库层。
  • 此方案有个数据延迟的地方,就是每次循环时的等待状态的时间。因为一次包含多次查库的业务调用,耗时基本都在几十毫秒,甚至是上百毫秒,可以把该等待睡眠设置小一点,比如10毫秒。这样即不会浪费CPU时间,实时性也比较高,但然也可以通过主动唤醒等待线程的方式,这个操作起来就比较复杂些。在这其中还可以添加一些异常处理、超时控制、最大重试次数,最大并发数(超时最大并发数就快速失败)等。

三、开始演练

  • 模拟一个远程调用接口

import org.springframework.stereotype.Service;

import java.util.*;

/**
* 模拟远程调用ShopData接口
* @author Lijing
*/
@Service
public class QueryServiceRemoteCall {

/**
* 调用远程的商品信息查询接口
*
* @param code 商品编码
* @return 返回商品信息,map格式
*/
public HashMapqueryShopDataInfoByCode(String code) {
try {
Thread.sleep(50L);
} catch (InterruptedException e) {
e.printStackTrace();
}
HashMap hashMap = new HashMap<>();
hashMap.put("shopDataId", new Random().nextInt(999999999));
hashMap.put("code", code);
hashMap.put("name", "小玩具");
hashMap.put("isOk", "true");
hashMap.put("price","3000");return hashMap;
}/**
* 批量查询 - 调用远程的商品信息查询接口
*
* @param codes 多个商品编码
* @return 返回多个商品信息
*/public List> queryShopDataInfoByCodeBatch(List codes) {
List> result = new ArrayList<>();for (String code : codes) {
HashMap hashMap = new HashMap<>();
hashMap.put("shopDataId", new Random().nextInt(999999999));
hashMap.put("code", code);
hashMap.put("name", "棉花糖");
hashMap.put("isOk", "true");
hashMap.put("price","6000");
result.add(hashMap);
}return result;
}
}
  • 使用CountDownLatch模拟并发请求的公共测试类

@RunWith(SpringRunner.class)
@SpringBootTest(classes = MyBotApplication.class)
public class MergerApplicationTests {

long timed = 0L;

@Before
public void start() {
System.out.println("开始测试");
timed = System.currentTimeMillis();
}

@After
public void end() {
System.out.println("结束测试,执行时长:" + (System.currentTimeMillis() - timed));
}

// 模拟的请求数量
private static final int THREAD_NUM = 1000;

// 倒计数器 juc包中常用工具类
private CountDownLatch countDownLatch = new CountDownLatch(THREAD_NUM);

@Autowired
private ShopDataService shopDataService;

@Test
public void simulateCall() throws IOException {
// 创建 并不是马上发起请求
for (int i = 0; i < THREAD_NUM; i++) {
final String code = "code-" + (i + 1);
// 多线程模拟用户查询请求
Thread thread = new Thread(() -> {
try {
// 代码在这里等待,等待countDownLatch为0,代表所有线程都start,再运行后续的代码
countDownLatch.await();
// 模拟 http请求,实际上就是多线程调用这个方法
Map result = shopDataService.queryData(code);
System.out.println(Thread.currentThread().getName() + " 查询结束,结果是:" + result);
} catch (Exception e) {
System.out.println(Thread.currentThread().getName() + " 线程执行出现异常:" + e.getMessage());
}
});
thread.setName("price-thread-" + code);
thread.start();// 启动后,倒计时器倒计数 减一,代表又有一个线程就绪了
countDownLatch.countDown();
}
System.in.read();
}
}
  • 先来个普通调用演示


/**
* 商品数据服务类
* @author lijing
*/
@Service
public class ShopDataService {
@Autowired
QueryServiceRemoteCall queryServiceRemoteCall;

// 1000 用户请求,1000个线程
public MapqueryData(String shopDataId) throws ExecutionException, InterruptedException {
return queryServiceRemoteCall.queryShopDataInfoByCode(shopDataId);
}
}
  • 查询结果展示
开始测试
price-thread-code-3 查询结束,结果是:{code=code-3, shopDataId=165800794, price=3000, isOk=true, name=小玩具}
price-thread-code-994 查询结束,结果是:{code=code-994, shopDataId=735455508, price=3000, isOk=true, name=小玩具}
price-thread-code-36 查询结束,结果是:{code=code-36, shopDataId=781610507, price=3000, isOk=true, name=小玩具}
price-thread-code-993 查询结束,结果是:{code=code-993, shopDataId=231087525, price=3000, isOk=true, name=小玩具}

....... 省略代码中。。。。

price-thread-code-25 查询结束,结果是:{code=code-25, shopDataId=149193873, price=3000, isOk=true, name=小玩具}
price-thread-code-2 查询结束,结果是:{code=code-2, shopDataId=324877405, price=3000, isOk=true, name=小玩具}

.......共计1000次的查询结果

结束测试,执行时长:150
  • 那么我们发现我们可以用code作为一个追踪traceId,然后使用ScheduledExecutorService,CompletableFuture,LinkedBlockingQueue等一些多线程技术,就可以实现这个请求合并,请求分发的简单实现demo.

import javax.annotation.PostConstruct;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.concurrent.*;

/**
* 商品数据服务类
*
* @author lijing
*/
@Service
public class ShopDataService {

class Request {
String shopDataId;
CompletableFuture> completableFuture;
}// 集合,积攒请求,每N毫秒处理
LinkedBlockingQueue queue = new LinkedBlockingQueue<>();@PostConstructpublic void init() {
ScheduledExecutorService scheduledExecutorPool = Executors.newScheduledThreadPool(5);
scheduledExecutorPool.scheduleAtFixedRate(() -> {// TODO 取出所有queue的请求,生成一次批量查询int size = queue.size();if (size == 0) {return;
}
System.out.println("此次合并了多少请求:" + size);// 1、 取出
ArrayList requests = new ArrayList<>();
ArrayList shopDataIds = new ArrayList<>();for (int i = 0; i < size; i++) {
Request request = queue.poll();
requests.add(request);
shopDataIds.add(request.shopDataId);
}// 2、 组装一个批量查询 (不会比单次查询慢很多)
List> mapList = queryServiceRemoteCall.queryShopDataInfoByCodeBatch(shopDataIds);// 3、 分发响应结果,给每一个request用户请求 (多线程 之间的通信)
HashMap> resultMap = new HashMap<>(); // 1000---- 007for (Map map : mapList) {
String code = map.get("code").toString();
resultMap.put(code, map);
}// 1000个请求for (Request req : requests) {
Map result = resultMap.get(req.shopDataId);// 怎么通知对应的1000多个线程,取结果呢?
req.completableFuture.complete(result);
}
}, 0, 10, TimeUnit.MILLISECONDS);
}@Autowired
QueryServiceRemoteCall queryServiceRemoteCall;/**
* 1000 用户请求,1000个线程
*
* @param shopDataId
* @return
* @throws ExecutionException
* @throws InterruptedException
*/public MapqueryData(String shopDataId) throws ExecutionException, InterruptedException {
Request request = new Request();
request.shopDataId = shopDataId;
CompletableFuture> future = new CompletableFuture<>();
request.completableFuture = future;
queue.add(request);// 等待其他线程通知拿结果return future.get();
}
}
  • 测试结果
开始测试
结束测试,执行时长:164

此次合并了多少请求:63
此次合并了多少请求:227
此次合并了多少请求:32
此次合并了多少请求:298
此次合并了多少请求:68
此次合并了多少请求:261
此次合并了多少请求:51

price-thread-code-747 查询结束,结果是:{code=code-747, shopDataId=113980125, price=6000, isOk=true, name=棉花糖}
price-thread-code-821 查询结束,结果是:{code=code-821, shopDataId=568038265, price=6000, isOk=true, name=棉花糖}
price-thread-code-745 查询结束,结果是:{code=code-745, shopDataId=998247608, price=6000, isOk=true, name=棉花糖}

....... 省略代码中。。。。

price-thread-code-809 查询结束,结果是:{code=code-809, shopDataId=479029433, price=6000, isOk=true, name=棉花糖}
price-thread-code-806 查询结束,结果是:{code=code-806, shopDataId=929748878, price=6000, isOk=true, name=棉花糖}

可以看到我们将1000次请求进行了合并,数据也是正常的模拟到了。

四、总结

弊端:

  • 启用请求的成本是执行实际逻辑之前增加的延迟。
  • 如果平均仅需要5毫秒的执行时间,放在一个10毫秒的做一次批处理的合并场景下,则在最坏的情况下,执行时间可能会变为15毫秒。(一定不适合低延迟的RPC场景、一定不适合低并发场景)

场景:

  • 如果很少有超过1或2个请求会并发在一起,则没有必要用。
  • 一个特定的查询同时被大量使用,并且可以将几+个甚至数百个批处理在一起,那么如果能接受处理时间变长一点点,用来减少网络连接欲,这是值得的。(典型如:数据库、Http接口)

扩展:

  • 我们不重复造轮子,在SpringCloud的组件spring-cloud-starter-netflix-hystrix中已经有封装好的轮子HystrixHystrixCollapser来实现请求的合并,以减少通信消耗和线程数的占用
  • 当然他的组件比较复杂,也更全面,支持异步,同步,超时,异常等的处理机制。
  • 但是,从底层思路来说,无非是线程之间的通信,线程的切换,队列等一些并发编程相关的技术,只要我们高度封装和抽象,那也可以手撸一个合并请求的框架处理。

————  e n d ————

快年底了,师长为大家准备了三份面试宝典:

《java面试宝典5.0》

《350道Java面试题:整理自100+公司》

《资深java面试宝典-视频版》

分别适用于初中级,中高级,以及资深级工程师的面试复习。

内容包含java基础、javaweb、各个性能优化、JVM、锁、高并发、反射、Spring原理、微服务、Zookeeper、数据库、数据结构、限流熔断降级等等。

344d945fcb282b8f966b1c4d7c277f43.png

获取方式:点“在看”,V信关注师长的小号:编程最前线并回复 面试 领取,更多精彩陆续奉上。

一、初中级《java面试宝典5.0》,对标8-13K

bd0223fa402093171564226b7df269ee.png

二、中高级《350道Java面试题:整理自100+公司》,对标12-20K

7449c00985287371ba1f109c8922ca00.png

三、资深《java面试突击-视频版》,对标20K+

7d806cd025f1468c627adca82613c0ad.png

1641769b055dabef294bbfd88252b0f5.gif 

在看好不好,喵~ 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值