Kingbase+sqlsugar 携手助力医疗国产化替换 【人大金仓 .NET ORM】

  • Kingbase+sqlsugar 携手助力医疗国产化替换 【人大金仓 .NET ORM】已关闭评论
  • 20 次浏览
  • A+
所属分类:.NET技术
摘要

 成某三甲医预约系统, 该项目在2024年初进行上线测试,在正常运行了两天后,业务系统报错:The connection pool has been exhausted, either raise MaxPoolSize (currently 800) or Timeout (currently 15 seconds)。金仓开发人员跟进分析,具体排查步骤如下:

 

1. 案例

成某三甲医预约系统, 该项目在2024年初进行上线测试,在正常运行了两天后,业务系统报错:The connection pool has been exhausted, either raise MaxPoolSize (currently 800) or Timeout (currently 15 seconds)。金仓开发人员跟进分析,具体排查步骤如下:

1.1 是否是高并发导致的问题

首先是对业务系统进行了梳理,用户业务系统图如下:

 

Kingbase+sqlsugar 携手助力医疗国产化替换  【人大金仓 .NET ORM】

 

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

1.2 查询服务器端的连接数

金仓数据库系统表:sys_stat_activity中,记录了每个连接的信息,可以通过如下的语句来查询具体业务的连接数:

select state,query from pg_stat_activity where application_name=‘ksql’;

通过加入定时命令,每隔1秒钟都会查询一下对应业务开启的数据库连接数。在业务量最大时,查询到的连接数达到了800个。并且大多数连接的状态为:Idle in transcation,意味着有大量连接开启了事务,但没有任何操作。是因为连接数池上限过小的问题吗?继续将连接池的上限修改,修改为所允许的最大值。结果连接数依旧可以达到连接上限1200。上述现象不符合驱动kdbndp连接池的循环使用机制。这里需要介绍一下金仓驱动kdbndp的连接池机制:

1.2.1 Kdbndp连接池-连接池状态

Kingbase+sqlsugar 携手助力医疗国产化替换  【人大金仓 .NET ORM】

 

连接池有三个计数器:

Idle:空闲连接计数器

Busy:正在使用连接计数器

Waiting:等待获取连接对象计数器

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

 

Kingbase+sqlsugar 携手助力医疗国产化替换  【人大金仓 .NET ORM】

 

 

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

 

Kingbase+sqlsugar 携手助力医疗国产化替换  【人大金仓 .NET ORM】

 

 

 

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

 

Kingbase+sqlsugar 携手助力医疗国产化替换  【人大金仓 .NET ORM】

 

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

 

Kingbase+sqlsugar 携手助力医疗国产化替换  【人大金仓 .NET ORM】

 

1.2.6 连接池满-处理流程

 

Kingbase+sqlsugar 携手助力医疗国产化替换  【人大金仓 .NET ORM】

 

1.2.7 连接池参数介绍

Pooling:

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

Minimum Pool Size

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

Maximum Pool Size

连接池可以创建连接额最大数,默认值:100

Connection Idle Lifetime

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

Connection Pruning Interval

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

从连接池设计的机制来看,一般连接使用结束之后,是释放回到连接池中;而现场问题中存在大量创建物理连接,将连接池撑爆的现象存在。而且大量物理连接的状态为:Idle in transcation,至此,我们找到了导致连接池爆池的原因。

1.3 分析Idle in transcation

Idle in transcation:当数据连接处于“Idle in transcation”状态时,意味着连接已经开启了事物,但没有任何操作(如提交或回滚)来结束这个事务。我们将KingbaseES+sugar框架的结构图梳理出来,进一步的定位问题,结果图如下:

 

Kingbase+sqlsugar 携手助力医疗国产化替换  【人大金仓 .NET ORM】

 

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

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

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

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

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

上述流程中,步骤二中,创建单例模式的访问对象,这个引起了sugar开发人员和金仓开发人员的关注。在SqlSugar创建单例模式时,整个的创建使用流程如下:

 

在创建单实例模式中,开始了事务,在使用结束之后,需要提交事务,使用commit接口CommitTran(),提交事务,释放Kdbndp连接对象;如果只是将sqlsugar单实例的对象释放,不使用提交事务接口完成释放的话,KdbndpConnection连接不会被释放,这样就导致了数据库中连接处于:Idle in transcation的现象;再次调用创建单实例模式对象,采用同样的流程,连接数开始逐渐的累加起来,直到出现爆池的错误。

分析之后,梳理用户的业务代码,果然是在开启事物之后,调用完成退出时没有做commit操作,导致Kdbndp连接无法回到连接池,无法循环使用连接池中连接而导致爆池。

调整业务代码,在释放sqlsugar单实例对象时,做事务提交退出操作。修改之后,连接池中的物理连接保持在20个左右,不再出现爆池的错误。循环使用连接池的连接,导致服务器端相关资源消耗下降至原来的1/60。每次任务的提交速度提升了200ms。

现场问题解决了,此过程中,了解了kingbase+sugar的一些基础,在进一步使用中您会发现,

如何避免问题总结

错误代码

db.BeginTran();  //海量代码  if (逻辑)   {       return;//导致事务没有提交,写return很容易漏写 db.RollbackTran();  }  //海量代码 db.CommitTran();  

  

正确写法

        try         {             db.BeginTran();             if (逻辑)             {                 throw new Exception("出错");             }             db.CommitTran();//保证所有出错都进RollbackTran         }         catch (Exception)         {                          db.RollbackTran();         }

SqlSugar和人大金仓优点:

1、 功能更新的及时性,因为两家公司深入合作,彼此产品有新功能的推出,能在第一时间互相沟通,及时发布;

2、 屏蔽差异化,采用该方案,可以在金仓的多个模式(pg、oracle、mysql)上开发,不用关注模式会带来额外的配置;

3、 开发的高效性,采用ORM框架,缩短了开发周期,屏蔽了差异化,业务迁移和开发的成本都会降低;

4、 实时的技术支持,以在多个项目中得到验证,双方的高效合作,为用户的定制开发、问题定位提供及时的技术支持。