CN105335231B - 一种服务端线程的动态分配方法和设备 - Google Patents

Abstract

本申请公开了一种服务端线程的动态分配方法和设备，该方法包括：服务器利用各接口对应的接口信息分配各接口的第一服务端线程数量；所述服务器在接收到RPC请求消息之后，确定所述RPC请求消息对应的接口当前已经启动的第二服务端线程数量；如果所述第二服务端线程数量小于所述接口对应的第一服务端线程数量，则所述服务器为所述RPC请求消息启动服务端线程；如果所述第二服务端线程数量等于所述接口对应的第一服务端线程数量，则所述服务器拒绝为所述RPC请求消息启动服务端线程。本申请实施例中，服务器可以合理的为各接口分配服务端线程，最大程度的提高服务端线程的利用率，并实现服务端线程的最优化分配以及服务器性能的最大化。

Description

一种服务端线程的动态分配方法和设备

技术领域

本申请涉及互联网领域，尤其是一种服务端线程的动态分配方法和设备。

背景技术

RPC(Remote Procedure Call，远程过程调用)协议是一种进程之间的通信协议，客户端可以通过RPC协议请求服务器所提供的服务。

具体的，服务器发布一个服务之后，客户端根据调用参数向服务器发送RPC请求消息，服务器在收到RPC请求消息之后，为该RPC请求消息启动一个服务端线程，并通过该服务端线程为客户端提供服务，即服务端线程利用RPC请求消息中携带的调用参数为客户端提供服务，并通过RPC应答消息将服务结果返回给客户端。客户端在收到RPC应答消息后，可以调用相应的服务。

通常情况下，服务器会对外提供多个接口，每个接口对应一个服务，例如，服务器对外提供接口1和接口2，客户端可以通过接口1调用服务器提供的服务1(如订单查询服务)，且客户端可以通过接口2调用服务器提供的服务2(如订单支付服务)。进一步的，在同一时间段内，通常会有大量客户端向服务器发送RPC请求消息，即服务器将收到大量的RPC请求消息。基于此，由于服务器上能够分配的服务端线程的数量有限，因此，服务器在收到RPC请求消息后，首先判断本服务器上是否有能够分配的服务端线程；如果有，则为RPC请求消息启动一个服务端线程，并在RPC请求消息被该服务端线程处理完成之后，由服务器释放该服务端线程；如果没有，则直接丢弃RPC请求消息。

在上述方式下，如果接口1对应的接口响应时间很长，而接口2对应的接口响应时间很短，且接口1对应有大量的RPC请求消息，则大量的服务端线程将用于处理接口1对应的RPC请求消息，服务端线程无法被及时释放，继而导致接口2对应的RPC请求消息也无法及时得到处理，即导致接口响应时间很短的接口2也无法分配到更多的服务端线程，其服务端线程的利用率很低。

发明内容

本申请实施例提供一种服务端线程的动态分配方法和设备，以合理的为各接口分配服务端线程，并提高服务端线程的利用率，提高消息处理效率。

本申请实施例提供一种服务端线程的动态分配方法，所述方法包括：

服务器利用各接口对应的接口信息分配各接口的第一服务端线程数量；

所述服务器在接收到远程过程调用RPC请求消息之后，确定所述RPC请求消息对应的接口当前已经启动的第二服务端线程数量；

如果所述第二服务端线程数量小于所述接口对应的第一服务端线程数量，则所述服务器为所述RPC请求消息启动服务端线程；

如果所述第二服务端线程数量等于所述接口对应的第一服务端线程数量，则所述服务器拒绝为所述RPC请求消息启动服务端线程。

所述各接口对应的接口信息具体包括：所述各接口在指定时间段内对应的平均接口响应时间，和/或，所述各接口在指定时间段内对应的RPC请求消息接收数量。

所述服务器利用各接口对应的接口信息分配各接口的第一服务端线程数量的过程，具体包括：

所述服务器利用预设第一分配策略为各接口分配对应的第一服务端线程数量；其中，所述预设第一分配策略具体为：当接口在指定时间段内对应的平均接口响应时间越小时，则所述服务器为所述接口分配的第一服务端线程数量越多；当接口在指定时间段内对应的平均接口响应时间越大时，则所述服务器为所述接口分配的第一服务端线程数量越少；或者，

所述服务器利用预设第二分配策略为各接口分配对应的第一服务端线程数量；其中，所述预设第二分配策略具体为：当接口在指定时间段内对应的RPC请求消息接收数量越多时，则所述服务器为所述接口分配的第一服务端线程数量越多；当接口在指定时间段内对应的RPC请求消息接收数量越少时，则所述服务器为所述接口分配的第一服务端线程数量越少；或者，

