之前写过一篇文章分享了我在工作中遇到了一个因为性能优化出现的一个BUG:异步查询转同步加redis业务实现的BUG分享。
最近又遇到了类似的任务,有一些多查询的接口很适合这种异步查询转同步的优化方案,所以分享一下服务端接口性能优化中用到的这个方案。
个人认为适合该方案的查询接口(涉及写入数据的另外再写)具备一下几个特点:
- 多次查询
- 一次查询时间较长
- 相互不依赖返回结果
伪代码如下:
@Override
public void doExecute(Map<String, Object> dataMap) {
doSomething(dataMap);
CountDownLatch countDownLatch = new CountDownLatch(3);
teacherPadAsyncService.do1(dataMap, countDownLatch, params);
teacherPadAsyncService.do2(dataMap, countDownLatch, params);
teacherPadAsyncService.do3(dataMap, countDownLatch, params);
try {
countDownLatch.await();
} catch (InterruptedException e) {
logger.error("异步处理线程异常", e);
}
}复制代码
实现方法很简单,通过spring的@Async
注解,这里需要修改一些配置,不再赘述,要注意线程安全。
@Async
public void do1(Map<String, Object> dataMap, CountDownLatch countDownLatch, Params params) {
try {
dosomething(dataMap, params);
} catch (Exception e) {
dosomething();
} finally {
countDownLatch.countDown();
}
}复制代码
这也算是一个常规的优化方案,以后有机会再分享一下其他优化方案。