CN113783912B - 请求分发方法、装置及存储介质 - Google Patents

Abstract

本申请提供一种请求分发方法、装置及存储介质，此方法包括：获取待分发请求，待分发请求携带业务来源标识信息；若业务来源标识信息对应的物理机分组的负载高于预设阈值，则根据各物理机分组的负载及资源使用情况，确定目标物理机分组；将待分发请求分发给目标物理机分组中的物理机。在业务来源标识信息对应的物理机分组的负载高于预设阈值时，通过根据各物理机分组的负载及资源使用情况，来确定目标物理机分组，这样有利于负载均衡，从而可以有效提升服务响应速率。

Description

请求分发方法、装置及存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种请求分发方法、装置及存储介质。

背景技术

在电商应用内，为了解决服务器中请求调用量超高的问题，分层级的应用系统会将请求的用途及来源作为分发请求的依据，并且会给具备相同特征的接口调用行为配置相同的物理机分组，比如，将商品详情或商品系统的接口调用行为配置到商品分组，清结算系统的接口调用行为配置到结算分组，等等。

上述技术的局限性在于需根据请求的用途及来源手动配置物理机分组。在固定物理机分组的环境下，对于诸多相同请求来源的数据读写，容易导致大量请求堆积到单个物理机分组，如果手动配置不及时，会导致服务响应速率低下。

发明内容

本申请提供一种请求分发方法、装置及存储介质，以有效提升服务响应速率。

第一方面，本申请提供一种请求分发方法，包括：

获取待分发请求，待分发请求携带业务来源标识信息；

若业务来源标识信息对应的物理机分组的负载高于预设阈值，则根据各物理机分组的负载及资源使用情况，确定目标物理机分组；

将待分发请求分发给所述目标物理机分组中的物理机。

在一种可能的实施方式中，上述根据各物理机分组的负载及资源使用情况，确定目标物理机分组，包括：

确定各物理机分组处理待分发请求所消耗的资源量；

根据各物理机分组的负载及其对应的资源量、资源使用情况，确定目标物理机分组。

在一种可能的实施方式中，上述确定各物理机分组处理所述待分发请求所消耗的资源量，包括：

获取待分发请求在物理机分组中各物理机上运行时的性能下降时长；

根据物理机分组中各物理机的性能下降时长，确定物理机分组对应的性能下降平均时长；

根据物理机分组对应的性能下降平均时长，确定物理机分组处理待分发请求所消耗的资源量。

在一种可能的实施方式中，上述获取待分发请求在物理机分组中各物理机上运行时的性能下降时长，包括：

根据影响因子及物理机在前一周期内资源利用率超过预设资源利用率时的性能下降时间，确定待分发请求在物理机分组中各物理机上运行时的性能下降时长，其中，影响因子是根据物理机的请求响应时间和物理机的可用率确定的，物理机的可用率用于指示物理机在单位时间内成功处理请求的占比。

在一种可能的实施方式中，请求分发方法还包括：

监听物理机的资源使用情况；

将当前次监听时物理机的资源使用情况，与对应的缓存区域中存储的物理机的资源使用情况进行比较，得到物理机的资源变化；

若资源变化在预设范围之外，则将缓存区域中存储的物理机的资源使用情况更新为当前次监听得到的物理机的资源使用情况。

在一种可能的实施方式中，请求分发方法还包括：

若业务来源标识信息对应的物理机分组的负载低于预设阈值，则将待分发请求分发给业务来源标识信息对应的物理机分组中的物理机。

第二方面，本申请提供一种请求分发装置，包括：

获取模块，用于获取待分发请求，待分发请求携带业务来源标识信息；

处理模块，用于在业务来源标识信息对应的物理机分组的负载高于预设阈值时，根据各物理机分组的负载及资源使用情况，确定目标物理机分组；

发送模块，用于将所述待分发请求分发给所述目标物理机分组中的物理机。

在一种可能的实施方式中，处理模块具体用于：

确定各物理机分组处理待分发请求所消耗的资源量；

根据各物理机分组的负载及其对应的资源量、资源使用情况，确定目标物理机分组。

在一种可能的实施方式中，处理模块在用于确定各物理机分组处理待分发请求所消耗的资源量时，具体用于：