所述服务器利用预设第三分配策略为各接口分配对应的第一服务端线程数量；其中，所述预设第三分配策略具体为：当接口在指定时间段内对应的平均接口响应时间越小，且所述接口在指定时间段内对应的RPC请求消息接收数量越多时，为所述接口分配的第一服务端线程数量越多；当接口在指定时间段内对应的平均接口响应时间越大，且所述接口在指定时间段内对应的RPC请求消息接收数量越少时，为所述接口分配的第一服务端线程数量越少。

当所述各接口对应的接口信息具体为：所述各接口在指定时间段内对应的平均接口响应时间以及所述各接口在指定时间段内对应的RPC请求消息接收数量时，所述服务器利用各接口对应的接口信息分配各接口的第一服务端线程数量的过程，具体包括：

所述服务器利用如下公式为接口分配所述接口的第一服务端线程数量：

其中，所述N为所述服务器能够分配的服务端线程总数，所述C为所述服务器提供的接口总数，所述R_n为所述接口在指定时间段内对应的RPC请求消息接收数量，所述R_x为第x个接口在指定时间段内对应的RPC请求消息接收数量，所述T_n为所述接口在指定时间段内对应的平均接口响应时间，所述T_x为第x个接口在指定时间段内对应的平均接口响应时间。

当所述各接口对应的接口信息具体为：所述各接口在指定时间段内对应的平均接口响应时间以及所述各接口在指定时间段内对应的RPC请求消息接收数量时，所述服务器利用各接口对应的接口信息分配各接口的第一服务端线程数量的过程，具体包括：

当服务器从能够分配的服务端线程中为各接口分配能够竞争的服务端线程时，所述服务器利用如下公式为接口分配所述接口的第一服务端线程数量：

其中，N为所述服务器能够分配的服务端线程总数，S为能够竞争的服务端线程的总数量，C为所述服务器提供的接口总数，R_n为所述接口在指定时间段内对应的RPC请求消息接收数量，R_x为第x个接口在指定时间段内对应的RPC请求消息接收数量，T_n为所述接口在指定时间段内对应的平均接口响应时间，T_x为第x个接口在指定时间段内对应的平均接口响应时间。

所述方法进一步包括：

当所述服务器从能够分配的服务端线程中为各接口分配能够竞争的服务端线程，且能够竞争的服务端线程的总数量为S时，如果所述第二服务端线程数量等于所述接口对应的第一服务端线程数量，则所述服务器确定当前已经启动的能够竞争的服务端线程的第三服务端线程数量；

如果所述第三服务端线程数量小于所述S，则所述服务器从能够竞争的服务端线程中为所述RPC请求消息启动服务端线程；如果所述第三服务端线程数量等于所述S，则所述服务器拒绝为所述RPC请求消息启动服务端线程。

本申请实施例提供一种服务器，所述服务器具体包括：

分配模块，用于利用各接口对应的接口信息分配所述各接口对应的第一服务端线程数量；

确定模块，用于在接收到远程过程调用RPC请求消息之后，确定所述RPC请求消息对应的接口当前已经启动的第二服务端线程数量；

处理模块，用于当所述第二服务端线程数量小于所述接口对应的第一服务端线程数量时，则为所述RPC请求消息启动服务端线程；

当所述第二服务端线程数量等于所述接口对应的第一服务端线程数量时，则拒绝为所述RPC请求消息启动服务端线程。

所述各接口对应的接口信息具体包括：所述各接口在指定时间段内对应的平均接口响应时间，和/或，所述各接口在指定时间段内对应的RPC请求消息接收数量。

所述分配模块，具体用于利用预设第一分配策略为各接口分配对应的第一服务端线程数量；其中，所述预设第一分配策略具体为：当接口在指定时间段内对应的平均接口响应时间越小时，则为所述接口分配的第一服务端线程数量越多；当接口在指定时间段内对应的平均接口响应时间越大时，则为所述接口分配的第一服务端线程数量越少；或者，利用预设第二分配策略为各接口分配对应的第一服务端线程数量；其中，所述预设第二分配策略具体为：当接口在指定时间段内对应的RPC请求消息接收数量越多时，则为所述接口分配的第一服务端线程数量越多；当接口在指定时间段内对应的RPC请求消息接收数量越少时，则为所述接口分配的第一服务端线程数量越少；或者，利用预设第三分配策略为各接口分配对应的第一服务端线程数量；其中，所述预设第三分配策略具体为：当接口在指定时间段内对应的平均接口响应时间越小，且所述接口在指定时间段内对应的RPC请求消息接收数量越多时，则为所述接口分配的第一服务端线程数量越多；当接口在指定时间段内对应的平均接口响应时间越大，且所述接口在指定时间段内对应的RPC请求消息接收数量越少时，则为所述接口分配的第一服务端线程数量越少。

