一种基于排队论的高效数据库连接池的设计

2010-05-05王宇杰杨文宾

微型电脑应用 2010年6期

关键词：监视器管理器等待时间

王宇杰，杨文宾

0 引言

在数据库的访问中，采用连接池技术在并发性能的处理上以及用户时延的等待上都有很大优势。但通用的连接池具有效率低、缺乏监控的缺点。本文在连接池的设计中，应用排队论的理论，建立了一个访问服务模型，用以优化连接池的服务质量。

文中设计连接池模型具有一定的通用性，可以用在对各种数据库的连接应用中。

1 连接池模块的结构设计

连接池在总体上包括四个部分：连接池、管理器、监视器和配置文件。如图1所示。

图1 连接池模块总体结构

1.1 连接池

连接池是存放具体连接实例的地方，需要注意的是，每个连接池对应着一种连接方式，比如对同一个数据库，不同的数据库用户所建立的连接就要放在不同的连接池中（因为连接参数不一样）。一个连接池中可以存放若干个连接实例。每个实例对应一个编号和一些使用属性，如已经被使用的次数，被创建的时间，上一次被使用的时间等。通过这些信息，就可以对这个实例进行管理（分配、回收和销毁等）以及由此获得系统的某些性能参数。每个连接池也设置一些参数，或者用于记录整个连接池的被使用情况，或者用来控制连接池的某些行为。连接池可以被设计成一个类，主要存放有一些有关连接池状态的信息，也可以自主地对存储在其内的连接实例进行管理（生成、销毁和维护等）。

1.2 管理器

管理器是对连接池进行管理的部分。一个管理器可以管理若干个连接池，负责每个连接池的生成和销毁。管理器从配置文件中获得静态的配置信息，如：可以管理的连接池的列表，每个连接池的连接信息，每个连接池的最大连接数或总体的最大连接数，建立连接时最大的等待时间等。用这些信息生成各个连接池，在系统停止时管理器还负责销毁各个连接池（回收资源）。

由于各个连接池都由管理器统一管理，所以管理器也为应用程序提供连接池的使用接口，所有应用程序都通过管理器的接口来获得合适的连接实例以及释放（连接池回收）一个连接实例。

1.3 监视器

监视器是一个后台运行的守候进程（或线程），本质上是一种对连接池进行优化的计算程序。它以一定频率扫描连接池的被访问频率和连接操作反应速度的统计信息，并以此为依据，计算最优的连接池参数，供连接池使用。访问的统计信息反应了用户的访问情况，连接操作的统计信息访问了服务器的当前状态（负荷、性能等），再通过一定的排队论模型计算，就可以大致确定连接池适应当前状况的最优状态，从而动态的对连接池进行调整，提高服务质量（QoS）。

监视器是与连接池相对应的，每个连接池实例对应一个监视器实例，这个监视器实例在与之对应的连接池实例被创建的时候启动，之后就不停地监视和调整连接池实例的状态。因为应用程序对连接池的访问就是个排队论的问题，所以监视器的算法以排队论为理论基础，通过建立一个合适的排队模型进行优化计算。

1.4 配置文件

配置文件是存放连接池的静态参数的地方，比如可管理的连接池名称列表，每个连接池建立连接所用的用户名，密码，服务器地址，数据库名称，连接驱动程序名称等。这些数据都是关于连接池全局的数据，都是在管理器每次启动时，一次性装入，此后便不再对连接池产生任何作用。

2 连接池的管理器

2.1 连接池管理器的设计

连接池管理器有两个主要作用：一是按照配置文件中的配置信息建立和销毁连接池。一是按照应用程序的要求，向相应的连接池实例请求可用的连接实例或回收一个连接实例，即要实现取得和回收连接实例的接口。

连接池的设计主要有3点考虑：

1.管理器在设计上需要注意的就是它只能生成一个实例，换句话说，第一个管理器实例生成后，要能禁止第二个管理器实例的生成，保证所有的连接池统一管理。

2.应用程序在请求获释放连接时，仅仅指出连接池的名称，即可通过管理器提供的接口获得或释放一个连接实例。管理器内部依据这个名字，向其所管理的某个连接池申请连接实例并返回给应用程序，或者回收这个连接实例。这个过程对应用程序透明。

3.管理器在实现这个接口时，还要注意多个进程（线程）使用接口时所造成的同步问题；一方面，我们希望提高程序的并行程度，即在同一时间内允许有多个应用访问管理器，以此来提高系统的运行效率；另一方面，还要严格注意到并行过程中不适当的代码可能造成的混乱。所以，对管理器的设计我们力求避免实现繁琐而又不甚必要的功能。

2.2 连接池的设计

2.2.1 连接池的主要功能