获取待分发请求在物理机分组中各物理机上运行时的性能下降时长；

根据物理机分组中各物理机的性能下降时长，确定物理机分组对应的性能下降平均时长；

根据物理机分组对应的性能下降平均时长，确定物理机分组处理待分发请求所消耗的资源量。

在一种可能的实施方式中，处理模块在用于获取待分发请求在物理机分组中各物理机上运行时的性能下降时长时，具体用于：

根据影响因子及物理机在前一周期内资源利用率超过预设资源利用率时的性能下降时间，确定待分发请求在所述物理机分组中各物理机上运行时的性能下降时长，其中，影响因子是根据物理机的请求响应时间和物理机的可用率确定的，物理机的可用率用于指示物理机在单位时间内成功处理请求的占比。

在一种可能的实施方式中，处理模块还用于：

监听物理机的资源使用情况；

将当前次监听时物理机的资源使用情况，与对应的缓存区域中存储的物理机的资源使用情况进行比较，得到物理机的资源变化；

若资源变化在预设范围之外，则将缓存区域中存储的物理机的资源使用情况更新为当前次监听得到的物理机的资源使用情况。

在一种可能的实施方式中，处理模块还用于：

若业务来源标识信息对应的物理机分组的负载低于预设阈值，则触发发送模块将待分发请求分发给所述业务来源标识信息对应的物理机分组中的物理机。

第三方面，本申请提供一种通信设备，包括：存储器和处理器；

存储器用于存储程序指令；

处理器用于调用存储器中的程序指令以执行如第一方面任一项所述的方法。

第四方面，本申请提供一种通信系统，包括：客户端、分发服务器和物理机分组，其中，物理机分组包括至少一物理机；其中：

客户端，用于发送请求给分发服务器；

分发服务器，用于执行如第一方面任一项所述的方法；

物理机，用于处理请求，并将处理结果发送给客户端。

第五方面，本申请提供一种可读存储介质，可读存储介质上存储有计算机程序；计算机程序被执行时，实现如第一方面任一项所述的方法。

第六方面，本申请还提供一种程序产品，程序产品包括计算机程序，计算机程序存储在可读存储介质中，处理器可以从可读存储介质中读取计算机程序，处理器执行计算机程序实现如第一方面任一项所述的方法。

本申请提供一种请求分发方法、装置及存储介质，此方法包括：获取待分发请求，该待分发请求携带业务来源标识信息；若业务来源标识信息对应的物理机分组的负载高于预设阈值，则根据各物理机分组的负载及资源使用情况，确定目标物理机分组；将待分发请求分发给目标物理机分组中的物理机。在业务来源标识信息对应的物理机分组的负载高于预设阈值时，通过根据各物理机分组的负载及资源使用情况，来确定目标物理机分组，这样有利于负载均衡，从而可以有效提升服务响应速率。

附图说明

图1是本申请提供的通信系统的一示意图；

图2为本申请一实施例提供的请求分发方法的流程示意图；

图3为本申请另一实施例提供的请求分发方法的流程示意图；

图4为本申请又一实施例提供的请求分发方法的流程示意图；

图5为本申请一实施例提供的请求分发装置的结构示意图；

图6为本申请一实施例提供的通信设备的结构示意图。

具体实施方式

应当理解，本申请实施例中涉及的“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。

在介绍本申请的技术方案之前，首先结合本申请的一个具体应用场景引出现有技术存在的问题以及本申请的技术构思过程。

在电商应用内，为了解决服务器中请求调用量超高的问题，分层级的应用系统会将请求的用途及来源作为分发请求的依据，并且会给具备相同特征的接口调用行为分配相同的物理机分组，比如给商品详情或商品系统的接口调用行为配置到商品分组，清结算系统的调用接口行为配置到结算分组等。该技术的局限性在于需要根据请求的用途及来源手动配置物理机分组，并且仅能通过手动追加动态别名的方式进行手动分流。服务提供方根据调用情况进行权重分配之后才会进行分发，所以请求来源在服务接口调用的过程中影响响应速度的权重很大。例如，调用方的所有请求会分发到固定的多台物理机中，在调用量突增并且持续居高不下的情形下，容易导致大量请求堆积到单个物理机分组，如果手动配置不及时，会导致服务响应速率低下，导致服务不可用情况增多，调用方体验变差。示例地，在大促时，对于清结算和商品详情这类请求，明显地，用户在短期内会进行高频次调用，因此，服务分组过载之后只会对客户端产生不良体验。

