基于服务池的资源管控方法、装置和系统与流程

本申请涉及互联网领域，尤其涉及一种基于服务池的资源管控方法、装置和系统。

背景技术：

随着互联网高速发展，互联网用户规模也呈现爆发式增长，大型门户网站或应用程序(app)，每天都会有数以万计或数以亿计的访问。而支撑用户访问，不仅需要软件服务，还需要耗费大量的硬件资源。

在现有技术中，服务器集群可以任意扩缩容，但是服务器所连接的数据资源却无法自动扩缩容。由于承载数据资源的数据库所能承载的连接数有限，存在最大连接数限制，当用户访问量超出预期地暴增时，配置的硬件资源会无法满足访问量需求，由此会导致数据资源瓶颈。

由此可见，目前亟需一种基于服务池的资源管控方法，以解决现有技术中的数据资源瓶颈问题。

技术实现要素：

本申请实施例提供了一种基于服务池的资源管控方法、装置和系统，用以解决现有技术中的资源瓶颈问题。

本申请实施例采用下述技术方案：

第一方面，提供一种基于服务池的资源管控方法，所述服务池包括至少一组目标应用客户端，所述资源管控方法包括：接收所述服务池中的至少一组目标应用客户端发送的目标消息，其中，所述目标应用客户端为使用目标资源的客户端，所述目标消息包括所述目标应用客户端与所述目标资源之间的连接数；基于所述至少一组目标应用客户端中每一个目标应用客户端与所述目标资源之间的连接数，确定所述目标资源的占用连接数；在所述目标资源的所述占用连接数达到所述目标资源的连接数阈值的情况下，对所述目标资源进行管控。

第二方面，提供一种基于服务池的资源管控方法，所述资源管控方法包括：确定客户端与目标资源之间的连接数，其中，所述客户端为使用目标资源的客户端；向服务器发送目标消息，所述目标消息包括所述客户端与所述目标资源之间的连接数，使得所述服务器基于服务池中至少一组所述使用目标资源的客户端与所述目标资源之间的连接数，确定所述目标资源的占用连接数，并在所述目标资源的所述占用连接数达到所述目标资源的连接数阈值的情况下，对所述目标资源进行管控。

第三方面，提供一种基于服务池的资源管控装置，所述服务池包括至少一组目标应用客户端，所述资源管控装置包括：

接收模块，用于接收所述服务池中的至少一组目标应用客户端发送的目标消息，其中，所述目标应用客户端为使用目标资源的客户端，所述目标消息包括所述目标应用客户端与所述目标资源之间的连接数；

确定模块，用于基于所述至少一组目标应用客户端中每一个目标应用客户端与所述目标资源之间的连接数，确定所述目标资源的占用连接数；

管控模块，用于在所述目标资源的所述占用连接数达到所述目标资源的连接数阈值的情况下，对所述目标资源进行管控。

第四方面，提供一种基于服务池的资源管控装置，所述资源管控装置包括：

确定模块，用于确定客户端与目标资源之间的连接数，其中，所述客户端为使用目标资源的客户端；

发送模块，用于向服务器发送目标消息，所述目标消息包括所述客户端与所述目标资源之间的连接数，使得所述服务器基于服务池中至少一组所述使用目标资源的客户端与所述目标资源之间的连接数，确定所述目标资源的占用连接数，并在所述目标资源的所述占用连接数达到所述目标资源的连接数阈值的情况下，对所述目标资源进行管控。

第五方面，提供一种基于服务池的资源管控系统，所述资源管控系统包括第三方面所提及的资源管控装置和第四方面所提及的资源管控装置。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

