CN113988582A - 下单资源分配方法、装置、存储介质以及电子设备 - Google Patents

Abstract

本发明公开了一种下单资源分配方法、装置、存储介质以及电子设备。该方法包括：接收客户端发送的下单请求；确定下单请求对应的目标渠道商；获取目标渠道商的目标资源配额和目标性能阈值；在下单请求所需要的资源值小于或等于目标资源配额的情况下，且下单请求所需要的响应时间小于或等于目标性能阈值的情况下，允许下单；在下单请求所需要的资源值大于目标资源配额的情况下，或者下单请求所需要的响应时间大于目标性能阈值的情况下，拒绝下单。本发明解决了某个渠道商接口性能影响整个下单服务的技术问题。

Description

下单资源分配方法、装置、存储介质以及电子设备

技术领域

本发明涉及计算机领域，具体而言，涉及一种下单资源分配方法、装置、存储介质以及电子设备。

背景技术

现有技术中，在渠道商进行下单时，由于未对渠道商的下单进行限制，因此，渠道商的下单请求数量可能超出***的最大服务处理量，或者接口的占用时长超出***接口的服务时长，不仅造成***无法处理该下单请求，而且会影响其他渠道商的下单请求，当出现大量性能较慢的下单请求时，会极大的消耗***服务器的资源，甚至造成宕机，在***服务器总资源有限、不能处理太多多并发业务的前提下，影响尤甚。

发明内容

本发明实施例提供了一种下单资源分配方法、装置、存储介质以及电子设备，以至少解决某个渠道商接口性能影响整个下单服务的技术问题。

根据本发明实施例的一个方面，提供了一种下单资源分配方法，包括：接收客户端发送的下单请求；确定上述下单请求对应的目标渠道商；获取上述目标渠道商的目标资源配额和目标性能阈值；在上述下单请求所需要的资源值小于或等于上述目标资源配额的情况下，且上述下单请求所需要的响应时间小于或等于上述目标性能阈值的情况下，允许下单；在上述下单请求所需要的资源值大于上述目标资源配额的情况下，或者上述下单请求所需要的响应时间大于上述目标性能阈值的情况下，拒绝下单。

作为一种可选的示例，为所述目标渠道商分配所述目标资源配额包括：确定接收所述下单请求的下单服务器在单位时间段内能够处理的下单请求的最大值；按照预定比例，将所述最大值分配给多个渠道商，其中，所述多个渠道商中包括所述目标渠道商，每一个所述运行商对应一个所述预定比例。

根据本发明实施例的另一方面，提供了一种下单资源分配装置，包括：接收模块，用于接收客户端发送的下单请求；确定模块，用于确定上述下单请求对应的目标渠道商；获取模块，用于获取上述目标渠道商的目标资源配额和目标性能阈值；第一处理模块，用于在上述下单请求所需要的资源值小于或等于上述目标资源配额的情况下，且上述下单请求所需要的响应时间小于或等于上述目标性能阈值的情况下，允许下单；第二处理模块，用于在上述下单请求所需要的资源值大于上述目标资源配额的情况下，或者上述下单请求所需要的响应时间大于上述目标性能阈值的情况下，拒绝下单。

作为一种可选的示例，所述分配模块包括：第一确定单元，用于确定接收所述下单请求的下单服务器在单位时间段内能够处理的下单请求的最大值；第一分配单元，用于按照预定比例，将所述最大值分配给多个渠道商，其中，所述多个渠道商中包括所述目标渠道商，每一个所述运行商对应一个所述预定比例。

根据本发明实施例的又一方面，还提供了一种存储介质，该存储介质中存储有计算机程序，其中，该计算机程序被处理器运行时执行上述下单资源分配方法。

根据本发明实施例的又一方面，还提供了一种电子设备，包括存储器和处理器，上述存储器中存储有计算机程序，上述处理器被设置为通过上述计算机程序执行上述的下单资源分配方法。

根据本发明实施例的又一方面，还提供了一种应用于C2M模式的下单资源分配设备，该下单资源分配设备包括如前述根据本发明实施例的另一方面的一种下单资源分配装置。

根据本发明实施例的又一方面，还提供了一种应用于C2M模式的电商平台服务器，该电商平台服务器包括如前述根据本发明实施例的另一方面的一种下单资源分配装置。

在本发明实施例中，采用了接收客户端发送的下单请求，确定上述下单请求对应的目标渠道商；获取上述目标渠道商的目标资源配额和目标性能阈值；在上述下单请求所需要的资源值小于或等于上述目标资源配额的情况下，且上述下单请求所需要的响应时间小于或等于上述目标性能阈值的情况下，允许下单；在上述下单请求所需要的资源值大于上述目标资源配额的情况下，或者上述下单请求所需要的响应时间大于上述目标性能阈值的情况下，拒绝下单的方法，由于在上述方法中，通过为渠道商分配资源配额和性能阈值的方法，从而可以通过为渠道商分配的资源配额和性能阈值来对渠道商的下单动作进行约束，实现了对渠道商下单的资源限制和接口响应时间进行限制的目的，进而解决了某个渠道商接口性能影响整个下单服务的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的一种可选的下单资源分配方法的流程图；