因此，本申请提供一种请求分发方法、装置及存储介质，为客户端提供灵活的、按需分配的接口服务，具体通过动态结合现有系统资源，将负载情况考虑到请求分发方法中，进而对请求分发方案进行修正，保证请求分发到最适宜、响应最迅速的业务处理服务器，有效提升服务响应速率，以确保客户端的调用体验。

值得说明的是，在本申请的实施例中，该请求分发方法是将用户在客户端触发的请求，由分发服务器分发至具体的业务处理服务器的过程。

示例性的，图1是本申请提供的通信系统的一示意图。如图1所示，该应用场景可以包括：至少一个客户端(图1示出了三个客户端，分别为客户端111、客户端112、客户端113)、分发服务器12和业务处理服务器13。其中，每个客户端与分发服务器12可以通过网络进行通信，分发服务器12与业务处理服务器13也可以通过网络进行通信。

示例地，当用户通过客户端111浏览电商平台时，例如，可通过客户端111中已安装的电商APP浏览电商平台，客户端111基于用户行为通过网络向分发服务器12发送请求，分发服务器12可以根据请求携带的业务来源标识信息及物理机分组的负载情况，确定目标物理机分组，并进一步通过网络将请求分发至目标物理机分组中的一业务处理服务器13，由该业务处理服务器13对其进行处理。

其中，用户行为包括但不限于商品购买行为、将商品添加至购物车的行为、浏览商品详情的行为、生成订单的行为、结算行为，等等。以浏览商品详情的行为为例，用户要浏览某一手机的详情，则用户点击商品页面中的“详情”，响应于用户的点击行为，客户端111通过网络发送请求给分发服务器12，分发服务器12可以根据请求携带的业务来源标识信息及物理机分组的负载情况，确定目标物理机分组，并进一步通过网络将请求分发至目标物理机分组中的一业务处理服务器13，由该业务处理服务器13对该请求进行响应，发送详情页面给客户端111，由客户端111展示上述详情页面给用户，以供用户查看。

需要说明的是，图1仅是本申请实施例提供的一种应用场景的示意图，本申请实施例不对图1中包括的设备进行限定，也不对图1中设备之间的位置关系进行限定。例如，在图1所示的应用场景中，还可以包括数据存储设备，该数据存储设备相对分发服务器12和/或业务处理服务器13可以是外部存储器，也可以是集成在分发服务器12和/或业务处理服务器13中的内部存储器。另外，分发服务器12和业务处理服务器13可以是独立的服务器，或者，也可以是服务集群等。

下面，通过具体实施例对本申请的技术方案进行详细说明。需要说明的是，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图2为本申请一实施例提供的请求分发方法的流程示意图。该方法以图1所示通信系统中的分发服务器作为执行主体进行解释说明。需明确，本申请实施例提供的请求分发方法的执行主体不以分发服务器为限制，只要是具备一定算力的通信设备，均可作为执行主体。

如图2所示，该方法包括如下步骤：

S201、获取待分发请求，待分发请求携带业务来源标识信息。

实际应用中，客户端发送请求给分发服务器，由分发服务器进行请求的分发。其中，客户端的个数为至少一个。至于请求，可以是一个客户端发送的至少一个请求，也可以是多个客户端发送的多个请求。例如，多个客户端同时发送请求给分发服务器。

示例地，在大促时，存在多个客户端同时发送用于结算的请求的情况，此时，分发服务器会同时接受到多个请求。分发服务器可以同时处理多个请求。但考虑到分发服务器处理能力有限，当请求个数特别多，超过分发服务器的处理能力时，分发服务器可以按照先入先出的形式将请求存入堆栈，这样，分发服务器可以依据其处理能力，从堆栈中获取待分发请求。需说明的是，上述将请求存入堆栈的方式仅为示例说明，本申请实施例不以此为限制。

