最近突然接到上游业务侧通知,其中一个核心接口rt升高,最高耗时达到了15s左右,上游业务受到影响,于是开启了接口优化之路。
优化思路
梳理接口逻辑并加缓存
梳理代码发现该接口依赖了很多其他接口数据。于是对各个接口耗时进行了分析, 将耗时top5的接口全部梳理出来。
- 让接口人自己对接口优化, 但是一般由于排期资源等,可能一时半会没有资源。
- 与接口人确认接口数据的实效性,确定接口是否可以加缓存以及缓存时间对数据影响。于是对接口中人员组织的信息等变化频率不高的接口加缓存, 如果缓存中取不到数据在调接口或者从数据库中取。
- 改单个调用为批量调用。
多线程
通过分析,发现接口耗时的另一个原因是逻辑中有一个比较复杂逻辑计算,并且for的结果互相不影响,没有依赖,以此考虑使用多线程代替for循环。
本例采用了线程池, 在spring初始化时候构建线程
@Configuration
public class ThreadPoolConfig {
/**
* 线程池维护线程所允许的空闲时间
*/
@Value("${async.executor.thread.keep_alive_seconds}")
private int keepAliveSeconds;
/**
* 线程池对拒绝任务(无线程可用)的处理策略
*/
private ThreadPoolExecutor.CallerRunsPolicy callerRunsPolicy = new ThreadPoolExecutor.CallerRunsPolicy();
private static final String EXECUTOR_THREAD = "AsyncExecutorThread-";
@Bean(name = "ruleRunningExecutor")
public ThreadPoolTaskExecutor ruleRunningExecutor() {
ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
executor.setCorePoolSize(4); //核心线程数4
executor.setMaxPoolSize(4); //最大线程数4
executor.setQueueCapacity(100); //队列最大长度100
executor.setKeepAliveSeconds(300); //线程池维护线程所允许的空闲时间300s
executor.setRejectedExecutionHandler(callerRunsPolicy); //线程池对拒绝任务(无线程可用)的处理策略
executor.setThreadNamePrefix(EXECUTOR_THREAD); // 线程名字
executor.setRejectedExecutionHandler(callerRunsPolicy); //拒绝策略
executor.initialize();
return executor;
}
}
上面的@Config和@Bean用法请参考博文 Spring注解@Config与@Bean
由于需要获取线程池返回结果,使用了CompletableFuture
未使用自定义线程池版本
// supplyAsync需要有返回值,runAsync不需要有返回值
List<CompletableFuture<String>> futures = list.stream().map(a -> CompletableFuture.supplyAsync(() -> {
try {
// 操作代码.....
} catch (InterruptedException e) {
e.printStackTrace();
}
return a;
})).collect(Collectors.toList());
List<Stri