【线上错误排查】数据库连接池不够用导致的服务集体雪崩

笔者参与了一个产品型项目，流量中等，每天都有很多人在使用，该项目很奇葩，每周六晚上的某个时间段，必定会挂~

此时恢复手段就是重启~，事后根据挂掉的日志去进行代码等方面的优化

笔者刚参与项目两周左右，因为没有服务器的权限，就向有权限的同事要了一份当时挂掉的日志来查看，发现了80% 左右都是数据库的错误，或者是因为数据库挂掉导致的微服务间调用链失败的错误

其中让笔者发现关键错误的一段log，如下

The last packet successfully received from the server was 34,859 milliseconds ago. The last packet sent successfully to the server was 34,859 milliseconds ago.

这个错误很常见，大家应该都见过，当时我根据这个错误去查看数据库连接池的配置，数据库连接池使用的是 druid

当时线上的配置大概是

maxActive: 50
initialSize: 20
maxWait: 60000
minIdle: 10
… 等等

笔者发现该配置的连接池应当是够用的，据反馈当时阿里云上的mysql也很平稳，连接池各项都没有报警，这时候就很奇怪了，为什么还会出现这种获取连接失败的问题呢？周六晚上也不是业务高峰期，业务高峰期也没出现过问题，偏偏就是到周六那个点会挂掉。

笔者当时也没有具体的思路，但是当时比较好奇druid的源码实现方式，就去看看数据库连接池这块的代码，走了个断点调试，这时候新发现就来了，我发现项目的配置文件并没有被注入到druid连接池的配置中，例如最终的maxActive的值竟然还是druid默认的8~！

我又打开了druid提供的监控页面，发现确实，项目所有的配置都没有被注入进去~！笔者观察了一下druid源码获取配置的配置前缀和项目配置前缀完全不同，这时候笔者则是百度了很多druid方面连接池创建的代码做了参考，最终发现，项目这时候用的连接池使用的版本极低。。

采用的是 1.1.0版本 ，这个版本如果想注入自定义的前缀配置必须使用如下方式，问题水落石出了，是因为版本的问题导致了数据库连接池的配置并没有生效，所以导致每个服务的连接不够使用，虽然没有深究到底什么样的极限会触发雪崩（笼统原因肯定是数据库连接被占用完了，其他线程获取不到连接使用），但是基本确定了问题就是这个地方引出来的。

 @ConfigurationProperties(prefix = "spring.datasource")
    @Bean
    public DruidDataSource druidDataSource(){
          return new DruidDataSource();
    }

当时druid的最新版本已经到了1.1.10，所以笔者反馈了此问题，并将微服务的数据库连接池版本都做了升级，测试确认数据库连接池配置正确注入后，在合适的发布时间里进行发布，最后的结果是项目自从做了这个升级后，再也没有出现过周末雪崩的情况~

当时开发组的同事们，都没有会想到会是这个小小的细节导致如此大的问题，笔者也是机缘巧合发现，此处做总结：项目搭建时，一定要对各种配置进行了然于胸，知道每一项是做什么的，出现问题时，围绕着错误周边转，由一个小点，慢慢发散思维，而不是天马行空的一会怀疑到架构，一会怀疑到中间件等等，多从细节基础出发，要问自己，为什么这么多使用开源框架的项目都没有出问题，而是自己使用时出现这种问题，一定是使用姿势不太恰当~ 平时多思考，多了解开源框架的实现原理及其背后的思想~