（1）要能生成、维护和销毁所管理的连接实例；

（2）要能迅速地对管理的连接实例进行检索，返回给应用程序（通过管理器），或从管理器回收一个连接实例；

（3）要维护各个连接实例的相关信息，以便于实现对连接实例和连接池的维护；

（4）要能及时地为监视器提供有用的统计信息以供监视器进行优化计算。

2.2.2 连接池中的数据组织

在实际设计中，一个连接池主要包括如下一些重要数据组织：

（1）链表cons，我们把空闲的连接实例放入这个链表中，因为对连接实例的操作主要是取得（不需检索）、加入和删除等修改性操作，采用链表结构最为适合。

（2）哈希表infos，我们把连接实例的相关信息放入一个哈希表中，每个连接实例的相关信息包括实例创建时间，实例被使用的次数，实例上次被调用的时间。因为对连接实例相关信息的查询操作比较频繁，不同于连接实例本身，所以，把相关信息和连接实例本身分开存储；哈希表比较适合于查询，所以就把连接实例信息放在哈希表中。

（3）还设有两个变量专门用于统计系统的被访频率和系统当前的反应速度uCount和yCount，连接池会根据实际情况不断地把一些信息计入这两个变量，监视器也会不断地访问这两个变量，以进行优化计算。

（4）其他比较重要的参数就是连接池内最大的连接实例数n，连接池内等待连接的请求队列的最大长度（m-n），这两个参数对连接池的性能有较大的影响，监视器会根据计算结果不断调整n和m的值，以期连接池的性能最优。

此外还有一些不太重要的参数，如连接实例的最大生存时间，最大使用次数，最长等待时间，已经生成的所有连接数（包括正在被使用和空闲状态中的连接实例）等等。

2.2.3 连接池向外提供的接口

连接池主要向外提供两个接口：获取连接getConnection（），即是从连接池取得一个可用的连接实例；释放连接freeConnection（），即是将一个用完的连接实例放回连接池。这两个接口都需要调用者提供一个连接池名称作为参数。

2.2.4 连接池的运行流程

考虑到一个连接实例在多次使用之后，或在经过较长一段时间之后会逐渐的变得不稳定（由于底层的原因），所以，在回收连接实例时，连接池要检查连接实例的生成时间和使用次数，当超过相应的标准时，就把这个连接实例销毁，同时删除对应的使用记录。

一个连接池的运行流程分析如下。

（1）管理器应应用程序的请求，调用连接池的获取连接接口getConnection（）。连接池首先把这个请求的有关信息记录到yCount中去，然后，看空闲连接链表cons中有没有可用的连接实例，如果有，到哈希表infos中修改这个连接实例的相关信息，并返回这个连接实例给管理器；如果空闲链表已经空了，则查看所有连接数是否达到最大值n，如果没有达到，则生成一个新的连接实例，把相关信息计入哈希表infos，并返回这个新的连接实例给管理器；如果已经达到最大值，则看等待队列有没有排满，若没满，则把这个请求放入等待队列，若已满，返回出错信息给管理器，报告没有取道连接。放入等待队列的请求也有一个最大的等待时间，如果在这个时间内，没有获得可用连接，则也要返回出错信息给管理器。如果我们还要对请求失败率进行统计的话，在合适的地方，还要对相关信息进行记录。

（2）管理器应应用程序的请求，调用连接池的释放连接接口freeConnection（）。连接池首先从哈希表infos中取出这个连接实例的相关信息，并把相关信息记录到uCount中去，然后检查这个连接实例的生存时间和使用次数是否超过要求，如果已经超过，关闭这个连接，删除相关信息，所有连接数减1。如果没有超过，则把这个连接实例放入空闲链表cons，相关信息中使用次数加1，然后通知等待队列，已经有空闲连接实例回收。

（3）连接池实例一旦生成，即启动一个监视器实例monitor，这个监视器以后台守护进程或线程的方式运行，经过一段间隔，就查询连接池中的统计信息yCount和uCount，并进行一次优化计算，并根据计算结果，调整连接池中的m和n值。在销毁连接池之前，要停止监视器最后销毁掉。

连接池的运行流程如图2所示，实际上包括两个独立的过程：

（a）应用程序向连接池申请一个连接的过程;

（b）应用程序向连接池释放一个连接的过程;

图2 连接池处理流程

2.3 监视器算法设计

2.3.1 监视器算法

监视器的作用就在于，按照一定的指标，通过模型计算，得到合适的连接池参数。优化的目标主要有两个：一个是尽量提高系统的通过能力，即是要使绝对通过量保持不低于某一个值（与系统能力有关）；一个是尽量减小对每个用户的服务时间，不能让用户等待的太久。

