高并发场景下服务不可使用问题排查

发表于: 2023-10-06 更新于: 2023-10-06 浏览: 41

1.用户中心现状

1.1 查询方式

用户中心查询操作使用【CompletableFuture】 + 【自定义线程池】的方式实现，所有查询均为单表操作，将查询结果在应用层组合后返回给调用方；

1.2 强一致性

用户中心使用读写分离方案，对于强一致性的请求，读请求也需要强制读取主库，但很多操作使用【自定义线程池】，实现方案为：filter拦截需要读取主库的url，需要将上下文透传到【自定义线程池】，配置Mybatis拦截器(aop亦可)，根据透传的上下文，使用 Sharding jdbc 设置强制操作主库：HintManagerHolder.isMasterRouteOnly()

1.3 上下文透传

父子线程透传：

父线程透传给子线程可以使用java提供的 InheritableThreadLocal

提交线程与线程池透传：

但对于使用线程池等会池化复用线程的执行组件的情况，线程由线程池创建好，并且线程是池化起来反复使用的；这时父子线程关系的ThreadLocal值传递已经没有意义，应用需要的实际上是把【任务提交给线程池时】的ThreadLocal值传递到【任务执行时】。

(a)使用TtlRunnable TtlCallable 修饰 Runnable Callable

(b)使用TtlExecutors 修饰线程池

(c)参考文档：https://github.com/alibaba/transmittable-thread-local

1.4 线程池配置

aysncTaskExecutor(原有线程池，上下文透传、强一致性线程池，用于有查询需求的写操作，保证读取请求读取主库、强一致性)

CorePoolSize = 80 MaxPoolSize = 500 QueueCapacity = 2000

TaskExecutorConfig implements AsyncConfigurer(原有线程池，@Async时使用，用于给第三方异步发送消息)

CorePoolSize = 80 MaxPoolSize = 500 QueueCapacity = 2000

cacheThreadPoolExecutor(C端老师增加读取缓存线程池)

CorePoolSize = 80 MaxPoolSize = 500 QueueCapacity = 2000

transactionThreadTaskPool(C端老师增加缓存后、写操作异步刷新缓存需要等数据库提交后refresh)

CorePoolSize = 80 MaxPoolSize = 500 QueueCapacity = 2000

2.根据学员号查询接口异常

/v2/students/search/code

2.1 批量查询学员

2.1.1 问题

当参数学员号较多、且请求量稍大时，会出现TaskRejectedException异常

2.1.2 分析

C端加缓存改造后，将批量学员号批量查询改为遍历查询缓存、缓存无查询数据库refresh，但此时学员号较多，每个学员号都会启动一个线程查询、直到cacheThreadPoolExecutor队列和线程达到上限采用默认抛弃(拒绝)策略。

同一时刻930批量请求将线程池打满

跟踪单个请求

2.2.3 方案

伟华老师已经将根据学员号查询改为批量查询

2.2 单表查询后数据组合方式

2.2.1 问题

service层组合学员、学员号信息，使用CompletableFuture默认的ForkJoin框架提供的线程池，未使用自定义线程池，ForkJoinPool是典型的异步任务线程池，当大量请求从tomcat线程池打过来时，会将请求打到队列、异步处理，请求方可能会超时，不适合做实时api服务

ForkJoinPool默认线程池配置为：

队列数量：WorkQueue MAXIMUM_QUEUE_CAPACITY = 1 << 26; // 64M

线程数量：cpu可用core - 1

2.2.2 方案

(a)使用自定义线程池，改造简单、但使用CompletableFuture方式适合做任务计算、而非实时api服务。

(b)直接使用tomcat主线程，串行请求单表数据组合可能会导致RT升高，好处是不用切换线程，有问题会直接抛出，而不是自定义线程池内部消化、且易维护。

3.全链路压测服务不可用

3.1 问题

