一、背景

接着上一篇的知识：性能测试能力提升-基准、负载、压力、容量测试，本篇文章，我们将主要介绍以下几方面的知识：

• 长连接、短连接
• 连接池的作用
• 连接池的配置优化
• Redis连接池补充知识

二、长连接、短连接

长连接请求模式：客户端连接–创建socket认证连接–维护连接–数据传输–维护连接–数据传输…-关闭连接，简单来说，就是建立一次连接可以长期反复使用。

短连接请求模式：客户端连接–创建socket认证连接–维护连接–数据传输–关闭连接，简单来说，就是每次请求都重新建立一次连接，每次请求完就关闭掉这次连接。

补充知识：
mysql、redis、dubbo通常建议都是使用长连接，通过连接池的方式复用连接。

互联网高并发场景下， 如果是短连接，那需要频繁建立和删除大量的连接，会造成、资源浪费：

• 大量的连接握手验证解析的时间=性能问题
• 大量的连接资源申请、分配内存、清理=性能问题

三、连接池的作用

长连接想要达到建立一次连接可以长期反复使用的目的，必然需要有一个地方来分配管理连接，不然很多请求过来使用连接的时候就乱套了。因此连接池的作用就出来了，主要体现在以下几方面：

• 负责分配、管理和释放连接
• 允许应用程序重复使用一个现有的连接，而不是重新建立一个
• 释放空闲时间超过最大空闲时间的连接，减少资源浪费

四、连接池配置定义

最小空闲连接数（minIdle）

• 连接池在初始化时创建一定数量的连接放到连接池中。
• 无论这些连接是否被使用，连接池都将一直保证至少拥有这么多的连接数量。
• 系统启动时就创建，也叫连接池预热，避免系统启动时，突然爆发大量请求导致短时间内需要创建大量连接，影响性能。
• 如果设置过大，而应用程序对连接的使用量不大，那将会造成连接资源被浪费掉。

最大空闲连接数（maxIdle）

• 连接池中允许存在的最大空闲连接数。
• 比如 minIdle = 10 ；maxIdle = 20 ；maxtotal =40。随着并发量逐渐增加，连接数量逐渐变大，但不会超过40，一段时间后，并发量下降，由于默认取maxIdle配置的连接数量20，所以超出20的连接会被释放，池中稳定存在20个连接。

最大连接数（maxtotal）

• 限定了这个连接池能占有的最大连接数。
• 当应用程序向连接池请求的连接数超过最大连接数量时，这些请求将被加入到等待队列中。

testOnBorrow
建议配置为false。获取连接时执行validationQuery检测连接是否有效，这个配置会降低性能。

testOnReturn
建议配置为false。归还连接时执行validationQuery检测连接是否有效，这个配置会降低性能。

testWhileIdle
建议配置为true。作用跟testOnBorrow是差不多的，当应用向连接池申请连接时，判断这条连接是否是可用的。验证不通过则会直接关闭连接，并重新从连接池获取下一条连接。对性能影响很小，因为是定期检查。

总结：testOnBorrow和testOnReturn在生产环境一般是不开启的，主要是性能考虑，因为如果每次获取或者归还连接时候都要到数据库验证连接有效性，这在高并发的时候会造成性能下降。失效连接主要通过testWhileIdle保证，如果获取到了不可用的数据库连接，一般由应用处理异常。

五、连接池设置考虑的因素

最小空闲连接数是连接池一直保持的连接，所以如果应用程序对连接的使用量不大，将会有大量的连接资源被浪费

最大连接数是连接池能申请的最大连接数，如果连接请求超过此数，后面的连接请求将被加入到等待队列中，这会影响之后的操作

如果最小空闲连接数与最大连接数相差太大，那么最先的连接请求将会获利，之后超过最小连接数量的连接请求等价于建立一个新的连接。最后，这些大于最大空闲连接数的连接在使用完不会马上被释放，它将被放到连接池中等待重复使用或是空闲超时后被释放。

因此根据系统应用的实际情况，设置合理的最小空闲连接数、最大空闲连接数、最大连接数，将会一定程度上提升性能。设置连接池的大小肯定不是越大越好，需要考虑的是当前服务所在应用服务器的性能，网络状况，数据库服务器性能，数据库特性等等。你可以设置一个基础值，然后在实际的性能测试过程中，通过微调，来寻找最合适的连接数。

六、Redis连接池补充知识

对于maxtotal优化要考虑的因素：

• 业务希望的并发量(QPS)
• 命令执行时间
• 小于redis允许的最大连接数（默认10000，可修改）

maxIdle和maxtotal计算:
假如：业务希望的QPS(每秒并发量)是50000。通过压测工具测得一次命令执行(拿连接+执行命令+归还连接)平均耗时为1ms，算得一个连接的QPS(每秒并发量)是1000；

结论：那么理论上需要的资源池大小是50000 / 1000 = 50个=maxIdle的值，避免连接池伸缩带来的性能干扰。maxTotal可以比理论值大一些，为redis预留一些资源，比如80个；

秒杀场景下redis性能提升策略：
多商品秒杀场景下：可以加redis服务器。如果是大促场景下，有很多商品待抢购，由于不同的商品id通过槽位分布在不同的redis集群节点上，可以通过增加redis服务器来分散槽位分配，实现高可用的redis架构。

单商品秒杀场景下：增加redis服务器已无法起到优化作用，因为一个商品只能被分配到某一个redis集群节点中，秒杀这个商品会对当前redis节点产生较大压力！可以使用分段库存锁的思路来解决！比如要秒杀id为001号商品，库存有1000个，可以把001拆分成001-1、001-2、001-3 … 001-10共拆分成10个小id来表示001号商品，每一个小id存储100库存，通过分段锁把单商品抢购优化为多商品抢购。

=================================

以上就是本篇文章的全部内容，下一篇文章，我们将主要介绍JVM GC的相关知识。

如果对你有帮助：
欢迎搜索关注我的微信公众号：程序员杨叔，获取更多测试开发技术资料，每周最新文章也是第一时间在上面发布，你的支持就是作者更新最大的动力！