当所述各接口对应的接口信息具体为：所述各接口在指定时间段内对应的平均接口响应时间以及所述各接口在指定时间段内对应的RPC请求消息接收数量时，所述分配模块，具体用于利用如下公式为接口分配所述接口的第一服务端线程数量：

其中，所述N为所述服务器能够分配的服务端线程总数，所述C为所述服务器提供的接口总数，所述R_n为所述接口在指定时间段内对应的RPC请求消息接收数量，所述R_x为第x个接口在指定时间段内对应的RPC请求消息接收数量，所述T_n为所述接口在指定时间段内对应的平均接口响应时间，所述T_x为第x个接口在指定时间段内对应的平均接口响应时间。

当所述各接口对应的接口信息具体为：所述各接口在指定时间段内对应的平均接口响应时间以及所述各接口在指定时间段内对应的RPC请求消息接收数量时，所述分配模块，具体用于当服务器从能够分配的服务端线程中为各接口分配能够竞争的服务端线程时，利用如下公式为接口分配所述接口的第一服务端线程数量：

其中，N为所述服务器能够分配的服务端线程总数，S为能够竞争的服务端线程的总数量，C为所述服务器提供的接口总数，R_n为所述接口在指定时间段内对应的RPC请求消息接收数量，R_x为第x个接口在指定时间段内对应的RPC请求消息接收数量，T_n为所述接口在指定时间段内对应的平均接口响应时间，T_x为第x个接口在指定时间段内对应的平均接口响应时间。

所述确定模块，还用于当所述服务器从能够分配的服务端线程中为各接口分配能够竞争的服务端线程，且能够竞争的服务端线程的总数量为S时，如果所述第二服务端线程数量等于所述接口对应的第一服务端线程数量，则确定当前已经启动的能够竞争的服务端线程的第三服务端线程数量；

所述处理模块，进一步用于当所述第三服务端线程数量小于所述S时，从能够竞争的服务端线程中为所述RPC请求消息启动服务端线程；当所述第三服务端线程数量等于所述S时，拒绝为所述RPC请求消息启动服务端线程。

与现有技术相比，本申请实施例至少具有以下优点：本申请实施例中，服务器可以利用各接口对应的接口信息分配各接口的第一服务端线程数量，并在接收到RPC请求消息之后，确定RPC请求消息对应的接口当前已经启动的第二服务端线程数量，如果第二服务端线程数量小于接口对应的第一服务端线程数量，则为RPC请求消息启动服务端线程，如果第二服务端线程数量等于接口对应的第一服务端线程数量，则拒绝为RPC请求消息启动服务端线程。基于上述方式，服务器可以合理的为各接口分配服务端线程，最大程度的提高服务端线程的利用率，并提高消息处理效率，并实现服务端线程的最优化分配以及服务器性能的最大化，并可以解决接口间的隔离性问题，避免了因为一个接口响应慢且请求高时，导致所有接口响应都变慢的问题。

附图说明

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

图1是本申请实施例一提供的一种服务端线程的动态分配方法流程图；

图2是本申请实施例二提供的一种服务器的结构示意图。

具体实施方式

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

实施例一

针对现有技术中存在的问题，本申请实施例一提供一种服务端线程的动态分配方法，该方法应用于包括服务器和多个客户端的系统中，且该系统可以为分布式系统。如图1所示，该服务端线程的动态分配方法包括以下步骤：

步骤101，服务器利用各接口对应的接口信息分配各接口的第一服务端线程数量。其中，各接口对应的接口信息具体包括但不限于：各接口在指定时间段内(如从当前时间之前的第100ms至当前时间)对应的平均接口响应时间，和/或，各接口在指定时间段内对应的RPC请求消息接收数量。

通常情况下，服务器会对外提供多个接口，每个接口对应一个服务，例如，服务器对外提供接口1和接口2，客户端可以通过接口1调用服务器提供的服务1(如订单查询服务)，且客户端可以通过接口2调用服务器提供的服务2(如订单支付服务)。基于此，接口1对应的接口信息具体包括但不限于：接口1在指定时间段内对应的平均接口响应时间，和/或，接口1在指定时间段内对应的RPC请求消息接收数量。接口2对应的接口信息具体包括但不限于：接口2在指定时间段内对应的平均接口响应时间，和/或，接口2在指定时间段内对应的RPC请求消息接收数量。例如，在指定时间段内共收到100个客户端通过接口1调用服务器提供的服务2的RPC请求消息，则接口1在指定时间段内对应的RPC请求消息接收数量为100。例如，在指定时间段内共完成50个对应接口1的RPC请求消息的处理，则接口1在指定时间段内对应的平均接口响应时间为这50个RPC请求消息的平均处理时间。