在本申请实施例中，接收至少一组目标应用客户端发送的目标消息，其中，所述目标应用客户端为使用目标资源的客户端，所述目标消息包括所述目标应用客户端与所述目标资源之间的连接数；基于所述目标应用客户端中每一个目标应用客户端与所述目标资源之间的连接数，确定所述目标资源的占用连接数；在所述目标资源的所述占用连接数达到所述目标资源的连接数阈值的情况下，对所述目标资源进行管控。如此，通过基于服务池的资源管控方法，可以根据目标资源的占用连接数以及目标资源的连接数阈值的关系，及时对目标资源进行动态管控，如此，可以在较大程度上解决现有技术中的资源瓶颈问题。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种基于服务池的资源管控方法的流程图；

图2是本申请实施例提供的服务池的示意图；

图3是本申请实施例提供的一种基于服务池的资源管控方法的流程图；

图4是本申请实施例提供的一种基于服务池的资源管控方法的流程图；

图5是本申请实施例提供的一种基于服务池的资源管控方法的流程图；

图6是本申请实施例提供的一种基于服务池的资源管控方法的流程图；

图7是本申请实施例提供的一种基于服务池的资源管控方法的示意图；

图8是本申请实施例提供的一种基于服务池的资源管控方法的示意图；

图9是本申请实施例提供的一种基于服务池的资源管控方法的示意图；

图10是本申请实施例提供的一种基于服务池的资源管控方法的示意图；

图11是本申请实施例提供的一种管控数据资源的装置的结构框图；

图12是本申请实施例提供的一种管控数据资源的装置的结构框图。

具体实施方式

本申请实施例提供一种基于服务池的资源管控方法、装置和系统。

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

图1是本申请实施例提供的一种基于服务池的资源管控方法的流程图。

本申请实施例提供的一种基于服务池的资源管控方法，所述服务池包括至少一组目标应用客户端。

图2是本申请实施例提供的服务池的示意图。

在本申请实施例中，参见图2，所述服务池1可以是由多台机器2组成的机器集群，可以理解的是，所述机器集群可以将多台机器集中起来一起提供服务。机器2可以为应用客户端的承载方。可以理解的是，服务池1可以包括包括至少一组目标应用客户端。

其中，所述服务池1可以包括至少一组目标应用客户端，可以理解的是，服务池1内的多台机器2，均可以为应用客户端提供服务。服务池内的一台机器可以同时为多个应用客户端提供服务。服务池中的多个目标应用客户端3就组成了至少一组目标应用客户端。

如图1所示，所述资源管控方法可以包括：步骤11、步骤12、步骤13。下面针对步骤11、步骤12、步骤13依次进行阐释。

步骤11：接收所述服务池中的至少一组目标应用客户端发送的目标消息，其中，所述目标应用客户端为使用目标资源的客户端，所述目标消息包括所述目标应用客户端与所述目标资源之间的连接数。

其中，所述至少一组目标应用客户端发送的目标消息中，目标消息的接收方可以是管理所述服务池的管理系统或服务器等等，目标消息的实际接收方并不构成对本申请的限定。

其中，所述目标资源可以是存储于mysql(关系型数据库管理系统)中的数据，也可以是存储于redis(remotedictionaryserver，key-value存储系统)中的数据。可以理解的是，mysql是关系型数据库，主要用于存放持久化数据，将数据存储在硬盘中。redis数据库是缓存数据库，用于存储使用频繁的数据。mysql和redis因为需求的不同，通常需要配合使用。因此，本申请中所述目标资源既可以是存储于mysql中的数据，也可以是存储于redis中的数据。

可以理解的是，服务池中的机器为应用客户端提供服务时，需要调用资源。类似地，目标应用客户端需要先连接所述目标资源，才能进行调用。即所述目标应用客户端与所述目标资源之间由于建立了连接关系，目标应用客户端与目标资源之间连接的具体数量即为所述目标应用客户端与所述目标资源之间的连接数。

步骤12：基于所述至少一组目标应用客户端中每一个目标应用客户端与所述目标资源之间的连接数，确定所述目标资源的占用连接数。

可以理解的是，从目标资源的角度考虑，目标消息的接收方可以确定有多少目标应用客户端与目标资源本身连接，即可确定该目标资源的占用连接数。