图2是根据本发明实施例的一种可选的下单资源分配方法的资源配额分配图；

图3是根据本发明实施例的一种可选的下单资源分配方法的数据采集分析中心的示意图；

图4是根据本发明实施例的一种可选的下单资源分配方法的计算健康评分的示意图；

图5是根据本发明实施例的一种可选的下单资源分配方法的计算健康值的示意图；

图6是根据本发明实施例的一种可选的下单资源分配方法的健康值与资源配额映射图；

图7是根据本发明实施例的一种可选的下单资源分配方法的性能阈值分配图；

图8是根据本发明实施例的一种可选的下单资源分配方法的健康值与性能阈值映射图；

图9是根据本发明实施例的一种可选的下单资源分配方法的下单校验图；

图10是根据本发明实施例的一种可选的下单资源分配装置的结构示意图；

图11是根据本发明实施例的一种可选的电子设备的示意图。

具体实施方式

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

根据本发明实施例的第一方面，提供了一种下单资源分配方法，可选地，如图1所示，上述方法包括：

S102，接收客户端发送的下单请求；

S104，确定下单请求对应的目标渠道商；

S106，获取目标渠道商的目标资源配额和目标性能阈值；

S108，在下单请求所需要的资源值小于或等于目标资源配额的情况下，且下单请求所需要的响应时间小于或等于目标性能阈值的情况下，允许下单；

S110，在下单请求所需要的资源值大于目标资源配额的情况下，或者下单请求所需要的响应时间大于目标性能阈值的情况下，拒绝下单。

可选地，本实施例中的客户端可以为完成签约的外部应用APP或小程序等，外部应用APP或小程序内可集成商城***平台的SDK，通过SDK，外部应用APP或小程序可以直接访问商城***平台，从而进行下单。例如，在渠道商A完成签约后，在渠道商A的应用程序中集成商城***平台SDK，用户在下载该渠道商的应用程序后，通过该应用程序来直接访问商城***平台进行下单。下单请求可以为向商城***平台的服务器发送的，用于下单购物的请求，目标渠道商为外部应用(客户端)的所属方，用户通过目标渠道商的客户端向商城***平台的服务器发送下单请求进行购物。在此，渠道商的客户端是指接入同一商城对应的商城***平台的SDK、以形成渠道商的自身商城、用户可在其上面进行商品下单的第三方平台，如第三方APP、第三方小程序等。在此，可以理解的是，渠道商自身商城中的商品来源于其接入的商城，且该商城可接入多个不同渠道商的客户端，用户在渠道商的自身商城进行商品下单时，虽然商品来源于其接入的商城，但用户并不感知，而是认为所下单商品是渠道商自身售卖的商品。当用户通过渠道商的自身商城进行购买商品的操作时，向商城***平台发送对商品的下单请求，商城***平台接收用户通过渠道商的自身商城对商品的下单请求。

可选地，本实施例中，可以包括多个渠道商和用于提供商城***平台服务的服务器，多个渠道商的每一个渠道商可以产生下单请求，然后将下单请求发送给服务器，由服务器进行处理。每一个渠道商都可以对应一个资源配额和性能阈值，资源配额用于限制单位时间内能够发送到服务器、由服务器处理的下单请求的数量，性能阈值用于限制调用接口的最大时长。当多个渠道商中的目标渠道商向服务器发送一个下单请求的时候，服务器可以获取该目标渠道商的目标资源配额和目标性能阈值，然后，判断下单请求所需要的资源值和目标资源配额的关系，以及判断下单请求所需要的响应时间和目标性能阈值的关系，如果下单请求所需要的资源值小于或等于目标资源配额，而且下单请求所需要的响应时间小于或等于目标性能阈值，则允许下单，如果所需要的资源值大于目标资源配额，或者下单请求所需要的响应时间大于目标性能阈值，则不允许下单。

作为一种可选的示例，在获取目标渠道商的目标资源配额和目标性能阈值之前，还包括：

为目标渠道商分配目标资源配额和目标性能阈值。

可选地，在实施例中为目标渠道商分配的目标资源配额可以为渠道商的单位时间段内下单请求数量的最大值，但不能超过服务器的处理极限值，目标性能阈值可以为经渠道商发送下单请求时调用接口所需要的最大时长，但不能超过服务器整体接收下单请求调用接口的最大时长，每个渠道商对应一个资源配额和性能阈值。为渠道商分配资源配额和性能阈值时，可以根据渠道商的不同，为不同的渠道商分配不同的资源配额和性能阈值。例如，可以根据历史经验值为资源配额和性能阈值来分配资源配额和性能阈值，例如，以一天的数据为依据，该一天的数据中，某一个渠道商的下单次数和每一次下单时的占用接口的平均时长作为资源配额和性能阈值的初始值。

