至此，暂未出现监控异常现象…

梳理&概括

为考虑到各个业务中各数据库资源的使用情况，做出了如下的优化&改造：
1、数据库连接数控制与释放；
2、任务调度Cron频率的控制；
3、数据库连接池构建与优化。

思考&延伸

那如何从架构与DBA的视角来辨证地看待这件事情？这里，我们来深度考量一下，针对上文中出现的这个典型场景的层与次，主要从以下俩个视角来分析看待：

经过多年耕耘，在一次次案例中总结与沉淀，的确遇到过很多连接池、线程池、jvm虚拟机生产故障导致整个服务不可用的情况。

就数据库连接数而言，当应用程序需要与数据库建立连接时，数据库连接池会检测可用的连接取之给到应用程序，当应用程序不再需要连接时，将连接归还给连接池以便其他应用程序可以重复利用。

想必研发同学都很清楚地了解这个机制，而当连接数一直处于增长趋势，不归还不释放的话积累到一定程度，导致连接池打满，当然打满的原因有很多，比如慢SQL、大批量处理等等，与此同时，对外提供服务的线程池也因此可能会受到影响，比如无法及时响应新的请求，或者排队等待进而请求耗时不断增加，接着就会出现界面连接超时的提示！

特别是在任务调度场景中，频繁地去操作DB，先不谈这种业务场景合不合适这样处理，我们抛开来看，需要很明确地知道一点就是，不管是构建连接池也好，给连接池中预先初始化一定的连接数也罢，对数据库的访问必须要合理地去控制！

回归系统技术本源，对一些重要的指标进行监控可以提前预防一些意外故障的发生，进而避免影响业务系统的正常使用！

数据库连接数在每隔一段时间会不断增加，终究是没有释放，还是来不及释放，亦或确实需要这个量去支撑上层的业务？

这里概且不作详细探讨，需要明确地就是使用技术为业务服务，但具体如何使用并应用技术至生产环境中，这个是需要时刻保持敬畏之心！

当然，导致数据库连接数持续增长且不释放，可能是数据库连接池、慢SQL、长事务、应用程序出了故障。如何对此类事件分析加强职业敏感度，是需要仔细推敲的，毕竟，掌握了这里面使用的技术原理，处理起问题来也就更能够镇定自若。与此同时，经过压测、验证、上线这个系统过程也极为重要！

引发猜想

这确实不由地想起N年前与某技术VP的一次对话，Tomact数K的连接数，如何看待？有兴趣的童鞋，可以互相探讨><