步骤13：在所述目标资源的所述占用连接数达到所述目标资源的连接数阈值的情况下，对所述目标资源进行管控。

可以理解的是，所述目标资源是存在所能承载的最大连接数目限制的，所述目标资源的连接数阈值可以是所述目标资源的最大连接数，也可以是目标资源的最大连接数的预设比例，例如，目标资源的最大连接数的80％、目标资源的最大连接数的75％、目标资源的最大连接数的70％、目标资源的最大连接数的65％、目标资源的最大连接数的60％等。例如，如果某目标资源的最大连接数是3000，则目标资源的连接数阈值可以为3000。当然，优选地，连接数阈值也可以是目标资源的最大连接数的预设百分比，例如最大连接数的80％，此时，连接数阈值为2400。当目标资源的占用连接数达到2400时，所述目标资源的所述占用连接数已经达到所述目标资源的连接数阈值，则需要对所述目标资源进行管控。

其中，所述对所述目标资源进行管控可以包括，拒绝除了已连接所述目标资源的目标应用客户端之外的其他目标应用客户端连接所述目标资源，并输出警报。

可以理解的是，所述目标资源的所述占用连接数已经达到所述目标资源的连接数阈值时，所述目标资源的连接数已经告急，再增加新的连接会导致所述目标资源连接数超限，因此可以通过禁止新的目标应用客户端连接所述目标资源，即停止除了已连接所述目标资源的目标应用客户端之外的其他目标应用客户端连接所述目标资源，并输出警报。其中所述输出警报可以是发送警报邮件等等。

可以理解的是，所述目标资源的所述占用连接数已经达到所述目标资源的连接数阈值时，所述目标资源的连接数已经告急，也可以通过输出警报，增大所述目标资源的数量，以防止所述目标资源连接数超限。

如此，通过本申请提供的一种基于服务池的资源管控方法，可以实时根据用户的访问量，得到目标资源的实时使用情况，从而可以对目标资源进行动态管控，进一步有效解决了现有技术中，由于无法实现对资源的动态管控，所造成的目标资源的使用瓶颈问题。

在本申请实施例中，可参见图3，上述步骤11还可以包括步骤31，相应的上述步骤12还可以包括步骤32，下面依次对步骤31、步骤32、步骤33进行阐述。

步骤31：接收所述服务池中的一组目标应用客户端发送的目标消息，该组目标应用客户端包括属于相同类别的多个目标应用客户端。

其中，目标消息的接收方可以是管理所述服务池的管理系统或服务器等等，目标消息的实际接收方并不构成对本申请的限定。

其中，所述目标资源可以是存储于mysql(关系型数据库管理系统)中的数据，也可以是存储于redis(remotedictionaryserver，key-value存储系统)中的数据。可以理解的是，mysql是关系型数据库，主要用于存放持久化数据，将数据存储在硬盘中。redis数据库是缓存数据库，用于存储使用频繁的数据。mysql和redis因为需求的不同，通常需要配合使用。因此，本申请中所述目标资源既可以是存储于mysql中的数据，也可以是存储于redis中的数据。

可以理解的是，参见图7-8，图7-8只是示例性的画出第一目标应用客户端31、第二目标应用客户端32、第三目标应用客户端33、第四目标应用客户端34、第五目标应用客户端35、第六目标应用客户端36。在图7中，上述目标应用客户端31-36均可以与目标资源41-44连接，图7-8只是示意性的画出了部分连接关系，目标应用客户端31-36与目标资源41-44的实际连接关系并不构成对本申请的限定。图7示意性的描述了第一服务池11和第二服务池12。第一服务池11和第二服务池12中的多台机器2可以同时为目标应用客户端提供服务。

参见图7，在第一服务池11和第二服务池12中部署了多台机器2，示例性的标出了第一机器21、第二机器22、第三机器23、第四机器24、第五机器25、第六机器26，上述机器可以同时为目标应用客户端31-36提供服务，所述机器可以为服务器。

