提高接口并发量，防止崩溃

思路：对高并发的接口，单独配置线程池。需考虑线程池内的线程数量，以及tomcat总线程数量与CPU的关系。

线程池的配置

接口如何配置单独的线程池

异步任务 @Async(“myExecutors”)

对实时性要求高的

分析下：实时就是同步，每一次请求就是一条线程，高并发就意味着同时运行大量线程，大量线程意味着对CPU时间片的抢夺会变多，导致CPU使用率飙升，同时IO运算较多也会导致内存占用飙升。总结一下就是，单机是有瓶颈的，我们要测出单机的并发瓶颈，然后使用多机部署（集群or微服务）

QPS://todo

TPS://todo

怎么集群

//todo

怎么微服务

//todo

对实时性要求不高的

⑴ 设置接口幂等性，返回唯一ID，让调用方通过ID查询此次的运行结果（这里用UUID标识的唯一ID，正式项目用 SnowFlake）

    @ApiOperation("测试SUCCESS")
    @RequestMapping("/success")
    @WebLog(description = "请求了测试接口")
    @Async("myExecutors")
    public ResultVo testSuccess(@ApiParam("入参") @RequestBody TestVo testVo) {
        //业务逻辑处理
        String resultCode = service.run();
        return new ResultVo(resultCode, testVo.getID());
    }

（2）提供回调，调用方传入需要回调的接口地址，待异步执行后，把结果返回

@ApiOperation("测试SUCCESS")
@RequestMapping("/success")
@WebLog(description = "请求了测试接口")
@Async("myExecutors")
public void testSuccess(@ApiParam("入参") @RequestBody TestVo testVo) {
         //业务逻辑处理
        String resultCode = service.run();
    	//结果回调
    	AsyncUtil.callBack(testVo.getUrl(),new ResultVo(ResultEnum.SUCCESS, testVo.getID()));
}

线程池的选择

• 使用ThreadPoolExecutor,不要用Executors,具体原因网上搜，一堆

• BlockingQueue对应三种，ArrayBlockingQuere:需要自己设置队列的容量，队列满了以后，将会开始创建maxPoolSize允许的线程数；LinkedBlockingQueue:队列的容量默认设置成了Integer.MaxValue;SynchronousQueue:不存储元素的队列，会直接给线程，使用它的话，线程数量很容易达到maxPoolSize;

单个线程池的线程数量设置

不要相信什么CPU数量+1，CPU数量 X 2 这种公式

理应通过排查当前服务器cpu使用率和负载，对要使用线程的任务进行压测，通过不断的调整CPU使用率和线程数，达到一个领自己满意的数值，这才是最适合的线程数量，如果非要给一个初始值，那么就是核的数量吧，然后反复调整，确定最终的值。

top：命令查询cpu使用率

cpuinfo:文件里查看核心数

线程总数量和CPU的关系

linux中，对于进程所拥有的的线程数有限制，一个进程最大线程数为1024

Tomcat和请求的关系

#最大队列数
server.tomcat.accept-count=100
#最大链接数
server.tomcat.max-connections=8192
#最大线程数
server.tomcat.max-threads=100

• tomcat的最大线程数，可以决定同时处理客户端的请求数量。
• 最大连接数一定要大于最大线程数，否则会有很多请求无响应