作为一种可选的示例，为目标渠道商分配目标资源配额包括：

确定接收下单请求的下单服务器在单位时间段内能够处理的下单请求的最大值；

按照预定比例，将最大值分配给多个渠道商，其中，多个渠道商中包括目标渠道商，每一个渠道商对应一个预定比例。

可选地，在实施例中对服务器整体下单能力进行评估，确定单位时间内处理下单请求次数的最大值，根据每个渠道商的健康值动态设定的预定比例，分配给每个渠道商对应的资源配额，单个渠道商的资源配额和所有渠道商资源配额总和不能超过服务器整体资源值。例如，当单位时间内处理下单请求次数的最大值为2000，则单位时间内，所有渠道商的资源配额的和不能超过2000。可以将2000按照比例分配给不同的渠道商，如渠道商A占800，渠道商B占1200，则单位时间内，渠道商A最高可以发送800个下单请求，渠道商B最高可以发送1200个下单请求。

作为一种可选的示例，为目标渠道商分配目标性能阈值包括：

获取整体性能阈值，其中，整体性能阈值为用于接收下单请求的接口的最大调用时长；

为目标渠道商分配目标性能阈值，其中，目标性能阈值小于或等于整体性能阈值。

可选地，在实施例中对服务器整体接口性能进行评估，确定整体接口调用的最大时长，根据每个渠道商的动态健康值设定的预定比例，分配给每个渠道商对应的接口调用最大时长，单个渠道商的性能阈值和所有渠道商性能阈值总和不能超过服务器整体性能阈值。例如，以整体接口调用的最大时长为1000毫秒为例，按照预定比例，为各个渠道商分配性能阈值。预定比例处于0-1之间。例如，渠道商A的性能阈值为600毫秒，渠道商B的性能阈值为800毫秒等，则渠道商A调用接口的时长不能超过600毫秒，渠道商B调用接口的时长不能超过800毫秒。

作为一种可选的示例，上述方法还包括：

根据健康值调整目标资源配额和目标性能阈值，其中，每一个渠道商对应一个健康值。

可选地，在实施例中健康值可以为***预设的分值评估***根据渠道商的健康评分计算得出的，每个渠道商被设置一个动态变化的健康值，根据动态变化的健康值调整为对应的资源配额和性能阈值，资源配额和性能阈值不是固定的，而是动态变化的。健康评分的波动，会影响到健康值。例如，可以周期性的为每一个渠道商进行评分，得到健康评分，健康评分的不同会增大或者减少该渠道商的健康值。健康值发生变化，则渠道商的资源配额和性能阈值对应发生变化。

作为一种可选的示例，根据健康值调整目标资源配额包括：

获取目标渠道商的健康值；

确定健康值所处的区间范围；

根据区间范围确定与区间范围对应的第一资源配额和第一性能阈值；

在第一资源配额和目标资源配额的数值不同的情况下，将目标资源配额的数值调整为第一资源配额的数值；

在第一性能阈值和目标性能阈值的数值不同的情况下，将目标性能阈值的数值调整为第一性能阈值的数值。

可选地，在实施例中每个渠道商的健康值根据数据收集分析中心收集到的数据划分多个区间范围，每个区间范围映射一个等级资源配额和一个接口性能。例如，以三个区间为例，分别为[0，6)、(6，8]以及(8，10]，三个区间各对应不同的资源配额和性能阈值。如果渠道商的健康值落在(6，8]之间，则将(6，8]对应的资源配额和性能阈值赋予渠道商。在第一资源配额和目标资源配额的数值相同的情况下，目标资源配额的数值保持不变。在第一性能阈值和目标性能阈值的数值相同的情况下，目标性能阈值的数值保持不变。

作为一种可选的示例，上述方法还包括：

获取目标渠道商的健康评分；

在健康评分处于第一区间的情况下，增大目标渠道商的健康值；

在健康评分处于第二区间的情况下，保持目标渠道商的健康值不变；

在健康评分处于第三区间的情况下，减小目标渠道商的健康值。

可选地，在实施例中健康评分可以为根据数据采集分析中心采集到的渠道商每日的有效订单比例、每日退款订单比例、每日完结订单比例等数据以及渠道商的评分和权重计算得出的。根据健康评分划分为三个区间，对应三个健康值的调整方法，对健康值进行增加或者减少。

作为一种可选的示例，获取健康评分包括：

确定所述目标渠道商的下单相关信息数组；

确定所述下单相关信息数组中各数组元素对应的健康子评分，以形成对应的健康数组；

根据所述健康数组中各数组元素，以及所述健康数组中各数组元素对应的权重信息，加权确定所述健康评分。