可以理解的是，接收所述服务池中的一组目标应用客户端发送的目标消息，该组目标应用客户端包括属于相同类别的多个目标应用客户端。例如，一组第一目标应用客户端31可以包括第一机器21中的第一目标应用客户端31、第二机器22中的第一目标应用客户端31、第三机器23中的第一目标应用客户端31......。每台机器中的第一目标应用客户端31共同组成一组第一目标应用客户端31。

步骤32：将该组目标应用客户端中的每一个目标应用客户端与所述目标资源之间的连接数之和，确定为所述目标资源的占用连接数。

可以理解的是，参见图7，所述目标资源可以是第一目标资源41、第二目标资源42、第三目标资源43、第四目标资源44。

可以理解的是，该组目标应用客户端中的每一个目标应用客户端与所述目标资源之间的连接数之和，确定为所述目标资源的占用连接数。举例而言，若只有一组第一目标应用客户端31与目标资源连接，则可以将该组目标应用客户端中的每一个目标应用客户端与所述目标资源之间的连接数之和，确定为所述目标资源的占用连接数。

步骤33：在所述目标资源的所述占用连接数达到所述目标资源的连接数阈值的情况下，对所述目标资源进行管控。

可以理解的是，所述目标资源是存在所能承载的最大连接数目限制的，所述目标资源的连接数阈值可以是所述目标资源的最大连接数。所述目标资源的连接数阈值可以是所述目标资源的最大连接数目的预设百分比。例如，某目标资源的最大连接数可以是3000，连接数阈值可以是3000的80％(或者70％、60％等)。当占用连接数为2400时，所述目标资源的所述占用连接数已经达到所述目标资源的连接数阈值，则需要对所述目标资源进行管控。

其中，所述对所述目标资源进行管控可以包括，拒绝除了已连接所述目标资源的目标应用客户端之外的其他目标应用客户端连接所述目标资源，并输出警报。

可以理解的是，所述目标资源的所述占用连接数已经达到所述目标资源的连接数阈值时，所述目标资源的连接数已经告急，再增加新的连接会导致所述目标资源连接数超限，因此可以通过拒绝新的目标应用客户端连接所述目标资源，即拒绝除了已连接所述目标资源的目标应用客户端之外的其他目标应用客户端连接所述目标资源，并输出警报。其中所述输出警报可以是发送警报邮件等等。

可以理解的是，所述目标资源的所述占用连接数已经达到所述目标资源的连接数阈值时，所述目标资源的连接数已经告急，也可以通过输出警报，增大所述目标资源的数量，以防止所述目标资源连接数超限。

如此，通过本申请提供的一种基于服务池的资源管控方法，可以实时根据用户的访问量，得到目标资源的实时使用情况，从而可以对目标资源进行动态管控，进一步有效解决了现有技术中，由于无法实现对资源的动态管控，所造成的目标资源的使用瓶颈问题。

在本申请实施例中，可参见图4，一组目标应用客户端可以指示一类应用客户端，且每一类应用客户端可以包括至少一个目标应用客户端，有多组目标应用客户端时，那么上述步骤11还可以包括步骤41，相应的上述步骤12还可以包括步骤42，下面依次对步骤41、步骤42、步骤43进行阐述。

可以理解的是，参见图8，在第一服务池11和第二服务池12中部署了多台机器2，示例性的标出了第一机器21、第二机器22、第三机器23、第四机器24、第五机器25、第六机器26，上述机器可以同时为目标应用客户端31-36提供服务。

可以理解的是，每一组目标应用客户端指示一类目标应用客户端，且每一类目标应用客户端包括至少一个目标应用客户端，参见图8，一组第一目标应用客户端31可以指示一类目标应用客户端。例如，一组第三目标应用客户端33可以指示第一机器21中的第三目标应用客户端33、第二机器22中的第三目标应用客户端33、第三机器23中的第三目标应用客户端33......。每台机器中的第三目标应用客户端33共同组成一组目标应用客户端33。