本申请实施例中，服务器利用各接口对应的接口信息分配各接口的第一服务端线程数量的过程，具体包括但不限于如下分配方式：

方式一、当各接口对应的接口信息为各接口在指定时间段内对应的平均接口响应时间时，服务器利用预设第一分配策略为各接口分配对应的第一服务端线程数量。其中，预设第一分配策略具体为：当接口在指定时间段内对应的平均接口响应时间越小时，服务器为接口分配的第一服务端线程数量越多；当接口在指定时间段内对应的平均接口响应时间越大时，服务器为接口分配的第一服务端线程数量越少。基于此，当接口在指定时间段内对应的平均接口响应时间相对于总响应时间越小，分配到的第一服务端线程数量越多。

方式二、当各接口对应的接口信息为各接口在指定时间段内对应的RPC请求消息接收数量时，服务器利用预设第二分配策略为各接口分配对应的第一服务端线程数量。预设第二分配策略为：当接口在指定时间段内对应的RPC请求消息接收数量越多时，服务器为接口分配的第一服务端线程数量越多；当接口在指定时间段内对应的RPC请求消息接收数量越少时，服务器为接口分配的第一服务端线程数量越少。基于此，当接口在指定时间段内对应的RPC请求消息接收数量相对于总请求数越多，分配到的第一服务端线程数量越多。

方式三、当各接口对应的接口信息具体为各接口在指定时间段内对应的平均接口响应时间，以及，各接口在指定时间段内对应的RPC请求消息接收数量时，则服务器利用预设第三分配策略为各接口分配对应的第一服务端线程数量。其中，预设第三分配策略具体包括但不限于：当接口在指定时间段内对应的平均接口响应时间越小，且该接口在指定时间段内对应的RPC请求消息接收数量越多时，则服务器为接口分配的第一服务端线程数量越多；当接口在指定时间段内对应的平均接口响应时间越大，且该接口在指定时间段内对应的RPC请求消息接收数量越少时，则服务器为接口分配的第一服务端线程数量越少。基于此，当接口在指定时间段内对应的平均接口响应时间相对于总响应时间越小，且接口在指定时间段内对应的RPC请求消息接收数量相对于总请求数越多，则分配到的第一服务端线程数量越多。

本申请实施例中，当各接口对应的接口信息具体为：各接口在指定时间段内对应的平均接口响应时间以及各接口在指定时间段内对应的RPC请求消息接收数量时(即针对方式三)，服务器利用各接口对应的接口信息分配各接口的第一服务端线程数量的过程，还具体包括但不限于如下方式：

服务器利用如下公式为接口(如接口1)分配接口的第一服务端线程数量：

其中，N为服务器能够分配的服务端线程总数(如服务器提供服务端线程总数200)，C为服务器提供的接口总数，R_n为接口(如接口1)在指定时间段内对应的RPC请求消息接收数量，R_x为第x个接口在指定时间段内对应的RPC请求消息接收数量，T_n为接口(如接口1)在指定时间段内对应的平均接口响应时间，T_x为第x个接口在指定时间段内对应的平均接口响应时间。

假设接口1在指定时间段内对应的平均接口响应时间小于接口2在指定时间段内对应的平均接口响应时间，则服务器可以为接口1分配第一服务端线程数量为150，且服务器可以为接口2分配第一服务端线程数量为50。

步骤102，服务器在接收到来自客户端的RPC请求消息之后，确定该RPC请求消息对应的接口当前已经启动的第二服务端线程数量。

具体的，服务器在发布一个服务之后，客户端可以根据调用参数向服务器发送RPC请求消息，且在同一时间段内，通常会有大量客户端向服务器发送RPC请求消息，即服务器将收到大量的RPC请求消息。服务器在收到RPC请求消息之后，针对每个RPC请求消息，服务器确定该RPC请求消息对应的接口当前已经启动的第二服务端线程数量。例如，如果RPC请求消息为客户端通过接口1调用服务器提供的服务1的RPC请求消息，则该RPC请求消息对应的接口为接口1，服务器确定接口1当前已经启动的第二服务端线程数量。

例如，服务器上已经启动的服务端线程为150个，且150个服务端线程中有100个服务端线程正在利用接口1对应的RPC请求消息中携带的调用参数为客户端提供服务，则接口1当前已经启动的第二服务端线程数量为100。

步骤103，服务器比较第二服务端线程数量与接口(即RPC请求消息对应的接口)对应的第一服务端线程数量(步骤101中分配)；如果第二服务端线程数量小于该接口对应的第一服务端线程数量，则执行步骤104；如果第二服务端线程数量等于该接口对应的第一服务端线程数量，则执行步骤105。