可选地，上述下单相关信息数组中的数组元素可以包括多种元素。例如，可以包括订单数量，如创建订单数量、支付订单数量、退款订单数量、完结订单数量、访问量、峰值访问量、推送商品的广告数量，推送商品的广告次数，推送商品的广告时长等，上述创建订单数量、支付订单数量、退款订单数量、完结订单数量、访问量、推送商品的广告数量，推送商品的广告次数，推送商品的广告时长可以按照一定的时长进行统计，如每小时统计一次，每天统计一次，每周统计一次，每月统计一次，每季度统计一次，每年统计一次等。如每天统计一次，则可以得到每日创建订单数量、每日支付订单数量、每日退款订单数量、每日完结订单数量、每日访问量、每日峰值访问量、每日推送商品的广告数量，每日推送商品的广告次数，每日推送商品的广告时长。数组元素还可以包括有效订单比例、退款订单比例、推送广告转化率以及完结订单比例等。上述比例可以通过上述数量计算得到。如有效订单比例为支付订单数量/创建订单数量、退款订单比例为退款订单数量/支付订单数量、完结订单比例为完结订单数量/创建订单数量。对于下单相关信息数组中的每一个数组元素，均对应一个权重信息。本实施例可以将下单相关信息数组中的每一个数组元素的健康子评分和权重信息相乘，然后将乘积的和作为健康评分。

本实施例中可以由服务器设置一个资源池，进行下单资源管控，如图2所示，对下单服务器的处理能力进行评估，以10分钟为统计维度，10分钟能处理下单请求2000次，那下单服务器的极限处理能力就是2000次/10分钟，在资源池中先配置下单处理极限值：2000次/10分钟。

在为服务器设置资源池之后，为服务器配置每个渠道商的资源配额(例如，每个渠道商的初始的资源配额可以是设置的经验值)，如下图2渠道商A的资源配额为20次/10分钟，渠道商B的资源配额为30次/10分钟，渠道商C的资源配额为50次/10分钟，如此便可限制每一个渠道商的访问资源配额。特殊情况：若服务器对渠道商D没有接口依赖，暂时不需求对渠道商D进行单独限制，那渠道商D就会与其他没有被限制的渠道商使用公共的下单资源2000次/10分钟。每个渠道在资源池中的资源配额不是固定的，而是动态变化的；为了更有效的分配资源，本申请配置了一套资源配额调整策略，根据有效销售量、下单集中时间等动态的分配资源配额。

在渠道商应用接入商城***平台后，会给渠道应用设置一个初始健康值(例如：健康值最高为10，设置初始默认为8)。渠道应用的健康值是通过不同维度综合判断的，根据收集到的数据划分不同的维度(如：日访问量、峰值访问量、下单数量等)，不同的维度设置有不同的权重，根据评分和权重计算出本次健康评分。

以有效销售量为例，以下单相关信息数组包括每日有效订单比例、每日退款订单比例、每日完结订单比例为例，如图3所示，数据采集分析中心会收集各时段的创建订单数量、支付订单数量、退款订单数量、完结订单数量；然后通过收集的各个维度的订单数量计算出每日的有效订单比例(支付订单数量/创建订单数量)、每日退款订单比例(退款订单数量/支付订单数量)、每日的完结订单比例(完结订单数量/创建订单数量)等数据。根据每日的有效订单比例、每日退款订单比例、每日完结订单比例为维度，定时进行一次统计。之后，可以计算每一个维度的健康子评分，并获取每一个维度的权重信息，如图4所示，本次健康评分＝评分1*权重1+评分2*权重2+评分3*权重3。

***中有预设的分值评估***，根据不同的分段，对健康值进行增加或者减少，如图5。例如最大分值为10分，当分数小于等于6分时，扣除1点健康值；当分数在6分到8分之间时，健康值保持不变；当分数大于8时，健康值加1点。

资源配额与健康值映射绑定，如图6，当计算出的健康值进入某一标准后，会对应的限制资源的配额。例如配置的低级资源配额为20次/10分钟，中级资源配额为50次/10分钟，若渠道商原来的健康度由7下降到6时，资源配额会由中级资源配额调整为低级资源配额，即由50次/10分钟限制为20次/10分钟。

设置性能阈值，例如整体接口性能限制为1000毫秒，即为所有的依赖接口性能不能超过1000毫秒，然后单独针对具体场景对具体的渠道商接口性能进行限制(例如，限制的时间也可以是经验值)，如图7所示：渠道商接口A限制300毫秒，渠道商接口B限制250毫秒，渠道商接口C限制300毫秒。

将健康值与接口性能限制进行映射绑定，就可以根据健康值动态的调整接口性能的限制，以此对健康值高的渠道商提供更大的便利，如图8。即随着健康值的升高，接口性能的限制也会放宽，对网络波动等因素引发的性能问题有更高的容忍度。