步骤41：接收所述服务池中的多组目标应用客户端发送的目标消息；

其中，每一组目标应用客户端指示一类目标应用客户端，且每一类目标应用客户端包括至少一个目标应用客户端。

可以理解的是，参见图8，图8示意性的描述了第一服务池11和第二服务池12。第一服务池11和第二服务池12中的多台机器2可以同时为目标应用客户端提供服务。

可以理解的是，每一组目标应用客户端指示一类目标应用客户端，且每一类目标应用客户端包括至少一个目标应用客户端。参见图8，在目标资源41的角度来看，与目标资源41相连的多组目标应用客户端可以为：一组目标应用客户端33：第一机器21中的目标应用客户端33、第二机器22中的目标应用客户端33、第三机器23中的目标应用客户端33。一组目标应用客户端36：第二机器22中的目标应用客户端36、第三机器23中的目标应用客户端36。一组目标应用客户端31：第四机器24中的目标应用客户端31。一组目标应用客户端34：第五机器25中的目标应用客户端34。因此，可以接收上述多组目标应用客户端发送的目标消息。

步骤42：针对每一组目标应用客户端，将该组内的每一个目标应用客户端与所述目标资源之间的连接数之和，作为该组目标应用客户端与所述目标资源之间的组连接数；将所述多组目标应用客户端中的每一组目标应用客户端与所述目标资源之间的组连接数之和，作为所述目标资源的占用连接数。

其中，在本申请实施例中，可以根据所述多组目标应用客户端中同一组内的每一个目标应用客户端与所述目标资源之间的连接数，分别确定每一组目标应用客户端与所述目标资源之间的组连接数。所述分别确定每一组目标应用客户端与所述目标资源之间的连接数可以包括子步骤：针对任一组目标应用客户端，将同一组内的每一个所述目标应用客户端与所述目标资源之间的连接数之和，作为该组目标应用客户端与所述目标资源之间的组连接数。

可以理解的是，所述根据所述多组目标应用客户端中同一组内的每一个目标应用客户端与所述目标资源之间的连接数，分别确定每一组目标应用客户端与所述目标资源之间的组连接数。参见图8，第一服务器21中的目标应用客户端33、第二服务器22中的目标应用客户端33、第三服务器23中的目标应用客户端33，与目标资源41之间的连接数之和可以作为，一组目标应用客户端33与所述目标资源41之间的连接数。

可以理解的是，将所述多组目标应用客户端中的每一组目标应用客户端与所述目标资源之间的组连接数之和，作为所述目标资源的占用连接数。参见图8，在目标资源41的角度来看，目标资源41的占用连接数可以为，与目标资源41相连的多组目标应用客户端中的每一组目标应用客户端与所述目标资源之间的连接数之和。

可以理解的是，目标资源41的占用连接数可以为，一组第一目标应用客户端31、一组第二目标应用客户端32、一组第三目标应用客户端33、一组第四目标应用客户端34、一组第五目标应用客户端35、一组第一目标应用客户端36，与所述目标资源之间的连接数之和，作为所述目标资源的占用连接数。

步骤43：在所述目标资源的所述占用连接数达到所述目标资源的连接数阈值的情况下，对所述目标资源进行管控。

其中，所述对所述目标资源进行管控可以包括，拒绝除了已连接所述目标资源的目标应用客户端之外的其他目标应用客户端连接所述目标资源，并输出警报。

可以理解的是，所述目标资源的所述占用连接数已经达到所述目标资源的连接数阈值时，所述目标资源的连接数已经告急，再增加新的连接会导致所述目标资源连接数超限，因此可以通过拒绝新的目标应用客户端连接所述目标资源，即拒绝除了已连接所述目标资源的目标应用客户端之外的其他目标应用客户端连接所述目标资源，并输出警报。其中所述输出警报可以是发送警报邮件等等。