步骤104，服务器为RPC请求消息启动服务端线程。

具体的，服务器为RPC请求消息启动一个服务端线程，并通过该服务端线程为客户端提供服务，即该服务端线程利用RPC请求消息中携带的调用参数为客户端提供服务，并通过RPC应答消息将服务结果返回给客户端。客户端在收到RPC应答消息后，可以调用相应的服务。进一步的，在RPC请求消息被该服务端线程处理完成之后，可以由服务器释放该服务端线程。

步骤105，服务器拒绝为RPC请求消息启动服务端线程。

具体的，服务器直接丢弃RPC请求消息，而不再为该RPC请求消息启动服务端线程。进一步的，客户端在预设时间内没有收到RPC应答消息时，会重新向服务器发送RPC请求消息，后续处理与上述流程类似，在此不再赘述。

综上所述，本申请实施例至少具有以下优点：本申请实施例中，服务器可以利用各接口对应的接口信息分配各接口的第一服务端线程数量，并在接收到RPC请求消息之后，确定RPC请求消息对应的接口当前已经启动的第二服务端线程数量，如果第二服务端线程数量小于接口对应的第一服务端线程数量，则为RPC请求消息启动服务端线程，如果第二服务端线程数量等于接口对应的第一服务端线程数量，则拒绝为RPC请求消息启动服务端线程。基于上述方式，服务器可以合理的为各接口分配服务端线程，最大程度的提高服务端线程的利用率，并提高消息处理效率，并实现服务端线程的最优化分配以及服务器性能的最大化，并可以解决接口间的隔离性问题，避免了因为一个接口响应慢且请求高时，导致所有接口响应都变慢的问题。

本申请实施例中，当服务器从能够分配的服务端线程中为各接口分配能够竞争的服务端线程时，例如，能够分配的服务端线程为200个，且服务器从200个服务端线程中选取出40个服务端线程作为各接口能够竞争的服务端线程，则本申请实施例中提出的服务端线程的动态分配方法还包括以下过程：

针对步骤101，当各接口对应的接口信息具体为：各接口在指定时间段内对应的平均接口响应时间以及各接口在指定时间段内对应的RPC请求消息接收数量时(即针对方式三)，服务器利用各接口对应的接口信息分配各接口的第一服务端线程数量的过程，还具体包括但不限于如下方式：

服务器利用如下公式为接口(如接口1)分配接口的第一服务端线程数量：

其中，N为服务器能够分配的服务端线程总数(如服务器提供服务端线程总数200)，S为能够竞争的服务端线程的总数量(能够竞争的服务端线程的总数量40)，C为服务器提供的接口总数，R_n为接口(如接口1)在指定时间段内对应的RPC请求消息接收数量，R_x为第x个接口在指定时间段内对应的RPC请求消息接收数量，T_n为接口(如接口1)在指定时间段内对应的平均接口响应时间，T_x为第x个接口在指定时间段内对应的平均接口响应时间。

例如，设N为200，S为40，C为2，R₁为接口1在指定时间段内对应的RPC请求消息接收数量(100)，R₁为接口2在指定时间段内对应的RPC请求消息接收数量(1000)，T₁为接口1在指定时间段内对应的平均接口响应时间(100ms)，T₂为接口2在指定时间段内对应的平均接口响应时间(50ms)。

服务器在利用上述公式为接口1分配接口1的第一服务端线程数量时，接口1的第一服务端线程数量为：[(200-40)/2]*[100/(100+1000)+1-100/(100+50)]，即接口1的第一服务端线程数量为34(对计算值四舍五入)。

服务器在利用上述公式为接口2分配接口2的第一服务端线程数量时，接口2的第一服务端线程数量为：[(200-40)/2]*[1000/(100+1000)+1-50/(100+50)]，即接口2的第一服务端线程数量为126(对计算值四舍五入)。

进一步的，当服务器从能够分配的服务端线程中为各接口分配能够竞争的服务端线程，且能够竞争的服务端线程的总数量为S时，则针对步骤103，服务器在比较第二服务端线程数量与接口对应的第一服务端线程数量之后，如果第二服务端线程数量等于接口对应的第一服务端线程数量，则服务器不执行步骤105，而是由服务器确定当前已经启动的能够竞争的服务端线程的第三服务端线程数量。进一步的，如果第三服务端线程数量小于S，则服务器直接从能够竞争的服务端线程中为RPC请求消息启动服务端线程；如果第三服务端线程数量等于S，则服务器进一步拒绝为RPC请求消息启动服务端线程。