S202、若业务来源标识信息对应的物理机分组的负载高于预设阈值，则根据各物理机分组的负载及资源使用情况，确定目标物理机分组。

其中，待分发请求携带业务来源标识信息，不同的业务来源标识信息对应有不同的物理机分组，也就是说，客户端发送的待分发请求和物理机分组之间存在映射关系。因此，通过业务来源标识信息可以确定处理对应请求的物理机分组。但本申请考虑到负载均衡的问题，在确定目标物理机分组之前，还要判断业务来源标识信息对应的物理机分组的负载情况，只有当业务来源标识信息对应的物理机分组的负载高于预设阈值时，才会根据各物理机分组的负载及资源使用情况，确定目标物理机分组。

该步骤中，分发服务器在分发请求时，结合各物理机分组的负载及资源使用情况，来确定目标物理机分组，从而避免大量请求堆积到单个物理机分组所导致的服务响应速率低下的问题，保证请求分发到响应较迅速的物理机分组。

需要说明的是，预设阈值可根据历史经验或者实际需求进行设置，此处不予限制。

可选地，该步骤可以替换为：确定业务来源标识信息对应的物理机分组的负载高于预设阈值；根据各物理机分组的负载及资源使用情况，确定目标物理机分组。

S203、将待分发请求分发给目标物理机分组中的物理机。

其中，物理机分组可包括至少一个物理机，也即业务处理服务器。业务处理服务器是指具体处理请求的服务器，业务处理服务器在对请求进行处理之后，反馈处理结果给对应的客户端。

在确定目标物理机分组之后，分发服务器可以通过多种实现方式进行请求的分发。例如，一种实现方式中，分发服务器在该目标物理机分组中随机选择一个物理机进行请求的分发；或者，另一种实现方式中，分发服务器在该目标物理机分组中选择满足预设条件的物理机进行请求的分发，等等。其中预设条件可以是业务处理服务器中没有请求在排队，或业务处理服务器处于空闲状态，即没有请求在处理。

本申请实施例的请求分发方法，首先获取待分发请求，待分发请求携带业务来源标识信息；之后，若业务来源标识信息对应的物理机分组的负载高于预设阈值，则根据各物理机分组的负载及资源使用情况，确定目标物理机分组，并将待分发请求分发给目标物理机分组中的物理机。在业务来源标识信息对应的物理机分组的负载高于预设阈值时，通过根据各物理机分组的负载及资源使用情况，来确定目标物理机分组，这样有利于负载均衡，从而可以有效提升服务响应速率。

一些实施例中，若业务来源标识信息对应的物理机分组的负载低于预设阈值，则将待分发请求分发给业务来源标识信息对应的物理机分组中的物理机。

如图3所示，该请求分发方法可以包括：

S301、获取待分发请求，待分发请求携带业务来源标识信息。

该步骤与S201类似，此处不再赘述。

S302、确定业务来源标识信息对应的物理机分组的负载是否高于预设阈值。

若业务来源标识信息对应的物理机分组的负载高于预设阈值，则执行S303；若业务来源标识信息对应的物理机分组的负载低于预设阈值，则执行S305。

S303、根据各物理机分组的负载及资源使用情况，确定目标物理机分组。

S304、将待分发请求分发给目标物理机分组中的物理机。

该步骤与S203类似，此处不再赘述。

S305、将待分发请求分发给业务来源标识信息对应的物理机分组中的物理机。

本实施例，在根据各物理机分组的负载及资源使用情况，确定目标物理机分组之前，首先确定业务来源标识信息对应的物理机分组的负载是否高于预设阈值，只有在业务来源标识信息对应的物理机分组的负载高于预设阈值时，才根据各物理机分组的负载及资源使用情况，确定目标物理机分组；在业务来源标识信息对应的物理机分组的负载低于预设阈值时，将待分发请求分发给业务来源标识信息对应的物理机分组中的物理机，也即按照现有的请求分发流程进行请求的分发。通过实时分析各物理机分组的负载动态，得到请求能够被分配的最佳物理机分组。

在上述实施例的基础上，可选地，根据各物理机分组的负载及资源使用情况，确定目标物理机分组，可以包括：确定各物理机分组处理待分发请求所消耗的资源量；根据各物理机分组的负载及其对应的资源量、资源使用情况，确定目标物理机分组。