可以理解的是，所述目标资源的所述占用连接数已经达到所述目标资源的连接数阈值时，所述目标资源的连接数已经告急，也可以通过输出警报，增大所述目标资源的数量，以防止所述目标资源连接数超限。

可以理解的是，所述目标资源是存在所能承载的最大连接数目限制的，所述目标资源的连接数阈值可以是所述目标资源的最大连接数。所述目标资源的连接数阈值可以是所述目标资源的最大连接数目的预设百分比。例如，某目标资源的最大连接数可以是3000，连接数阈值可以是3000的80％(或者70％、60％等)。当占用连接数为2400时，所述目标资源的所述占用连接数已经达到所述目标资源的连接数阈值，则需要对所述目标资源进行管控。如此，通过本申请提供的一种基于服务池的资源管控方法，可以实时根据用户的访问量，得到目标资源的实时使用情况，从而可以对目标资源进行动态管控，进一步有效解决了现有技术中，由于无法实现对资源的动态管控，所造成的目标资源的使用瓶颈问题。

在本申请实施例中，上述步骤11还可以包括：接收目标应用客户端集合中的目标应用客户端每隔单位周期发送的目标消息。

可以理解的是，参见图10，目标应用客户端33中可以设置一个定时任务，并且可以设置定时周期，例如可以设置定时周期为1分钟，目标应用客户端33每隔单位周期将采集到的目标消息发送一次，将目标消息发送到接收方101。接收方101可以将接收到的目标消息存储在数据库102中。

在本申请实施例中，在上述步骤12之后，所述方法还包括：显示可视界面，所述可视界面中包括所述目标资源的占用连接数。

其中，所述可视界面可以包括：应用维度界面、资源维度界面、服务池维度界面。

可以理解的是，应用维度界面可以展示目标应用客户端与所述目标资源之间的连接数。

可以理解的是，参见图7，资源维度界面可以展示第一目标资源41、第二目标资源42、第三目标资源43、第四目标资源44中，每一个目标资源的当前实际占用连接数，可以采用表格的形式进行汇总展示。资源维度界面展示的方式可以方便用户实时对目标资源的占用连接数进行监控。

可以理解的是，服务池维度界面可以展示服务池内所有目标应用客户端与所述目标资源之间的连接数。

图5是本申请实施例提供的一种基于服务池的资源管控方法的流程图。

本申请实施例提供的一种基于服务池的资源管控方法，所述服务池可以包括客户端，参见图5，所述资源管控方法可以包括：步骤51、步骤52，下面分别对步骤51和步骤52进行阐述。

步骤51：确定客户端与目标资源之间的连接数，其中，所述客户端为使用目标资源的客户端。

在本申请实施例中，在步骤51之前，本申请实施例提供的一种基于服务池的资源管控方法还可以包括如下步骤：在所述客户端中植入目标指令，所述目标指令用于采集所述客户端与目标资源的连接数。

那么，上述步骤51还可以包括：

子步骤一：所述客户端通过所述目标指令确定所述客户端与目标资源之间的连接数。

本申请实施例提供的一种基于服务池的资源管控方法，所述客户端可以为基于java语言的客户端，所述目标指令可以为jar包，参见图6，上述子步骤一还可以包括：步骤61、步骤62。

其中，所述jar包(javaarchive)是一种软件包文件格式，通常用于聚合大量的java类文件、相关的元数据和资源文件到一个jar包，以便开发java平台应用软件和库。所述jar包可以自动采集所述客户端与目标资源之间的连接数。

步骤61：所述客户端在启动后，执行所述目标指令，从java基础框架的容器中读取各个数据库池的基本单元，所述基本单元包括连接数。

其中，所述java基础框架可以采用spring框架(springframework)、springboot框架(springbootframework)等等。其中spring框架是一个轻量级的控制反转和面向切面的容器框架，可以理解的是，所有的spring模块都是在核心容器的基础上构建的，核心容器是spring框架中最基础的部分，核心容器提供了依赖注入(dependencyinjection)特征来实现容器对java软件组件(enterprisejavabean，bean)的管理。