基于上述技术方案，本申请实施例至少具有以下优点：本发明实施例中，通过设置服务端线程竞争区域(如40个服务端线程)，实现在给接口动态分配服务端线程的同时，保留接口之间通过资源竞争实现服务端线程的合理分配，并可以通过服务端线程竞争区域的占用量来动态监控服务器的健康状况。如果服务端线程竞争区域使用过半，则说明此时服务器的负载已经过高，可以考虑通过增加服务器或其它方式来降低单台服务器的负载。

实施例二

基于与上述方法同样的申请构思，本申请实施例中还提供了一种服务器，如图2所示，所述服务器具体包括：分配模块11，用于利用各接口对应的接口信息分配所述各接口对应的第一服务端线程数量；确定模块12，用于在接收到远程过程调用RPC请求消息之后，确定所述RPC请求消息对应的接口当前已经启动的第二服务端线程数量；处理模块13，用于当所述第二服务端线程数量小于所述接口对应的第一服务端线程数量时，则为所述RPC请求消息启动服务端线程；当所述第二服务端线程数量等于所述接口对应的第一服务端线程数量时，则拒绝为所述RPC请求消息启动服务端线程。

本申请实施例中，所述各接口对应的接口信息具体包括：所述各接口在指定时间段内对应的平均接口响应时间，和/或，所述各接口在指定时间段内对应的RPC请求消息接收数量。

所述分配模块11，具体用于利用预设第一分配策略为各接口分配对应的第一服务端线程数量；其中，所述预设第一分配策略具体为：当接口在指定时间段内对应的平均接口响应时间越小时，则为所述接口分配的第一服务端线程数量越多；当接口在指定时间段内对应的平均接口响应时间越大时，则为所述接口分配的第一服务端线程数量越少；或者，利用预设第二分配策略为各接口分配对应的第一服务端线程数量；其中，所述预设第二分配策略具体为：当接口在指定时间段内对应的RPC请求消息接收数量越多时，则为所述接口分配的第一服务端线程数量越多；当接口在指定时间段内对应的RPC请求消息接收数量越少时，则为所述接口分配的第一服务端线程数量越少；或者，利用预设第三分配策略为各接口分配对应的第一服务端线程数量；其中，所述预设第三分配策略具体为：当接口在指定时间段内对应的平均接口响应时间越小，且所述接口在指定时间段内对应的RPC请求消息接收数量越多时，则为所述接口分配的第一服务端线程数量越多；当接口在指定时间段内对应的平均接口响应时间越大，且所述接口在指定时间段内对应的RPC请求消息接收数量越少时，则为所述接口分配的第一服务端线程数量越少。

本申请实施例中，当所述各接口对应的接口信息具体为：所述各接口在指定时间段内对应的平均接口响应时间以及所述各接口在指定时间段内对应的RPC请求消息接收数量时，所述分配模块11，具体用于利用如下公式为接口分配所述接口的第一服务端线程数量：

其中，所述N为所述服务器能够分配的服务端线程总数，所述C为所述服务器提供的接口总数，所述R_n为所述接口在指定时间段内对应的RPC请求消息接收数量，所述R_x为第x个接口在指定时间段内对应的RPC请求消息接收数量，所述T_n为所述接口在指定时间段内对应的平均接口响应时间，所述T_x为第x个接口在指定时间段内对应的平均接口响应时间。

本申请实施例中，当所述各接口对应的接口信息具体为：所述各接口在指定时间段内对应的平均接口响应时间以及所述各接口在指定时间段内对应的RPC请求消息接收数量时，所述分配模块11，具体用于当服务器从能够分配的服务端线程中为各接口分配能够竞争的服务端线程时，利用如下公式为接口分配所述接口的第一服务端线程数量：

其中，N为所述服务器能够分配的服务端线程总数，S为能够竞争的服务端线程的总数量，C为所述服务器提供的接口总数，R_n为所述接口在指定时间段内对应的RPC请求消息接收数量，R_x为第x个接口在指定时间段内对应的RPC请求消息接收数量，T_n为所述接口在指定时间段内对应的平均接口响应时间，T_x为第x个接口在指定时间段内对应的平均接口响应时间。

所述确定模块12，还用于当所述服务器从能够分配的服务端线程中为各接口分配能够竞争的服务端线程，且能够竞争的服务端线程的总数量为S时，如果所述第二服务端线程数量等于所述接口对应的第一服务端线程数量，则确定当前已经启动的能够竞争的服务端线程的第三服务端线程数量；

所述处理模块13，进一步用于当所述第三服务端线程数量小于所述S时，从能够竞争的服务端线程中为所述RPC请求消息启动服务端线程；当所述第三服务端线程数量等于所述S时，拒绝为所述RPC请求消息启动服务端线程。