由于各物理机分组所包含的物理机的个数、硬件条件及资源使用情况存在差异，对于同一请求，不同物理机分组在对其进行处理时所消耗的资源量是不同的，因此，在确定目标物理机分组时，可以先确定各物理机分组处理待分发请求所消耗的资源量，进一步根据各物理机分组的负载及其对应的资源量、资源使用情况来确定目标物理机分组。例如，可以通过计算公式得到每个物理机分组在下一个时段或周期的负载情况。示例地，以分钟为单位，一个时段或周期约定为1分钟。

一种具体实现中，确定各物理机分组处理待分发请求所消耗的资源量，可以包括：获取待分发请求在物理机分组中各物理机上运行时的性能下降时长；根据物理机分组中各物理机的性能下降时长，确定物理机分组对应的性能下降平均时长；根据物理机分组对应的性能下降平均时长，确定物理机分组处理待分发请求所消耗的资源量。

示例地，通过以下公式获取待分发请求在物理机分组中各物理机上运行时的性能下降时长：

其中，T_j表示服务器j在前一个周期内资源利用率超过预设资源利用率时导致服务器j整体性能下降的时间；Sum(i)表示待分发请求i在某一物理机分组的N台物理机上运行时性能下降的总时长；E(i)表示物理机分组对应的性能下降平均时长。

结合每个分组上服务器的各项指标及其在正常状态下能够承担的负载范围，得到与计算结果差值最大的服务器即为可用负载机器，保证每个请求都有一个量身定制的分组和机器，打破了传统固定分组和手动切换的禁锢。

进一步地，获取待分发请求在物理机分组中各物理机上运行时的性能下降时长，可以包括：根据影响因子及物理机在前一周期内资源利用率超过预设资源利用率时的性能下降时间，确定待分发请求在物理机分组中各物理机上运行时的性能下降时长。其中，影响因子是根据物理机的请求响应时间和物理机的可用率确定的，物理机的可用率用于指示物理机在单位时间内成功处理请求的占比。结合影响因子进行分发结果的修正更新，一定程度上以保证分发结果不堆积，既能确保下游客户端的调用体验，又能提高响应速度。

可选地，影响因子的取值范围为(0,1)。

图4为本申请又一实施例提供的请求分发方法的流程示意图。参考图4，该请求分发方法可以包括以下步骤：

S401、监听物理机的资源使用情况。

S402、将当前次监听时物理机的资源使用情况，与对应的缓存区域中存储的物理机的资源使用情况进行比较，得到物理机的资源变化。

S403、若资源变化在预设范围之外，则将缓存区域中存储的物理机的资源使用情况更新为当前次监听得到的物理机的资源使用情况。

分发服务器上电开机后，初始化物理机分组信息和物理机分组内各物理机的资源信息存储到缓存区域，分发服务器实时监听各物理机分组中物理机的资源使用情况及资源变化，以为能够进行快速的分析做准备。

其中，资源的使用情况包括以下两种情况：

第一种情况，如果资源变化在合理的区间，即资源变化在预设范围之内，则不做任何操作，不更新缓存区域的内容；

第二种情况，如果资源变化不在合理的区间，即资源变化在预设范围之内，则抽取资源数据，如内存、磁盘空间、CPU等，存储到缓存区域，也就是将缓存区域中存储的物理机的资源使用情况更新为当前次监听得到的物理机的资源使用情况。

另需说明的是，本申请不限制S401至S403与上述实施例中各步骤之间的执行顺序。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图5为本申请一实施例提供的请求分发装置的结构示意图。本申请实施例提供一种请求分发装置，该装置可以集成在例如服务器等通信设备上，或该装置可以集成在通信设备的芯片上，或该装置也可以是通信设备。如图5所示，请求分发装置50包括：获取模块51、处理模块52和发送模块53。其中：

获取模块51，用于获取待分发请求。其中，待分发请求携带业务来源标识信息。

处理模块52，用于在业务来源标识信息对应的物理机分组的负载高于预设阈值时，根据各物理机分组的负载及资源使用情况，确定目标物理机分组。

