探案录 | KingbaseES+SqlSugar为医疗用户排忧解难

在2024年的初春，某大型三甲医院的CT预约系统上线测试，如同新芽破土，充满了希望与活力。然而，仅仅两天后，一个技术难题如同迷雾中的幽灵，悄然出现：The connection pool has been exhausted……

福尔摩斯K，如同猎犬般敏锐，迅速投入了这场技术探案。

 #第一章：迷雾初现 

“华生，我们必须首先排除高并发的可能性。”福尔摩斯K开始对业务系统进行梳理。

他发现，错误是业务系统报出的，业务系统处理第三方消息平台发送的请求，第三方消息平台收集签到机和其它设备发送的请求。业务系统高峰期时，同时请求的请求可以达到10条左右。并发量并不大，排除并发量导致的连接池爆池。

​

#第二章：数字的线索 

福尔摩斯K转而查询K家族自主研发的KingbaseES系统表sys_stat_activity，记录了每个连接的信息。

他发现，KingbaseES通过精心设计的查询语句，每隔一秒，如同钟表的滴答声，记录下了对应业务的数据库连接数。在业务量最大时，连接数竟达到了800个，大多数连接状态为“Idle in transaction”，如同悬而未决的谜团。

#第三章：连接池的秘密 

之后，福尔摩斯K对KingbaseES驱动的kdbndp连接池机制进行了深入的分析。

在他看来，连接池的三个计数器——空闲连接计数器Idle、正在使用连接计数器Busy和等待获取连接对象计数器Waiting——如同三重奏，共同维持着连接池的和谐。

然而，现场问题中存在大量创建物理连接的现象，将连接池撑爆，这与连接池的设计机制不符，也许这就是破案的关键。

01

连接池中无连接-申请连接流程

02

连接池已经存在连接-申请连接流程

03

连接池释放连接—应用退出

04

连接池释放连接—连接空闲达到设置时间(默认5分钟)

05

连接池满-处理流程

06

连接池参数介绍

Pooling

是否开启连接池，true：开发连接池，false:关闭连接池，默认值：true

Minimum Pool Size

连接池保持最小连接数,默认值：0

Maximum Pool Size

连接池可以创建连接额最大数，默认值：100

Connection Idle Lifetime

空闲连接空闲时间达到的时间值，到达该时间值时，可以回收该连接，默认值：300(秒)

Connection Pruning Interval

空闲连接回收之前等待时间，默认值：10(秒)

分析后得知，从连接池设计的机制来看，一般连接使用结束之后，是释放回到连接池中；而现场问题中存在大量创建物理连接，将连接池撑爆的现象存在。

大量物理连接的状态为：

Idle in transcation

至此，福尔摩斯K找到了导致连接池爆池的原因。

#第四章：事务的幽灵

“华生，我们需要关注这些‘Idle in transaction’的连接。”福尔摩斯K认为，当数据连接处于此状态时，意味着连接已经开启了事务，但没有任何操作来结束这个事务。

他们进一步梳理了KingbaseES+SqlSugar框架的结构图，试图定位问题。

KingbaseES+SqlSugar

业务流程访问数据库的数据经过了如下步骤：

1> 定义实体数据模型，实体模型模型是编写程序的依据；

2>业务系统调用SqlSugar接口，创建对象时，业务代码编写人员可以指定使用SqlSugar的模式，推荐使用的是单例模式SqlSugarScope，该模式是线程安全的。在创建对象的时候，通过DbType指定访问的数据库是哪一家的。Kdbndp中有一个参数DbModeType，指定使用哪种数据库模式，两者有异曲同工之妙；这个时候，我们也指定了我们访问的数据库，访问数据库使用的连接参数等信息；

3>还是调用SqlSugar接口，SqlSugar会将对应接口的操作，映射、翻译为对应的sql语句，调用Kdbndp的执行接口，将语句发送到服务器端；

4>服务器端执行之后，执行结果又通过Kdbndp的功能接口，回到SqlSugar,根据映射关系，将结果存放至模型对象中，业务系统通过获取模型对象中的数据，完成业务数据展示的处理流程。

上述流程步骤二中，创建单例模式的访问对象，引起了福尔摩斯K和华生的关注。福尔摩斯K对华生说：“我觉得我们需要梳理一下SqlSugar创建单例模式时，整个的创建使用流程。”

华生立刻给出了流程图：

K家族

不一般

#第五章：单例模式的陷阱 

在SqlSugar创建单例模式的过程中，福尔摩斯K发现了关键的线索。果然是在开启事物之后，调用完成退出时没有做commit操作，导致Kdbndp连接无法回到连接池，无法循环使用连接池中连接而导致爆池。

#第六章：迷雾散去 

福尔摩斯k说：“调用BeginTran()，完成业务逻辑退出时，必须调用CommitTran()来完成连接的释放。”用户在完成业务逻辑退出时，调用了CommitTran()。

经过调整，连接池中的物理连接保持在20个左右，爆池的错误不再出现。服务器端相关资源消耗大幅下降，每次任务的提交速度显著提升。这场技术探案，如同解开了一道复杂的密码，终于迎来了曙光。

#第七章：搭子的力量 

案件水落石出后，华生发现了KingbaseES+SqlSugar的方案在实际业务中有不少优点，比如说：

1

屏蔽数据库模式的差异，业务根本不用关心我连接的是金仓的什么数据库模式，因为驱动和框架已经做了屏蔽了差异，让业务编写更容易迁移；

2

业务开发和迁移的高效性，驱动和框架做了兼容开发，只是通过连接串的不同，就能实现不同数据库之间的业务迁移，太方便了；

3

实时的技术支持，可以快速定位问题，并解决问题。

福尔摩斯k点点头，表示认可，并补充到：“你忘了说KingbaseES较为全面的兼容能力，目前兼容了PostgreSQL、Oracle、MySQL、SQL Server等数据库的核心功能。这在业界是极具独创性的。”

这一次

福尔摩斯K更接近K家族的核心技术了

欢迎大家持续关注

揭开K家族的神秘面纱

供稿：产品研发中心、战略市场部

编辑：王堇

审核：日尧