在下单购买时添加渠道商校验(也可以是在下单购买发生渠道商接口响应时间超过预定阈值、下单总时长较长等异常情况时，进行渠道商校验)，先校验渠道商的下单资源配额是否充足，如果资源不足，便会拒绝此次下单操作，需等待资源释放后才能再次下单；资源校验通过后，再校验渠道商的接口响应时间，若响应时间低于阈值，则终止此次下单，释放下单资源。如图9所示。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

根据本申请实施例的另一方面，还提供了一种下单资源分配装置，如图10所示，包括：

接收模块1002，用于接收客户端发送的下单请求；

确定模块1004，用于确定下单请求对应的目标渠道商；

获取模块1006，用于获取目标渠道商的目标资源配额和目标性能阈值；

第一处理模块1008，用于在下单请求所需要的资源值小于或等于目标资源配额的情况下，且下单请求所需要的响应时间小于或等于目标性能阈值的情况下，允许下单；

第二处理模块1010，用于在下单请求所需要的资源值大于目标资源配额的情况下，或者下单请求所需要的响应时间大于目标性能阈值的情况下，拒绝下单。

可选地，本实施例中的客户端可以为完成签约的外部应用APP或小程序等，外部应用APP或小程序内可集成商城***平台的SDK，通过SDK，外部应用APP或小程序可以直接访问商城***平台，从而进行下单。例如，在渠道商A完成签约后，在渠道商A的应用程序中集成商城***平台SDK，用户在下载该渠道商的应用程序后，通过该应用程序来直接访问商城***平台进行下单。下单请求可以为向商城***平台的服务器发送的，用于下单购物的请求，目标渠道商为外部应用(客户端)的所属方，用户通过目标渠道商的客户端向商城***平台的服务器发送下单请求进行购物。在此，渠道商的客户端是指接入同一商城对应的商城***平台的SDK、以形成渠道商的自身商城、用户可在其上面进行商品下单的第三方平台，如第三方APP、第三方小程序等。在此，可以理解的是，渠道商自身商城中的商品来源于其接入的商城，且该商城可接入多个不同渠道商的客户端，用户在渠道商的自身商城进行商品下单时，虽然商品来源于其接入的商城，但用户并不感知，而是认为所下单商品是渠道商自身售卖的商品。当用户通过渠道商的自身商城进行购买商品的操作时，向商城***平台发送对商品的下单请求，商城***平台接收用户通过渠道商的自身商城对商品的下单请求。

可选地，本实施例中，可以包括多个渠道商和用于提供商城***平台服务的服务器，多个渠道商的每一个渠道商可以产生下单请求，然后将下单请求发送给服务器，由服务器进行处理。每一个渠道商都可以对应一个资源配额和性能阈值，资源配额用于限制单位时间内能够发送到服务器、由服务器处理的下单请求的数量，性能阈值用于限制调用接口的最大时长。当多个渠道商中的目标渠道商向服务器发送一个下单请求的时候，服务器可以获取该目标渠道商的目标资源配额和目标性能阈值，然后，判断下单请求所需要的资源值和目标资源配额的关系，以及判断下单请求所需要的响应时间和目标性能阈值的关系，如果下单请求所需要的资源值小于或等于目标资源配额，而且下单请求所需要的响应时间小于或等于目标性能阈值，则允许下单，如果所需要的资源值大于目标资源配额，或者下单请求所需要的响应时间大于目标性能阈值，则不允许下单。

根据一种可选的示例，上述装置还包括：

分配模块，用于获取目标渠道商的目标资源配额和目标性能阈值之前为目标渠道商分配目标资源配额和目标性能阈值。

可选地，在实施例中为目标渠道商分配的目标资源配额可以为渠道商的单位时间段内下单请求数量的最大值，但不能超过服务器的处理极限值，目标性能阈值可以为经渠道商发送下单请求时调用接口所需要的最大时长，但不能超过服务器整体接收下单请求调用接口的最大时长，每个渠道商对应一个资源配额和性能阈值。为渠道商分配资源配额和性能阈值时，可以根据渠道商的不同，为不同的渠道商分配不同的资源配额和性能阈值。例如，可以根据历史经验值为资源配额和性能阈值来分配资源配额和性能阈值，例如，以一天的数据为依据，该一天的数据中，某一个渠道商的下单次数和每一次下单时的占用接口的平均时长作为资源配额和性能阈值的初始值。

根据一种可选的示例，上述分配模块包括：

第一确定单元，用于确定接收下单请求的下单服务器在单位时间段内能够处理的下单请求的最大值；

第一分配单元，用于按照预定比例，将最大值分配给多个渠道商，其中，多个渠道商中包括目标渠道商，每一个运行商对应一个预定比例。