可以理解的是，参见图9，所述基本单元可以是bean组件，bean组件中属性有：最小连接数、最大连接数、当前连接数。所述客户端33在启动后，jar包95采集数据库池91-94中的bean组件中的属性。

可以理解的是，参见图9，数据库池可以包括：第一数据库池91、第二数据库池92、第三数据库池93、第四数据库池94。其中与第一目标资源41相连接的数据库池为第一数据库池91、第二数据库池92、第三数据库池93。与第二目标资源42相连的数据库池为第四数据库池。可以理解的是，第一目标资源41可以是mysql数据库，第二目标资源42可以是redis数据库。而连接数据库所使用的数据库池有所不同，连接mysql数据库的数据库池可以包括c3p0、druid、hikari，连接redis数据库的数据库池可以使用jredis。那么，第一数据库池91可以为c3p0、第二数据库池92可以为druid、第三数据库池93可以为hikari、第四数据库池94可以为jredis。

步骤62：将从各个数据库池的基本单元中读取出的连接数之和，作为所述客户端与目标资源之间的连接数。

可以理解的是，通过上述步骤61和步骤62，可以嵌入客户端内部进行连接数采集，从而得到了最小颗粒度数据，即一个客户端的连接数数据。

步骤52：向服务器发送目标消息，所述目标消息包括所述客户端与所述目标资源之间的连接数，使得所述服务器基于服务池中至少一组所述使用目标资源的客户端与所述目标资源之间的连接数，确定所述目标资源的占用连接数，并在所述目标资源的所述占用连接数达到，所述目标资源的连接数阈值的情况下，对所述目标资源进行管控。

如此，通过本申请提供的一种基于服务池的资源管控方法，可以实时根据用户的访问量，得到目标资源的实时使用情况，从而可以对目标资源进行动态管控，进一步有效解决了现有技术中，由于无法实现对资源的动态管控，所造成的目标资源的使用瓶颈问题。

图11是本申请实施例提供的一种基于服务池的资源管控装置的结构框图。参见图11，所述服务池包括目标应用客户端集合，所述资源管控装置800可包括：

接收模块801，用于接收所述服务池中的至少一组目标应用客户端发送的目标消息，其中，所述目标应用客户端为使用目标资源的客户端，所述目标消息包括所述目标应用客户端与所述目标资源之间的连接数；

确定模块802，用于基于所述至少一组目标应用客户端中每一个目标应用客户端与所述目标资源之间的连接数，确定所述目标资源的占用连接数；

管控模块803，用于在所述目标资源的所述占用连接数达到所述目标资源的连接数阈值的情况下，对所述目标资源进行管控。

可选的，所述管控模块803还可以用于：拒绝除了已连接所述目标资源的目标应用客户端之外的其他目标应用客户端连接所述目标资源，并输出警报。

可选的，所述接收模块801还可以用于：接收所述服务池中的一组目标应用客户端发送的目标消息，该组目标应用客户端包括属于相同类别的多个目标应用客户端。所述确定模块802还可以用于：将该组目标应用客户端中的每一个目标应用客户端与所述目标资源之间的连接数之和，确定为所述目标资源的占用连接数。

可选地，每一组目标应用客户端指示一类目标应用客户端，且每一类目标应用客户端包括至少一个目标应用客户端。所述接收模块801还可以用于：接收所述服务池中的多组目标应用客户端发送的目标消息；其中，每一组目标应用客户端指示一类目标应用客户端，且每一类目标应用客户端包括至少一个目标应用客户端。所述确定模块802还可以用于：针对每一组目标应用客户端，将该组内的每一个目标应用客户端与所述目标资源之间的连接数之和，作为该组目标应用客户端与所述目标资源之间的组连接数；将所述多组目标应用客户端中的每一组目标应用客户端与所述目标资源之间的组连接数之和，作为所述目标资源的占用连接数。所述确定模块802还可以用于：针对任一组目标应用客户端，将同一组内的每一个目标应用客户端与所述目标资源之间的连接数之和，作为该组目标应用客户端与所述目标资源之间的连接数。