其中，本申请装置的各个模块可以集成于一体，也可以分离部署。上述模块可以合并为一个模块，也可以进一步拆分成多个子模块。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。本领域技术人员可以理解附图只是一个优选实施例的示意图，附图中的模块或流程并不一定是实施本申请所必须的。本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分布于实施例的装置中，也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块，也可以进一步拆分成多个子模块。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。以上公开的仅为本申请的几个具体实施例，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (8)

1.一种服务端线程的动态分配方法，其特征在于，所述方法包括：

服务器利用各接口对应的接口信息分配各接口的第一服务端线程数量；

所述服务器在接收到远程过程调用RPC请求消息之后，确定所述RPC请求消息对应的接口当前已经启动的第二服务端线程数量；

如果所述第二服务端线程数量小于所述接口对应的第一服务端线程数量，则所述服务器为所述RPC请求消息启动服务端线程；

如果所述第二服务端线程数量等于所述接口对应的第一服务端线程数量，则所述服务器拒绝为所述RPC请求消息启动服务端线程；

其中，所述各接口对应的接口信息具体包括：所述各接口在指定时间段内对应的平均接口响应时间，和/或，所述各接口在指定时间段内对应的RPC请求消息接收数量；

当所述各接口对应的接口信息具体为：所述各接口在指定时间段内对应的平均接口响应时间以及所述各接口在指定时间段内对应的RPC请求消息接收数量时，所述服务器利用各接口对应的接口信息分配各接口的第一服务端线程数量的过程，具体包括：

所述服务器利用如下公式为接口分配所述接口的第一服务端线程数量：

其中，所述N为所述服务器能够分配的服务端线程总数，所述C为所述服务器提供的接口总数，所述R_n为所述接口在指定时间段内对应的RPC请求消息接收数量，所述R_x为第x个接口在指定时间段内对应的RPC请求消息接收数量，所述T_n为所述接口在指定时间段内对应的平均接口响应时间，所述T_x为第x个接口在指定时间段内对应的平均接口响应时间。

2.如权利要求1所述的方法，其特征在于，所述服务器利用各接口对应的接口信息分配各接口的第一服务端线程数量的过程，具体包括：

所述服务器利用预设第一分配策略为各接口分配对应的第一服务端线程数量；其中，所述预设第一分配策略具体为：当接口在指定时间段内对应的平均接口响应时间越小时，则所述服务器为所述接口分配的第一服务端线程数量越多；当接口在指定时间段内对应的平均接口响应时间越大时，则所述服务器为所述接口分配的第一服务端线程数量越少；或者，

所述服务器利用预设第二分配策略为各接口分配对应的第一服务端线程数量；其中，所述预设第二分配策略具体为：当接口在指定时间段内对应的RPC请求消息接收数量越多时，则所述服务器为所述接口分配的第一服务端线程数量越多；当接口在指定时间段内对应的RPC请求消息接收数量越少时，则所述服务器为所述接口分配的第一服务端线程数量越少；或者，

所述服务器利用预设第三分配策略为各接口分配对应的第一服务端线程数量；其中，所述预设第三分配策略具体为：当接口在指定时间段内对应的平均接口响应时间越小，且所述接口在指定时间段内对应的RPC请求消息接收数量越多时，为所述接口分配的第一服务端线程数量越多；当接口在指定时间段内对应的平均接口响应时间越大，且所述接口在指定时间段内对应的RPC请求消息接收数量越少时，为所述接口分配的第一服务端线程数量越少。

3.如权利要求1所述的方法，其特征在于，当所述各接口对应的接口信息具体为：所述各接口在指定时间段内对应的平均接口响应时间以及所述各接口在指定时间段内对应的RPC请求消息接收数量时，所述服务器利用各接口对应的接口信息分配各接口的第一服务端线程数量的过程，具体包括：

当服务器从能够分配的服务端线程中为各接口分配能够竞争的服务端线程时，所述服务器利用如下公式为接口分配所述接口的第一服务端线程数量：

其中，N为所述服务器能够分配的服务端线程总数，S为能够竞争的服务端线程的总数量，C为所述服务器提供的接口总数，R_n为所述接口在指定时间段内对应的RPC请求消息接收数量，R_x为第x个接口在指定时间段内对应的RPC请求消息接收数量，T_n为所述接口在指定时间段内对应的平均接口响应时间，T_x为第x个接口在指定时间段内对应的平均接口响应时间。

4.如权利要求1所述的方法，其特征在于，所述方法进一步包括：

当所述服务器从能够分配的服务端线程中为各接口分配能够竞争的服务端线程，且能够竞争的服务端线程的总数量为S时，如果所述第二服务端线程数量等于所述接口对应的第一服务端线程数量，则所述服务器确定当前已经启动的能够竞争的服务端线程的第三服务端线程数量；