可选地，在实施例中对服务器整体下单能力进行评估，确定单位时间内处理下单请求次数的最大值，根据每个渠道商的健康值动态设定的预定比例，分配给每个渠道商对应的资源配额，单个渠道商的资源配额和所有渠道商资源配额总和不能超过服务器整体资源值。例如，当单位时间内处理下单请求次数的最大值为2000，则单位时间内，所有渠道商的资源配额的和不能超过2000。可以将2000按照比例分配给不同的渠道商，如渠道商A占800，渠道商B占1200，则单位时间内，渠道商A最高可以发送800个下单请求，渠道商B最高可以发送1200个下单请求。

根据一种可选的示例，上述分配模块包括：

第一获取单元，用于获取整体性能阈值，其中，整体性能阈值为用于接收下单请求的接口的最大调用时长；

第二分配单元，用于为目标渠道商分配目标性能阈值，其中，性能阈值小于或等于整体性能阈值。

可选地，在实施例中对服务器整体接口性能进行评估，确定整体接口调用的最大时长，根据每个渠道商的动态健康值设定的预定比例，分配给每个渠道商对应的接口调用最大时长，单个渠道商的性能阈值和所有渠道商性能阈值总和不能超过服务器整体性能阈值。例如，以整体接口调用的最大时长为1000毫秒为例，按照预定比例，为各个渠道商分配性能阈值。预定比例处于0-1之间。例如，渠道商A的性能阈值为600毫秒，渠道商B的性能阈值为800毫秒等，则渠道商A调用接口的时长不能超过600毫秒，渠道商B调用接口的时长不能超过800毫秒。

根据一种可选的示例，上述装置还包括：

调整模块，用于根据健康值调整目标资源配额和目标性能阈值，其中，每一个渠道商对应一个健康值。

可选地，在实施例中健康值可以为***预设的分值评估***根据渠道商的健康评分计算得出的，每个渠道商被设置一个动态变化的健康值，根据动态变化的健康值调整为对应的资源配额和性能阈值，资源配额和性能阈值不是固定的，而是动态变化的。健康评分的波动，会影响到健康值。例如，可以周期性的为每一个渠道商进行评分，得到健康评分，健康评分的不同会增大或者减少该渠道商的健康值。健康值发生变化，则渠道商的资源配额和性能阈值对应发生变化。

根据一种可选的示例，上述调整模块包括：

第二获取单元，用于获取目标渠道商的健康值；

第二确定单元，用于确定健康值所处的区间范围；

第三确定单元，用于根据区间范围确定与区间范围对应的第一资源配额和第一性能阈值；

第一调整单元，用于在第一资源配额和目标资源配额的数值不同的情况下，将目标资源配额的数值调整为第一资源配额的数值；

第二调整单元，用于在第一性能阈值和目标性能阈值的数值不同的情况下，将目标性能阈值的数值调整为第一性能阈值的数值。

可选地，在实施例中每个渠道商的健康值根据数据收集分析中心收集到的数据划分多个区间范围，每个区间范围映射一个等级资源配额和一个接口性能。例如，以三个区间为例，分别为[0，6)、(6，8]以及(8，10]，三个区间各对应不同的资源配额和性能阈值。如果渠道商的健康值落在(6，8]之间，则将(6，8]对应的资源配额和性能阈值赋予渠道商。在第一资源配额和目标资源配额的数值相同的情况下，目标资源配额的数值保持不变。在第一性能阈值和目标性能阈值的数值相同的情况下，目标性能阈值的数值保持不变。

根据一种可选的示例，上述调整模块包括：

第三获取单元，用于获取目标渠道商的健康评分；

第一处理单元，用于在健康评分处于第一区间的情况下，增大目标渠道商的健康值；

第二处理单元，用于在健康评分处于第二区间的情况下，保持目标渠道商的健康值不变；

第三处理单元，用于在健康评分处于第三区间的情况下，减小目标渠道商的健康值。

可选地，在实施例中健康评分可以为根据数据采集分析中心采集到的渠道商每日的有效订单比例、每日退款订单比例、每日完结订单比例等数据以及渠道商的评分和权重计算得出的。根据健康评分划分为三个区间，对应三个健康值的调整方法，对健康值进行增加或者减少。

根据一种可选的示例，上述第三获取单元包括：

处理子单元，用于获取目标渠道商的有效下单数量、下单支付数量以及下单退回数量；根据所述有效下单数量、所述下单支付数量以及所述下单退回数量确定有效下单比例、下单支付比例以及下单退回比例；按照所述有效下单比例、所述下单支付比例以及所述下单退回比例确定所述有效下单数量、所述下单支付数量以及所述下单退回数量各自的评分；将有效下单数量、下单支付数量以及下单退回数量各自对应的评分分别与预定权重相乘；将乘积的和确定为健康评分。