发送模块53，用于将待分发请求分发给目标物理机分组中的物理机。

一种具体实现中，处理模块52可具体用于：

确定各物理机分组处理待分发请求所消耗的资源量；

根据各物理机分组的负载及其对应的资源量、资源使用情况，确定目标物理机分组。

进一步地，处理模块52在用于确定各物理机分组处理待分发请求所消耗的资源量时，具体用于：

获取待分发请求在物理机分组中各物理机上运行时的性能下降时长；

根据物理机分组中各物理机的性能下降时长，确定物理机分组对应的性能下降平均时长；

根据物理机分组对应的性能下降平均时长，确定物理机分组处理待分发请求所消耗的资源量。

一些实施例中，处理模块52在用于获取待分发请求在物理机分组中各物理机上运行时的性能下降时长时，可具体用于：根据影响因子及物理机在前一周期内资源利用率超过预设资源利用率时的性能下降时间，确定待分发请求在物理机分组中各物理机上运行时的性能下降时长。其中，影响因子是根据物理机的请求响应时间和物理机的可用率确定的，物理机的可用率用于指示物理机在单位时间内成功处理请求的占比。

在上述基础上，处理模块52还可以用于：

监听物理机的资源使用情况；

将当前次监听时物理机的资源使用情况，与对应的缓存区域中存储的物理机的资源使用情况进行比较，得到物理机的资源变化；

若资源变化在预设范围之外，则将缓存区域中存储的物理机的资源使用情况更新为当前次监听得到的物理机的资源使用情况。

可选地，处理模块52还用于：在业务来源标识信息对应的物理机分组的负载低于预设阈值时，触发发送模块53将待分发请求分发给业务来源标识信息对应的物理机分组中的物理机。

需要说明的是，应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。例如，处理模块可以为单独设立的处理元件，也可以集成在上述装置的某一个芯片中实现，此外，也可以以程序代码的形式存储于上述装置的存储器中，由上述装置的某一个处理元件调用并执行以上处理模块的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

例如，以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(Application Specific Integrated Circuit，简称ASIC)，或，一个或多个微处理器(Digital Signal Processor，简称DSP)，或，一个或者多个现场可编程门阵列(Field Programmable Gate Array，简称FPGA)等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(Central Processing Unit，简称CPU)或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统(System-On-a-Chip，简称SOC)的形式实现。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘solid state disk(SSD))等。

图6为本申请一实施例提供的通信设备的结构示意图。如图6所示，该通信设备可以包括：处理器61、存储器62、通信接口63和系统总线64。其中，存储器62和通信接口63通过系统总线64与处理器61连接并完成相互间的通信，存储器62用于存储程序指令，通信接口63用于和其他设备进行通信，处理器61用于调用存储器中的程序指令以执行如上述方法实施例所述的方案。

