背景
国庆期间重新开发连接池, 发现曾经设计过的不合理的缺陷代码,早已被删除, 由于当时没有注释说明. 这次又稀里糊涂重新写了一遍, 后来才记起为什么不这么写的原因, 浪费了一些时间,非常懊悔.
另外我觉得底层设计必须多次主动优化,必须要有足够的时间研发,要更加深入理解我们调用的每一个函数,还要进行各种场景的测试.才能确保系统安全
每次优化都有很大收货,对很多东西有了新的理解
记录
- 网络中断时, jdbc connection 如何工作的?
- mysql最大连接数与程序最大连接数的关系?
- 如何回收连接到连接池?
- connection.setNetworkTimeout 与DriverManager.setLoginTimeout?
- setAutoCommit() 事务与非事务对连接的影响
网络中断时, jdbc connection 如何工作的?
回答:
网络中断以后,连接并没有马上断开
如果脚本还没有开始执行,执行前会一直尝试连接 根据 DriverManager.setLoginTimeout 设定默认需要10分钟才断开,并报异常.
如果脚本已经开始执行,例如 事务性手动提交的连接 ,已经执行了一个或多个脚本,那么会继续在 connection.setNetworkTimeout 后断开
如果在开始执行事务或脚本的过程及时恢复原有连线, connection没有close,那么执行语句不受影响;
如果在执行事务过程, 原连接断开后,没有commit 就close,那么原执行过语句被丢弃,并抛出close异常;
mysql最大连接数与程序最大连接数的关系?
mysql 的连接数与程序连接池最大连接数无关
但是 所有同时连接到mysql的程序的 ,合计连接数不能大于mysql连接数
- # 查询mysql l\最大连接上限值
- show variables like '%max_connections%';
- #查询mysql 当前最大用户连接数
- show global status like 'Max_used_connections';
- #设置最大连接数上限
- set GLOBAL max_connections=200;
mysql服务器最大连接数值的设置范围比较理想的是:服务器响应的最大连接数值占服务器上限连接数值的比例值在10%以上,如果在10%以下,说明mysql最大连接上限值设置过高;
不要太大 因为MySQL会为每个连接提供连接缓冲区,就会开销越多的内存,所以要适当调整该值,不能盲目提高设值。
连接池的连接池是对程序的连接数的限制,不会改变mysql 连接数**
如何回收连接到连接池?
-
方案: 队列做连接池,用完回收, 问题是异常的连接丢失, 最终连接池大小不可控
-
方案: 数组做连接池, 取连接时需要一个一个确认是否空闲,浪费算力,但是可控
-
方案: 数组做总连接池,队列做可用连接池, 双连接池设计, 不仅提高了效率,也避免了异常连接失控的风险 (目前采用的就是该设计)
应该还有更好的设计思路,欢迎大家给我提建议
connection.setNetworkTimeout 与DriverManager.setLoginTimeout?
connection.setNetworkTimeout 是执行sql的最大时间
DriverManager.setLoginTimeout 是连接到mysql服务器,获取有效链接的最大时间
setAutoCommit() 事务与非事务对连接的影响
很简单的函数,但是带来的一些不小的问题
setAutoCommit(false) 非事务模式
setAutoCommit(true) 事务模式
对batch 影响 :
- 非事务模式: 只有出错的sql无法提交,其他正常的sql 都可以提交
- 事务模式: 一句sql错,所有正常sql都无法提交,且只在batchexecute 是时判断脚本是否异常
对提交的影响
- 事务模式: sql 执行异常后,继续commit()时,不会影响异常前的脚本提交, 但会阻止后续脚本执行;
- 非事务模式: sql 执行异常后,不会影响之前的脚本,也 不会影响后续脚本执行,
对连接的影响
- 事务模式: 如果连接断开, 连接在运行超时后close()
- 非事务模式: 如果连接断开, 连接会阻塞设定时间,或默认的10分钟