可选地，上述下单相关信息数组中的数组元素可以包括多种元素。例如，可以包括订单数量，如创建订单数量、支付订单数量、退款订单数量、完结订单数量、访问量、峰值访问量、推送商品的广告数量，推送商品的广告次数，推送商品的广告时长等，上述创建订单数量、支付订单数量、退款订单数量、完结订单数量、访问量、推送商品的广告数量，推送商品的广告次数，推送商品的广告时长可以按照一定的时长进行统计，如每小时统计一次，每天统计一次，每周统计一次，每月统计一次，每季度统计一次，每年统计一次等。如每天统计一次，则可以得到每日创建订单数量、每日支付订单数量、每日退款订单数量、每日完结订单数量、每日访问量、每日峰值访问量、每日推送商品的广告数量，每日推送商品的广告次数，每日推送商品的广告时长。数组元素还可以包括有效订单比例、退款订单比例、推送广告转化率以及完结订单比例等。上述比例可以通过上述数量计算得到。如有效订单比例为支付订单数量/创建订单数量、退款订单比例为退款订单数量/支付订单数量、完结订单比例为完结订单数量/创建订单数量。对于下单相关信息数组中的每一个数组元素，均对应一个权重信息。本实施例可以将下单相关信息数组中的每一个数组元素的健康子评分和权重信息相乘，然后将乘积的和作为健康评分。

本实施例的其他示例请参见上述示例，在此不在赘述。

图11是根据本申请实施例的一种可选的电子设备的结构框图，如图11所示，包括处理器1102、通信接口1104、存储器1106和通信总线1108，其中，处理器1102、通信接口1104和存储器1106通过通信总线1108完成相互间的通信，其中，

存储器1106，用于存储计算机程序；

处理器1102，用于执行存储器1106上所存放的计算机程序时，实现如下步骤：

接收客户端发送的下单请求；

确定下单请求对应的目标渠道商；

获取目标渠道商的目标资源配额和目标性能阈值；

在下单请求所需要的资源值小于或等于目标资源配额的情况下，且下单请求所需要的响应时间小于或等于目标性能阈值的情况下，允许下单；

在下单请求所需要的资源值大于目标资源配额的情况下，或者下单请求所需要的响应时间大于目标性能阈值的情况下，拒绝下单。

可选地，在本实施例中，上述的通信总线可以是PCI(Peripheral ComponentInterconnect，外设部件互连标准)总线、或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。通信接口用于上述电子设备与其他设备之间的通信。

存储器可以包括RAM，也可以包括非易失性存储器(non-volatile memory)，例如，至少一个磁盘存储器。可选地，存储器还可以是至少一个位于远离前述处理器的存储装置。

作为一种示例，上述存储器1106中可以但不限于包括上述请求的处理装置中的接收模块1002、确定模块1004、获取模块1006、第一处理模块1008以及第二处理模块1010。此外，还可以包括但不限于上述请求的处理装置中的其他模块单元，本示例中不再赘述。

上述处理器可以是通用处理器，可以包含但不限于：CPU(Central ProcessingUnit，中央处理器)、NP(Network Processor，网络处理器)等；还可以是DSP(DigitalSignal Processing，数字信号处理器)、ASIC(Application Specific IntegratedCircuit，专用集成电路)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

本领域普通技术人员可以理解，图11所示的结构仅为示意，实施上述请求的处理方法的设备可以是终端设备，该终端设备可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌上电脑以及移动互联网设备(Mobile Internet Devices，MID)、PAD等终端设备。图11其并不对上述电子设备的结构造成限定。例如，电子设备还可包括比图11中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图11所示的不同的配置。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、ROM、RAM、磁盘或光盘等。

根据本发明的实施例的又一方面，还提供了一种计算机可读的存储介质，该计算机可读的存储介质中存储有计算机程序，其中，该计算机程序被处理器运行时执行上述下单资源分配方法中的步骤。

可选地，在本实施例中，本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(Random Access Memory，RAM)、磁盘或光盘等。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (18)

1.一种下单资源分配方法，其特征在于，包括：

接收客户端发送的下单请求；

确定所述下单请求对应的目标渠道商；

获取所述目标渠道商的目标资源配额和目标性能阈值；

在所述下单请求所需要的资源值小于或等于所述目标资源配额的情况下，且所述下单请求所需要的响应时间小于或等于所述目标性能阈值的情况下，允许下单；

在所述下单请求所需要的资源值大于所述目标资源配额的情况下，或者所述下单请求所需要的响应时间大于所述目标性能阈值的情况下，拒绝下单。

2.根据权利要求1所述的方法，其特征在于，在获取所述目标渠道商的目标资源配额和目标性能阈值之前，还包括：

为所述目标渠道商分配所述目标资源配额和所述目标性能阈值。

3.根据权利要求2所述的方法，其特征在于，为所述目标渠道商分配所述目标性能阈值包括：

获取整体性能阈值，其中，所述整体性能阈值为用于接收所述下单请求的接口的最大调用时长；

为所述目标渠道商分配所述目标性能阈值，其中，所述目标性能阈值小于或等于所述整体性能阈值。

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

