在日常应用中，应用使用第三方中间件往往需要进行网络通讯，而网络通讯都是基于TCP三次握手协议进行的，如果在一些高并发的系统中，往往建立连接的速度赶不上系统的速度，从而导致应用的QPS无法上去，因此往往会使用连接池技术，提前进行预创建一些连接放在连接池中，供访问随时从连接池拿连接，而不需要反反复复创建连接，关闭连接，从而提高系统的性能和资源使用率，减少频繁建立和销毁连接所带来的额外开销。那么常见的连接池有基于Http访问的HttpClient，有基于redis 访问的Jedis，也有基于数据库访问的Druid。

在数据库领域有比较成熟的数据库连接池的组件，各个连接池各有优缺点，国内使用最多的还是基于阿里开源的Druid和以性能著称的HikariCP，但连接池的参数较多，每个参数的含义需要了解清楚还是很有必要的，如果不加以正确的配置，很容易导致线上应用发生雪崩或者是服务直接被夯死，以Druid配置参数为例

initialSize：初始化时创建的连接数，连接池创建连接时，会创建initialSize个连接，以确保应用程序在启动时可以立即获取到数据库连接。

maxActive：连接池最大连接数。如果连接池中连接数达到maxActive，则应用获取连接的请求将被阻塞，直到有连接被释放。

minIdle：最小空闲连接数。如果连接池中空闲连接数少于minIdle，会创建新的连接以达到minIdle。

maxWait：获取连接时的最大等待时间（毫秒）。如果连接池中没有可用连接且已经达到最大连接数，则应用获取连接的请求将被阻塞，最多等待maxWait毫秒。

connectTimeout：配置连接超时时间。表示数据库驱动与数据库服务器建立TCP连接的超时时间。

socketTimeout：配置socket的超时时间。表示通过TCP连接发送数据（在这里就是要执行的sql）后，等待响应的超时时间。

当然还有很多其他参数,可参考下面链接，这里面就不一一说明。

https://github.com/alibaba/druid/wiki/DruidDataSource%E9%85%8D%E7%BD%AE%E5%B1%9E%E6%80%A7%E5%88%97%E8%A1%A8

initialSize：设置合理的initialSize，应用启动后可以立即处理并发需求。一般建议initialSize设置为平均并发连接数的60%-80%，MaxActive可略大于预计峰值并发量，预留一定的连接应对突发流量，建议设置成为50-100。

为什么不建议initialSize与MaActive相差很大？是因为如果相差太大，会造成在峰值的时候出现连接池里面的连接不够，而造成大量的创建连接，从而导致连接风暴，initialSize主要是参考平常大多数的连接数是多少，一般比这个稍大即可。

另外如果有一个数据库实例被多个应用使用的话，也要合理分配initialSize值，否则会出现数据库连接数过大的问题。

maxActive：一般100-150即可，当出现100-150 还不能够的时候，主要要考虑去优化SQL语句，而不是一味的扩大连接数，往往连接数被占满是因为SQL语句出现慢SQL导致，所以首要要考虑的是去优化SQL语句的性能。

minIdle：一般和初始化连接数 保持一致即可。

maxWait(ms)：maxWait=-1：默认值，一直等待，maxWait=0：不等待，不推荐配置成-1和0。如果设置为0，则在峰值的时候很容易出现连接超时的报错，导致用户受损，但如果设置成为-1的时候，就会一直处于等待状态，等待被动超时，这样很容易将服务夯死，一般建议设置5000

connectTimeout：建立连接的超时时间，一般设置为2000，一般处于内网的网络环境，连接基本在毫秒级别，建立连接的耗时有限。

socketTimeout：数据库的响应时长，建议基于应用的特征进行设置，如果应用大多数是一些报表或者是一些较为复杂的查询，建议设置的时长长些60s左右，如果应用是面向C端用户的查询，且SQL语句相对较为简单，建议设置10s左右，这个取决于SQL语句的执行时长，当然需要尽一切手段去优化SQL语句，缩短SQL语句的执行时长。

当然Druid的参数也不是一蹴而蹴，主要还是基于应用的特点去有针对性的设置相应的参数，既要防止因为不合理的参数的设置，导致故障时长延长，而不能因为参数的设置过短，而导致业务大量的失败，两者均不可取，需要在这两者中间找到一个想较而然比较均衡的点，同时应该对系统的慢SQL进行监控和及时的优化，确保因为处于一个相对安全可控的状态。