如果所述第三服务端线程数量小于所述S，则所述服务器从能够竞争的服务端线程中为所述RPC请求消息启动服务端线程；如果所述第三服务端线程数量等于所述S，则所述服务器拒绝为所述RPC请求消息启动服务端线程。

5.一种服务器，其特征在于，所述服务器具体包括：

分配模块，用于利用各接口对应的接口信息分配所述各接口对应的第一服务端线程数量；

确定模块，用于在接收到远程过程调用RPC请求消息之后，确定所述RPC请求消息对应的接口当前已经启动的第二服务端线程数量；

处理模块，用于当所述第二服务端线程数量小于所述接口对应的第一服务端线程数量时，则为所述RPC请求消息启动服务端线程；

当所述第二服务端线程数量等于所述接口对应的第一服务端线程数量时，则拒绝为所述RPC请求消息启动服务端线程；

其中，所述各接口对应的接口信息具体包括：所述各接口在指定时间段内对应的平均接口响应时间，和/或，所述各接口在指定时间段内对应的RPC请求消息接收数量；

当所述各接口对应的接口信息具体为：所述各接口在指定时间段内对应的平均接口响应时间以及所述各接口在指定时间段内对应的RPC请求消息接收数量时，所述分配模块，具体用于利用如下公式为接口分配所述接口的第一服务端线程数量：

其中，所述N为所述服务器能够分配的服务端线程总数，所述C为所述服务器提供的接口总数，所述R_n为所述接口在指定时间段内对应的RPC请求消息接收数量，所述R_x为第x个接口在指定时间段内对应的RPC请求消息接收数量，所述T_n为所述接口在指定时间段内对应的平均接口响应时间，所述T_x为第x个接口在指定时间段内对应的平均接口响应时间。

6.如权利要求5所述的服务器，其特征在于，

所述分配模块，具体用于利用预设第一分配策略为各接口分配对应的第一服务端线程数量；其中，所述预设第一分配策略具体为：当接口在指定时间段内对应的平均接口响应时间越小时，则为所述接口分配的第一服务端线程数量越多；当接口在指定时间段内对应的平均接口响应时间越大时，则为所述接口分配的第一服务端线程数量越少；或者，利用预设第二分配策略为各接口分配对应的第一服务端线程数量；其中，所述预设第二分配策略具体为：当接口在指定时间段内对应的RPC请求消息接收数量越多时，则为所述接口分配的第一服务端线程数量越多；当接口在指定时间段内对应的RPC请求消息接收数量越少时，则为所述接口分配的第一服务端线程数量越少；或者，利用预设第三分配策略为各接口分配对应的第一服务端线程数量；其中，所述预设第三分配策略具体为：当接口在指定时间段内对应的平均接口响应时间越小，且所述接口在指定时间段内对应的RPC请求消息接收数量越多时，则为所述接口分配的第一服务端线程数量越多；当接口在指定时间段内对应的平均接口响应时间越大，且所述接口在指定时间段内对应的RPC请求消息接收数量越少时，则为所述接口分配的第一服务端线程数量越少。

7.如权利要求5所述的服务器，其特征在于，当所述各接口对应的接口信息具体为：所述各接口在指定时间段内对应的平均接口响应时间以及所述各接口在指定时间段内对应的RPC请求消息接收数量时，所述分配模块，具体用于当服务器从能够分配的服务端线程中为各接口分配能够竞争的服务端线程时，利用如下公式为接口分配所述接口的第一服务端线程数量：

其中，N为所述服务器能够分配的服务端线程总数，S为能够竞争的服务端线程的总数量，C为所述服务器提供的接口总数，R_n为所述接口在指定时间段内对应的RPC请求消息接收数量，R_x为第x个接口在指定时间段内对应的RPC请求消息接收数量，T_n为所述接口在指定时间段内对应的平均接口响应时间，T_x为第x个接口在指定时间段内对应的平均接口响应时间。

8.如权利要求5所述的服务器，其特征在于，

所述确定模块，还用于当所述服务器从能够分配的服务端线程中为各接口分配能够竞争的服务端线程，且能够竞争的服务端线程的总数量为S时，如果所述第二服务端线程数量等于所述接口对应的第一服务端线程数量，则确定当前已经启动的能够竞争的服务端线程的第三服务端线程数量；

所述处理模块，进一步用于当所述第三服务端线程数量小于所述S时，从能够竞争的服务端线程中为所述RPC请求消息启动服务端线程；当所述第三服务端线程数量等于所述S时，拒绝为所述RPC请求消息启动服务端线程。

Images