6万并发用户中心服务不可用：response:{"State":0,"Error":"【用户中心系统】异常，请稍后再试。此时用户中心无法接收处理后续连接请求，重启应用才能恢复，需要用户中心相关老师协助配合排查优化；用户中心异常时压测时间点：（7月22日 00:06/00:20/00:33/00:51）

3.2 用户、订单中心对比分析

吞吐率、响应时间对比：用户中心(6台)、订单中心(3台)

订单单台机器请求量、RT分位图，每分钟请求量6k、最大RT0.2秒、平均5ms

用户中心单台机器请求量、RT分位图，每分钟请求量7.5k、最大RT 9秒左右、平均500ms

3.3 中间件、数据库分析

3.3.1 事务、DB、缓存负载分析

(a)事务分析

前三名分别是：根据studentId查询学员、根据studentCode查询学员、查询真实手机号；最大响应时间长达16.733秒；

(b)数据库分析

吞吐率、响应时间：压测期间、数据库吞吐率没有明显升高，应该是开启缓存的效果、且RT也都在5毫秒左右

慢SQL追踪：次数、响应时间都不大

(c)Redis分析

吞吐率、响应时间：压测期间吞吐率升高，说明流量都打到了redis；响应时间最大值373毫秒、平均RT极小

3.3.2 结论

数据库、Redis非此次压测瓶颈，可以断定程序代码、线程池、JVM参数、垃圾回收器等多方面有调优的可能性

3.4 代码、线程池、虚拟机层分析

3.4.1 异常统计分析

(a) 异常统计

压测期间异常信息总量：6840

压测期间异常信息总量(6840) = RejectedExecutionException(6484) + Redis command timed out(212) + 其他异常(空指针)：144

java.util.concurrent.RejectedExecutionException：6484条

Redis command timed out：212条

其他异常(空指针)：144

(b)异常分析：

大部分异常为 java.util.concurrent.RejectedExecutionException，缓存改造中C端老师使用了【CompletableFuture】 + 【自定义线程池】方式，单台机器最大并发量为queueSize2000 + maxSize500 = 2500，原来徐文老师仅仅使用了【CompletableFuture】方案，CompletableFuture最大队里为64M、线程数量为cpu core - 1，最多会造成超时，但不会造成RejectedExecutionException异常，因为队列足够大64M。

少部分异常为Redis command timed out，可能是瞬间流量过大导致请求redis超时，也可能仅仅是自己程序内部线程竞争。

下面将从垃圾收集器选型、JVM常用参数、线程数量、GC耗时等几个方面分析

3.4.2 垃圾收集器

订单中心：CMS，适合做web应用等实时api服务，STW时间短

用户中心：Java默认的Parallel，适合做任务，吞吐量优先，STW时间长

3.4.3 JVM参数

订单中心：

-server -Xmx4g -Xms4g -Xmn512m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=512m -Xss256k -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:+HeapDumpOnOutOfMemoryError -XX:CMSInitiatingOccupancyFraction=70

用户中心：

-Xmx8g -Xms8g

内存设置过大，使用默认配置old/new=2，老年代2*8/3、年轻代内存8/3g，两者都过大，不利于内存回收，分布式应用应该采取小内存、多节点模式。

3.4.5 线程数量

用户中心是订单中心线程数量的5-7倍

订单中心：

用户中心：

3.4.6 GC耗时

观察用户中心6台机器，在23:30-01:00之间出现几次Full gc、数十次Yong gc，STW时间长达600ms，两方面原因：线程数量过多、跟gc线程抢资源；堆内存设置过大导致gc时间过长

观察订单中心3台机器，在23:30-01:00之间只有Yong gc，无Full gc，且垃圾收集时间在20ms以内

订单中心

用户中心：

3.5 解决方案

3.5.1 线程池

原有方案：【CompletableFuture】+【自定义线程池】并发请求多张表组合数据

当流量较小时，1个tomcat线程对应N个自定义线程请求组合，RT较低；

当流量较大时，假如此时1000 tomcat 线程，那内部需要 N*1000 个线程对应处理任务，当没有这么多线程时，需要进入队列等待，类似于异步处理任务，导致调用方等待超时；当达到自定义线程池上限时（队列满了，线程数量达到maxSize），就会抛出RejectedException

如果依然使用原有方案，因读写操作比例10:1，则应该将写操作线程池aysncTaskExecutor、发送异步消息线程池TaskExecutorConfig，提交事务后刷新缓存线程池 transactionThreadTaskPool 都等写操作线程调小；将读操作改为缓存线程池 Executors.newCachedThreadPool()读取(队列容量为0)，此线程池队列SynchronousQueue，缓存60秒，线程最大为数量为Integer.MAX_VALUE

A [blocking queue](eclipse-javadoc:☂=extend-core/D:\/Soft\/jdk1.8.0_92\/jre\/lib\/rt.jar in which each insert operation must wait for a corresponding remove operation by another thread, and vice versa. A synchronous queue does not have any internal capacity, not even a capacity of one.

依然会有1个请求对应N个线程的问题

建议方案：建议不再使用【CompletableFuture】 + 【自定义线程池】方式查询，直接使用tomcat主线程，串行请求单表数据（数据库或缓存）组合。

当流量较小时，此方案可能会导致单条RT升高，好处是不用切换线程，能够节省部分资源；

当流量较大时，也不会有明显的RT升高、有问题会直接抛出，而不是自定义线程池内部消化、且易维护。

3.5.2 垃圾收集器选型、JVM参数调整

建议使用CMS垃圾收集器，小内存(尤其是年轻代，因大部分都是很快消亡的，Yong gc频繁点远远好于Full gc)、多节点方案