这两个指标在有些时候是矛盾的，假设系统资源已经达到极限，为了提高系统通过率，可以增加每个连接池内的连接数，使更多到达的请求不被马上拒绝，但这样肯定会增大整个系统的开销，使得等待队列中的请求等待的时间延长。反之，如果想让每个以获得连接的用户花费时间短，就不能在连接池内创建太多的连接，以节省系统资源，从而降低了系统的通过率。

所以，必须分情况采用不同的优化策略，权衡两个因素，以期达到最佳效果。在平均的请求速度低于平均的响应速度时，说明系统是可以胜任当前任务的，所以应该尽量保证系统通过率，适当地增加连接实例以及加长等待队列的长度，使一些局部密集到达的请求不至于被马上拒绝掉。在平均的请求速度高于平均的响应速度时，说明系统是已经不可以胜任当前任务了，一些请求被拒绝是必然的，这时，就应该保证每个用户的响应时间，在此基础上，尽量提高系统通过量，所以就要限制连接池内连接实例数目和等待队列的长度，适当拒绝对某些申请的响应。

从而得到如下的优化算法：

Λ：为单位时间内平均到达的请求数量；

μ：为单位时间内每个连接实例所能处理的请求数；

n：为连接池内所有的连接实例数目；

m：等待队列长度；

timeout:用户最大等待时间；

（1）使用当前的λ、µ、m和n值，比较nµ和λ，如果nµ＞λ说明系统目前设置基本上能够胜任当前任务，仅仅需要微调，进入第二步计算。

（2）计算用户等待时间，如果计算结果已经大于timeout，则适当增加m值重复计算，但m值不要大于2n，如果在某一个时刻，计算结果小于timeout了，计算完成，本轮计算结束。当增加到m=2n时，若还没有使计算结果小于timeout，此时m值的增加对计算结果的影响已经很小，说明不能靠调整m值来缩短响应时间了，转入第四步。如果计算结果小于timeout，转入第三步。

（3）减小m值，值到计算的等待时间刚好小于timeout，本轮计算完成。如果一直到m=n尚不能使等待时间刚好小于timeout，转入第四步。

（4）n值减1，本轮计算完成，等待下一轮计算。

（5）使用当前的λ、μ、m和n值，比较nμ和λ，如果nμ＜λ说明系统目前设置不能够胜任当前任务，需要大的调整，转入第六步。

（6）检查以前记录的μ和n值，其乘积与当前值乘积进行比较，如果当前值较大且n+1值有效，说明系统尚有空余利用空间，记录下当前μ和n值存储起来，n值加1，本轮计算完成，等待下一轮计算。如果当前值较小，转入第七步计算。如果n+1值无效，同样转入第七步计算进行微调。

（7）此时系统资源的利用到达极限，且还不能满足当前任务，使一部分的用户请求被拒绝已经无法避免，所能做的就是保证连接用户的等待时间在规定的等待时间内，同时，尽可能提高系统通过率。计算方法是计算等待时间是否小于规定时间，如果是，逐步增加m值，直到一个临界值（并且m＜2n），如果不是，逐步减小m值，直到一个临界值；如果一直到m=n尚不能满足要求，说明通过调整等待队列长度不能完成用户等待时间的调整，从而转入第八步计算。

（8）做一个标记，表示当前n值无效，n值减1，进入下一轮计算。

优化算法的流程可参考图3，其中的具体算法参考排队论理论。

图3 监视器算法流程图

可以看出，因为n值的调整会对系统有较大的影响，所以一般n值变化后要等到下一轮实测结果出来再做进一步决定（此时的实测结果可能会较现状有较大的变化），调整周期要长；而m值的调整对系统影响较小，可以用过迭代计算在一轮内算得出，调整周期要短的多。调整n值时伴随着连接实例的建立和销毁，是个很费资源的工作，但m值的调整则没有这么大的影响，而且m值的调整也能在小范围内对系统指标产生影响，所以在一定程度上避免了由于任务变化剧烈所带来n值的频繁变化，为n值的调整起到了一定的缓冲作用，实际上，也就是在一定程度上避免了系统频繁生成和销毁连接实例所出现的“颠簸”现象。

由于排队论计算中，算法比较繁琐，不好由要求的指标变量反求得到输入变量，所以，在计算中采用了所谓“愿望模型”的试算方法，即逐次给出不同的输入变量得到不同的指标变量，再依据得到的指标变量，从中选择一个合适的输入作为计算结果。对m和n值的计算本质上都是这样的。

2.3.2 优化计算时用到的主要公式及其推导过程（已知n，m，µ，λ的值）

（1）计算系统损失率：

（2）系统绝对通过能力：A=λ*Pm

（3）平均服务时间：

由：