该图6中提到的系统总线可以是外设部件互连标准(Peripheral ComponentInterconnect，简称PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture，简称EISA)总线等。该系统总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。通信接口用于实现数据库访问装置与其他设备(例如客户端、读写库和只读库)之间的通信。存储器可能包含随机存取存储器(Random Access Memory，简称RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

上述的处理器可以是通用处理器，包括中央处理器、网络处理器(NetworkProcessor，简称NP)等；还可以是数字信号处理器DSP、专用集成电路ASIC、现场可编程门阵列FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

如图1所示例，本申请实施例还提供一种通信系统，包括：客户端、分发服务器和物理机分组，其中，物理机分组包括至少一物理机；其中：

客户端，用于发送请求给分发服务器；

分发服务器，用于执行如上述方法实施例所述的方法；

物理机，用于处理请求，并将处理结果发送给客户端。

可选的，本申请实施例还提供一种可读存储介质，可读存储介质中存储有计算机程序，计算机程序被执行时，实现如上述方法实施例所述的方法。

可选的，本申请实施例还提供一种运行指令的芯片，所述芯片用于执行上述方法实施例所述的方法。

本申请实施例还提供一种程序产品，该程序产品包括计算机程序，该计算机程序存储在可读存储介质中，至少一个处理器可以从该可读存储介质中读取计算机程序，该至少一个处理器执行所述计算机程序时可实现上述方法实施例所述的方法。

本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系；在公式中，字符“/”，表示前后关联对象是一种“相除”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a-b，a-c，b-c，或a-b-c，其中，a，b，c可以是单个，也可以是多个。

可以理解的是，在本申请的实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本申请的实施例的范围。在本申请的实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请的实施例的实施过程构成任何限定。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (9)

1.一种请求分发方法，其特征在于，包括：

获取待分发请求，所述待分发请求携带业务来源标识信息；

若所述业务来源标识信息对应的物理机分组的负载高于预设阈值，则根据所述待分发请求在各物理机分组中的各物理机上处理时的性能下降时长，确定各物理机分组处理所述待分发请求所消耗的资源量；所述性能下降时长根据影响因子和物理机在前一周期内资源利用率超过预设资源利用率时的性能下降时间确定，所述影响因子根据物理机的请求响应时间和物理机的可用率确定，所述物理机的可用率用于指示物理机在单位时间内成功处理请求的占比；

根据各物理机分组对应的所述资源量、资源使用情况及基于预设公式得到的各物理机分组在下一时段或下一周期的负载，确定目标物理机分组；

将所述待分发请求分发给所述目标物理机分组中的物理机。

2.根据权利要求1所述的方法，其特征在于，所述根据所述待分发请求在各物理机分组中的各物理机上处理时的性能下降时长，确定各物理机分组处理所述待分发请求所消耗的资源量，包括：

获取所述待分发请求在各物理机分组中的各物理机上处理时的性能下降时长；

根据各物理机分组中的各物理机的性能下降时长，确定各物理机分组对应的性能下降平均时长；

根据各物理机分组对应的性能下降平均时长，确定各物理机分组处理所述待分发请求所消耗的资源量。

3.根据权利要求1或2所述的方法，其特征在于，还包括：

监听物理机的资源使用情况；

将当前次监听时物理机的资源使用情况，与对应的缓存区域中存储的物理机的资源使用情况进行比较，得到物理机的资源变化；

若所述资源变化在预设范围之外，则将缓存区域中存储的物理机的资源使用情况更新为当前次监听得到的物理机的资源使用情况。

4.根据权利要求1或2所述的方法，其特征在于，还包括：

若所述业务来源标识信息对应的物理机分组的负载低于预设阈值，则将所述待分发请求分发给所述业务来源标识信息对应的物理机分组中的物理机。

5.一种请求分发装置，其特征在于，包括：

获取模块，用于获取待分发请求，所述待分发请求携带业务来源标识信息；

处理模块，用于在所述业务来源标识信息对应的物理机分组的负载高于预设阈值时，根据所述待分发请求在各物理机分组中的各物理机上处理时的性能下降时长，确定各物理机分组处理所述待分发请求所消耗的资源量；所述性能下降时长根据影响因子和物理机在前一周期内资源利用率超过预设资源利用率时的性能下降时间确定，所述影响因子根据物理机的请求响应时间和物理机的可用率确定，所述物理机的可用率用于指示物理机在单位时间内成功处理请求的占比；根据各物理机分组对应的所述资源量、资源使用情况及基于预设公式得到的各物理机分组在下一时段或下一周期的负载，确定目标物理机分组；

发送模块，用于将所述待分发请求分发给所述目标物理机分组中的物理机。

6.一种通信设备，其特征在于，包括：存储器和处理器；

所述存储器用于存储程序指令；

所述处理器用于调用所述存储器中的程序指令以执行如权利要求1至4中任一项所述的方法。

7.一种通信系统，其特征在于，包括：客户端、分发服务器和物理机分组，其中，所述物理机分组包括至少一物理机；其中：

所述客户端，用于发送请求给所述分发服务器；

所述分发服务器，用于执行如权利要求1至4中任一项所述的方法；

所述物理机，用于处理所述请求，并将处理结果发送给所述客户端。

8.一种可读存储介质，其特征在于，所述可读存储介质上存储有计算机程序；所述计算机程序被执行时，实现如权利要求1至4中任一项所述的方法。

9.一种计算机程序产品，包括：计算机程序，其特征在于，所述计算机程序被处理器执行时用于实现如权利要求1至4任一项所述的方法。