多数据源导致生产订单服务假死问题排查以及arthas的使用

问题暴露  

当出现假死问题后，首先出问题的是上游面向用户的服务，汇总问题点

1：上游管理oms卡死
2：上游小程序涉及订单接口很慢到直接卡死

通过生产环境linux命令排查发现cpu以及内存都非常低，观察生产日志刷新很慢，基本确定服务假死不再提供服务，通过重启服务发现，重启后会进行cpu线程数报障但服务可用，持续不到一分钟后暴跌服务假死

环境情况

k8s微服务集群，jdk1.8,springcloud相关组件，mysql数据库

问题排查

1、怀疑数据库问题

生产环境使用腾讯云数据库，通过监控查看发现当前数据库的cpu占用只有百分之零点几，内存方面也很低，通过

2、怀疑nacos转发问题

调用其他同级服务发现一切正常

3、怀疑网络问题

本地通过域名-nginx-服务接口发现正常

4、怀疑jvm内存问题

通过工具发现内存使用很低，在腾讯云服务器观察服务器指标也正常

5、怀疑服务内线程问题

通过引入arthas排查工具，运维同学远程进入当前服务doker内部继续arthas安装

1. 查找当前服务 docker ps -a | grep order-service
2. 通过当前服务进程 docker exec -it a581b287c4bd /bin/bash
3. 下载arthas  curl -O https://arthas.aliyun.com/arthas-boot.jar
4. 直接前端启动arthas java -jar arthas-boot.jar

出现以下界面标识已经进入arthas 

安装好之后通过阿尔萨斯来进行排查诊断，下面是在测试环境进行模拟排查

通过dashboard命令观察当前服务器的情况，如下图

 具体上图可通过阿尔萨斯官网教程中看到。

生产环境的情况是内存都比较良好可以说非常良好，使用的内存非常低，但是线程这个模块就能看出来，当前dashboard会动态刷新，每次刷新可以观察如下，state为RUNNABLE的非常少，切多是为TIMED_WAITING（下图为测试环境）

 可以看到左侧id为306的为TIMED_WAITING状态，通过命令thread 306获取到下图

 

多次刷新后看了多次id后，发现都是在这个地方线程阻塞，通过截图圈红百度发现为druid默认配置没有设置maxWait参数导致druid使用默认参数-1，看代码后发现无可用连接时无限等待，真特么坑，通过配置spring.datasource.druid.maxWait = 7500后解决当前问题，百度druid maxWait发现一堆人出现这个问题，只能说可能在阿里这边来说默认配置出现bug不算bug吧emmmm

疑问点

当前公司使用的数据源从底层统一为hikariCP,怎么会突然冒出来一个druid数据源呢？

通过maven依赖发现这个dynamic-datasource-spring-boot-starter包，看代码提交记录是做了多数据源引入进来的

 那我们默认使用的hikari为毛自动给切换到druid上了呢？

这个后续有空看一下找源代码看看多数据源切换数据源的逻辑