Java学习笔记（码出高效-Java开发手册-杨冠宝，高海慧）----初识连接池

我们使用连接来进行系统之间的交互，如何管理成千上万的连接呢？

• 为什么需要连接池

  服务器可以快速创建和断开连接，但对于高并发的后台服务器而言，连接的频繁创建与断开，是非常重的负担。就好像我们在紧急处理线上故障，给同时打电话一起定位问题时，一般情况是不会挂断电话，知道问题解决。在时间极度紧张的情况下，频繁地拨打接听电话会降低处理问题的效率。

  在客户端与服务端之间可以事先创建若干连接并提前放置在连接池中，需要时可以直接从连接池中获取，数据传输完成后，将连接归还至连接池中，从而减少频繁创建和释放连接锁造成的开销。

• 数据库连接池

  连接池资源在数据库端是一种非常关键且有限的系统资源。连接过多往往会严重影响数据库性能。

  数据库连接池负责分配、管理和释放连接，这是一种以内存空间换区时间的策略，能够明显地提升数据库操作的性能。但如果数据库连接管理不善，也会影响到整个应用集群的吞吐量。连接池配置错误加上慢SQL，奖项屋漏偏逢连夜雨，可以瞬间让一个系统进入服务超时假死宕机状态

• 合理创建、管理、断开连接

  以Druid为例，Druid是阿里巴巴的一个数据库连接池开源框架，准确来说它不仅仅包括数据库连接池，还提供了强大的监控和扩展功能。当应用启动时，连接池初始化最小连接数（MIN）；当外部请求到达时，直接使用空闲连接即可。加入并发数达到最大（MAX），则需要等待，直到超时。如果未拿到连接，就会抛出异常。

•   MIN  ---- 太小
  

  可能出现过多请求排队等待获取连接

•  MIN ---- 太大 
  

  会造成资源浪费

•  MAX ---- 太小
  

  峰值情况下仍有很多请求处于等待状态

•  MAX ---- 太大
  

  数据库连接被占满，大量请求超时，进而影响其他应用，引发服务的连环雪崩。在实际业务中，加入数据库配置的MAX是100，一个请求10ms，则最大能够处理10000QPS。增大连接数，有可能会超过单台服务器的正常负载能力。

连接数的创建受到服务器操作系统的fd（文件描述符）数量限制的。创建更多的活跃连接，就需要消耗更多的fd，系统默认单个进程同时拥有1024个fd，该值虽然可以调整，但如果无限地增加，会导致服务器在fd的维护和切换上消费过多精力。

开发人员可能为了图省事还会不依不饶地调大Timeout时间，如果这个数值过大，对于调用端来说也是不可接受的。

如果应用服务器超时，前台已经失败返回，但是后台仍然在没有意义地 重试，并且还有新的处理请求不断堆积

最终导致服务器崩溃。这明显是不合理的。

• 应对方案

一个线程就是一个活跃连接。一般可以吧连接池的最大连接数设置在30个左右，理论上还可以设置更大的值。但是DBA一般不会允许，因为往往只有出现了慢SQL，才需要使用更多的连接数。这时候通常需要优化应用层逻辑或者创建数据库索引，而不是一味地采用加大连接数这种指标不治本的做法。极端情况下回导致数据库服务不响应，进而影响其他服务。

从经验上来看，在数据层面的请求应答时间必须在100ms以内，秒级的SQL查询通常存在巨大的性能提升空间，有如下应对方案

1. 建立高效且合适的索引。

索引谁都可以建，但想要建好又难度极大。因为索引既要有数据特征，又有业务特征，数据量的变化会影响索引的选择，业务特点不一样，索引的优化思路也不一样。通常某个字段平时不用，但是某种场景下命中“索引缺失”的字段会导致查询瞬间变慢。所以要事先明确业务场景，建立合适的索引。

2. 排查连接资源为显示关闭的情形

要特别注意在ThreadLoca或流式计算中使用数据库连接的地方

3. 合并短的请求

根据CPU空间局部性原理，对于相近的数据，CPU会一起提取到内存中。另外，合并请求也可以有效减少连接的次数。

4. 合理拆分多个表join的SQL，若是超过三个表则禁止join。

如果表结构建的不合理，应用逻辑处理不当，业务模型抽象有问题，name三标join的数据量由于笛卡尔积操作会呈现几何倍数的增加，所以不推荐这样的做法。另外，对于需要join的字段，数据类型应保持绝对一致。多表付暗恋查询是，应确保被关联的字段要有索引。

5. 使用临时表

某种情况下该方法是一种比较好的选择。曾经遇到一个场景不适用临时表需要执行1个多小时，使用临时表降低到2分钟以内。因为在不断的嵌套查询中，已经无法很好地利用现有 的索引提升查询小哦了，所以把中间结果保存到临时表，然后重建索引，再通过临时表进行后续的数据操作

6. 应用层优化

包括进行数据结构优化、并发多线程改造等

7. 改用其他数据库。

因为不同数据库针对的业务场景是不同的，比如Cassandra、MOngoDB。