可选地，所述接收模块801还可以用于：接收所述目标应用客户端集合中的所述目标应用客户端每隔单位周期发送的目标消息。

可选地，在所述确定所述目标资源的占用连接数之后，所述管控模块803还包括：显示单元，用于显示可视界面，所述可视界面中包括所述目标资源的占用连接数。

其中，所述基于服务池的资源管控装置与基于服务池的资源管控方法相对应，以上各个步骤的具体实施过程可参照上文描述，在此不再赘述。

在本申请实施例中，所述服务池包括目标应用客户端集合，所述资源管控方法包括：接收目标应用客户端集合中的目标应用客户端发送的目标消息，其中，所述目标应用客户端为使用目标资源的客户端，所述目标消息包括所述目标应用客户端与所述目标资源之间的连接数；基于所述目标应用客户端与所述目标资源之间的连接数，确定所述目标资源的占用连接数；在所述目标资源的所述占用连接数达到，所述目标资源的连接数阈值的情况下，对所述目标资源进行管控。如此，通过本申请提供的一种基于服务池的资源管控方法，可以实时根据用户的访问量，得到目标资源的实时使用情况，从而可以对目标资源进行动态管控，进一步有效解决了现有技术中，由于无法实现对资源的动态管控，所造成的目标资源的使用瓶颈问题。

图12是本申请实施例提供的一种基于服务池的资源管控装置的结构框图。参见图12，所述服务池包括客户端，所述资源管控装置900可包括：

确定模块901，用于确定客户端与目标资源之间的连接数，其中，所述客户端为使用目标资源的客户端。

发送模块902：用于向服务器发送目标消息，所述目标消息包括所述客户端与所述目标资源之间的连接数，使得所述服务器基于服务池中至少一组所述使用目标资源的客户端与所述目标资源之间的连接数，确定所述目标资源的占用连接数，并在所述目标资源的所述占用连接数达到，所述目标资源的连接数阈值的情况下，对所述目标资源进行管控。

可选地，在所述客户端确定所述客户端与目标资源之间的连接数之前，所述确定模块901还可以用于，在所述客户端中植入目标指令，所述目标指令用于采集所述客户端与目标资源的连接数。

可选地，上述所述确定模块901还用于，所述客户端通过所述目标指令确定所述客户端与目标资源之间的连接数。

可选地，上述所述客户端可以为基于java语言的客户端，所述目标指令可以为jar包。所述确定模块901还可以用于，在所述客户端启动后，执行所述目标指令，从java基础框架的容器中读取各个数据库池的基本单元，所述基本单元包括连接数；将从各个数据库池的基本单元中读取出的连接数之和，作为所述客户端与目标资源之间的连接数。

其中，所述基于服务池的资源管控装置与基于服务池的资源管控方法相对应，以上各个步骤的具体实施过程可参照上文描述，在此不再赘述。

在本申请实施例中，所述服务池包括目标应用客户端集合，所述资源管控方法包括：接收目标应用客户端集合中的目标应用客户端发送的目标消息，其中，所述目标应用客户端为使用目标资源的客户端，所述目标消息包括所述目标应用客户端与所述目标资源之间的连接数；基于所述目标应用客户端与所述目标资源之间的连接数，确定所述目标资源的占用连接数；在所述目标资源的所述占用连接数达到所述目标资源的连接数阈值的情况下，对所述目标资源进行管控。如此，通过本申请提供的一种基于服务池的资源管控方法，可以实时根据用户的访问量，得到目标资源的实时使用情况，从而可以对目标资源进行动态管控，进一步有效解决了现有技术中，由于无法实现对资源的动态管控，所造成的目标资源的使用瓶颈问题。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本发明的保护之内。