根据健康值调整所述目标资源配额和所述目标性能阈值，其中，每一个渠道商对应一个所述健康值。

5.根据权利要求4所述的方法，其特征在于，根据健康值调整所述目标资源配额包括：

获取所述目标渠道商的所述健康值；

确定所述健康值所处的区间范围；

根据所述区间范围确定与所述区间范围对应的第一资源配额和第一性能阈值；

在所述第一资源配额和所述目标资源配额的数值不同的情况下，将所述目标资源配额的数值调整为所述第一资源配额的数值；

在所述第一性能阈值和所述目标性能阈值的数值不同的情况下，将所述目标性能阈值的数值调整为所述第一性能阈值的数值。

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

获取所述目标渠道商的健康评分；

在所述健康评分处于第一区间的情况下，增大所述目标渠道商的所述健康值；

在所述健康评分处于第二区间的情况下，保持所述目标渠道商的所述健康值不变；

在所述健康评分处于第三区间的情况下，减小所述目标渠道商的所述健康值。

7.根据权利要求6所述的方法，其特征在于，获取所述健康评分包括：

确定所述目标渠道商的下单相关信息数组；

确定所述下单相关信息数组中各数组元素对应的健康子评分，以形成对应的健康数组；

根据所述健康数组中各数组元素，以及所述健康数组中各数组元素对应的权重信息，加权确定所述健康评分。

8.一种下单资源分配装置，其特征在于，包括：

接收模块，用于接收客户端发送的下单请求；

确定模块，用于确定所述下单请求对应的目标渠道商；

获取模块，用于获取所述目标渠道商的目标资源配额和目标性能阈值；

第一处理模块，用于在所述下单请求所需要的资源值小于或等于所述目标资源配额的情况下，且所述下单请求所需要的响应时间小于或等于所述目标性能阈值的情况下，允许下单；

第二处理模块，用于在所述下单请求所需要的资源值大于所述目标资源配额的情况下，或者所述下单请求所需要的响应时间大于所述目标性能阈值的情况下，拒绝下单。

9.根据权利要求8所述的装置，其特征在于，所述装置还包括：

分配模块，用于获取所述目标渠道商的目标资源配额和目标性能阈值之前，为所述目标渠道商分配所述目标资源配额和所述目标性能阈值。

10.根据权利要求9所述的装置，其特征在于，所述分配模块包括：

第一获取单元，用于获取整体性能阈值，其中，所述整体性能阈值为用于接收所述下单请求的接口的最大调用时长；

第二分配单元，用于为所述目标渠道商分配所述目标性能阈值，其中，所述目标性能阈值小于或等于所述整体性能阈值。

11.根据权利要求9所述的装置，其特征在于，所述装置还包括：

调整模块，用于根据健康值调整所述目标资源配额和所述目标性能阈值，其中，每一个渠道商对应一个所述健康值。

12.根据权利要求11所述的装置，其特征在于，所述调整模块包括：

第二获取单元，用于获取所述目标渠道商的所述健康值；

第二确定单元，用于确定所述健康值所处的区间范围；

第三确定单元，用于根据所述区间范围确定与所述区间范围对应的第一资源配额和第一性能阈值；

第一调整单元，用于在所述第一资源配额和所述目标资源配额的数值不同的情况下，将所述目标资源配额的数值调整为所述第一资源配额的数值；

第二调整单元，用于在所述第一性能阈值和所述目标性能阈值的数值不同的情况下，将所述目标性能阈值的数值调整为所述第一性能阈值的数值。

13.根据权利要求11或12所述的装置，其特征在于，所述调整模块包括：

第三获取单元，用于获取所述目标渠道商的健康评分；

第一处理单元，用于在所述健康评分处于第一区间的情况下，增大所述目标渠道商的所述健康值；

第二处理单元，用于在所述健康评分处于第二区间的情况下，保持所述目标渠道商的所述健康值不变；

第三处理单元，用于在所述健康评分处于第三区间的情况下，减小所述目标渠道商的所述健康值。

14.根据权利要求13所述的装置，其特征在于，所述第三获取单元包括：

计算子单元，用于确定所述目标渠道商的下单相关信息数组；确定所述下单相关信息数组中各数组元素对应的健康子评分，以形成对应的健康数组；根据所述健康数组中各数组元素，以及所述健康数组中各数组元素对应的权重信息，加权确定所述健康评分。

15.一种应用于C2M模式的下单资源分配设备，其特征在于，该设备包括权利要求8所述的下单资源分配装置。

16.一种应用于C2M模式的电商平台服务器，其特征在于，该电商平台服务器包括权利要求8所述的下单资源分配装置。

17.一种计算机可读的存储介质，所述计算机可读的存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器运行时执行所述权利要求1至7任一项中所述的方法。

18.一种电子设备，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为通过所述计算机程序执行所述权利要求1至7任一项中所述的方法。

Images