CN111240841A - 用于执行新任务或处理资源撤回请求的方法和系统 - Google Patents

Abstract

本申请涉及用于执行新任务的方法，包括：接收在该服务器上执行新任务的请求，该请求指定执行该新任务的所需资源量，该服务器目前正在执行多个执行中任务；对于该多个执行中任务中的每个执行中任务，查询该执行中任务的当前占用资源量以及当前可释放资源量；基于所查询到的该多个执行中任务中的每个执行中任务的该当前占用资源量和/或该当前可释放资源量，将该所需资源量在该多个执行中任务之间自动分配以确定每个执行中任务的重分配资源量，以使每个执行中任务的最终占用资源量均衡；以及将每个执行中任务的重分配资源量分配给该新任务。本申请还涉及用于处理资源撤回请求的方法。本申请能够提高效率和用户体验。

Description

用于执行新任务或处理资源撤回请求的方法和系统

技术领域

本说明书的一个或多个实施例涉及用于执行新任务或处理资源撤回请求的方法和系统。

背景技术

如今，在现实生活中常常需要处理任务或请求。而为了处理任务或请求，可能需要分配资源，从而遇到资源分配问题。例如，在目前的分布式计算或云计算场景中，由于任务的增加或减少以及服务器资源的增加或减少，常常需要将新增资源进行分配或将原有资源进行重新分配。

另一种情况是处理对多个资源池的资源撤回请求，并使得最终多个资源池的持有资源大致均衡。这种资源撤回请求可能发生于多种不同场景。这同样涉及到资源的分配。然而，现有技术中缺少自动、高效地处理对多个资源池的资源撤回请求的方案。

因此，需要能够自动地、高效地、体验良好地执行新任务或处理资源撤回请求的方法和系统。

发明内容

为了克服现有技术的缺陷，本说明书的一个或多个实施例提供了能够高效地、体验良好地执行新任务或处理资源撤回请求的方案。

本说明书的一个或多个实施例通过以下技术方案来实现其上述目的。

在一个方面中，公开了一种用于在服务器上执行新任务的方法，包括：接收在所述服务器上执行新任务的请求，所述请求指定执行所述新任务的所需资源量，所述服务器目前正在执行多个执行中任务；对于所述多个执行中任务中的每个执行中任务，查询该执行中任务的当前占用资源量以及当前可释放资源量；基于所查询到的所述多个执行中任务中的每个执行中任务的所述当前占用资源量和/或所述当前可释放资源量，将所述所需资源量在所述多个执行中任务之间自动分配以确定每个执行中任务的重分配资源量，以使每个执行中任务的最终占用资源量均衡；以及将每个执行中任务的重分配资源量分配给所述新任务。

在另一方面中，公开了一种用于处理资源撤回请求的方法，包括：接收对多个资源池的资源撤回请求，所述资源撤回请求指定对所述多个资源池的总撤回资源量；对于所述多个资源池中的每个资源池，传送对该资源池的当前持有资源量和/或当前可用资源量的查询请求；接收所查询到的每个资源池的当前持有资源量和/或所述当前可用资源量；基于所查询到的所述多个资源池中的每个资源池的所述当前持有资源量和/或所述当前可用资源量，将所述总撤回资源量自动分配给所述多个资源池以确定每个资源池的分配撤回资源量，以使每个资源池的最终持有资源量均衡；以及对于所述多个资源池中的一个或多个资源池，从该资源池撤回相应的分配撤回资源量。

在又一方面中，公开了一种存储指令的计算机可读存储介质，所述指令当被计算机执行时，使所述计算机执行上述方法。

在再一方面中，公开了一种系统，所述系统包括用于执行上述方法的装置。

与现有技术相比，本说明书的一个或多个实施例可具有如下有益效果：

能够提升处理任务或请求的效率；

能够提升资源管理任务或基金的效率；以及

能够提升用户体验。

当然，实施本申请的任一技术方案无需同时达到所有上述技术效果。

附图说明

以上发明内容以及下面的具体实施方式在结合附图阅读时会得到更好的理解。需要说明的是，附图仅作为所请求保护的发明的示例。在附图中，相同的附图标记代表相同或类似的元素。

图1示出根据本说明书实施例的用于在服务器上执行新任务的方法的示例流程图。

图2示出根据本说明书实施例的用于在服务器上执行新任务的系统的示意框图。

图3示出根据本说明书的实施例的用于确定新任务的所需资源量是否太高的过程的示例流程图。

图4示出根据本说明的一实施例的将所需资源量在多个执行中任务之间自动分配的过程的示例流程图。

图5示出了根据本说明的实施例的在考虑资源基准线的情况下将所需资源量在多个执行中任务之间自动分配的过程的示例流程图。

图6示出根据本说明书实施例的用于在不同执行中任务之间借用差额的过程的示例流程图。

图7示出根据本说明书实施例的用于处理赎回请求的系统的示例框图。

图8示出根据本说明书的实施例的用于实现多基金账户的系统的示意图。

图9示出根据本说明书实施例的用于在服务器上执行新任务的方法的示例流程图。

图10示出根据本说明书的实施例的用于确定赎回请求指定的总赎回金额是否太高的过程的示例流程图。

图11示出根据本说明书的实施例的用于相对于总赎回限额确定赎回请求指定的总赎回金额是否太高的过程的示例流程图。

图12示出根据本说明的一实施例的将总赎回金额在多只基金之间自动分配的过程的示例流程图。

图13示出了根据本说明的实施例的在考虑赎回基准线的情况下，将总赎回金额在多只基金之间自动分配的过程的示例流程图。

图14示出根据本说明书实施例的用于在不同基金之间借用差额的过程的示例流程图。

图15示出根据本说明书的实施例的用于处理支付请求的方法的流程图。

图16示出根据本说明书的实施例的用于处理资源撤回请求的方法的流程图。

具体实施方式

以下具体实施方式的内容足以使任何本领域技术人员了解本说明书的一个或多个实施例的技术内容并据以实施，且根据本说明书所揭露的说明书、权利要求及附图，本领域技术人员可轻易地理解本说明书的一个或多个实施例相关的目的及优点。

在现实生活中，常常遇到资源分配问题。

例如，在云计算等环境中，任务常常在多个服务器上执行。此时，需要为任务分配服务器资源。

服务器资源例如可包括计算资源和/或存储资源。计算资源例如是CPU资源、GPU资源或其它处理资源等。存储资源例如是内存资源或者闪存、硬盘等存储器资源等。服务器资源还可包括网络资源，例如带宽资源等。服务器资源还可包括其它资源，例如I/O资源、功率资源等。

在以上场景中，常常遇到需要增加新任务的场景。在一些情况下，虽然增加了新任务，但可能来不及或不想要增加服务器资源量。此时，需要将现有的服务器资源分配给新任务。

任务请求处理实施例

参见图1，其示出了根据本说明书实施例的用于在服务器上执行新任务的方法100的示例流程图。此方法可参考图2来理解。图2示出了根据本说明书实施例的用于在服务器上执行新任务的系统200的示意框图。

如图1所示，方法100可包括：在步骤S101，可接收在所述服务器(例如图2中的服务器202)上执行新任务的请求。

该服务器202可以是各种类型的服务器，例如大型机、小型机等。该服务器也可以是服务器集群或虚拟机集群，例如云服务器等。通常，服务器可能正在执行多个任务(例如图2中的任务1、任务2……任务n)，服务器上当前正在执行的任务在后文中可被成为执行中任务。

该新任务和/或该执行中任务可以是任何类型的任务，例如采集数据、处理数据、处理来自用户的请求等等。

该请求可来自请求方202，该请求方例如可以是客户端、来自用户、来自该服务器本身和/或来自一个或多个其它服务器等。该请求可指定执行所述新任务的所需资源量，所述服务器204目前正在执行多个执行中任务(例如任务1、任务2……任务n)。如上所述，该资源量可以是计算资源量(例如CPU循环数)、存储资源量(例如内存量、硬盘量等)、网络资源量(例如带宽量)等。该资源量还可以是其它资源量，例如I/O资源量、功率资源量等。

方法100还可包括：在步骤S102，对于每个执行中任务，可查询该执行中任务的当前占用资源量以及当前可释放资源量。

所谓当前占用资源量，是指当前为该执行中任务分配的资源量。例如，服务器可能为每个任务分配各自的资源量，这些资源量可能相同或可能不同。例如，服务器可能为执行中任务A分配了2GB内存，为执行中任务B分配了3GB内存，为执行中任务C分配了3GB内存……。执行中任务的当前所分配的资源量在后文中被称为该执行中任务的当前占用资源量。

然而，分配给执行中任务的资源量可能并未被全部使用。例如，在为执行中任务1分配的3GB内存中，可能只使用了1GB，而剩余2GB内存未用；为执行中任务2分配的2GB内存中，可能只使用了1.8GB，而剩余0.2GB内存未用；为执行中任务3分配的3GB内存中，可能只使用了2.5GB，而剩余0.5GB内存未用……这些剩余的未被使用的资源量可被释放并被分配给其它任务使用，在后文中可将其称为当前可释放资源量。

方法100还可包括：在步骤S103，可基于所查询到的所述多个执行中任务中的每个执行中任务的所述当前占用资源量和/或所述当前可释放资源量，将所述所需资源量在所述多个执行中任务之间自动分配以确定每个执行中任务的重分配资源量，以使每个执行中任务的最终占用资源量均衡。也就是说，将该多个自行中任务中的一个或多个执行中任务的当前占用资源量的一部分作为重分配资源量，以用于分配给新任务，以使得新任务能够被执行。该重分配资源量可能对于每个执行中任务是不同的。最终占用资源量，是指每个执行中任务的当前占用资源量减去其重分配资源量所得到的占用资源量，其是在将重分配资源量分配给新任务后为该执行中任务保留以继续执行该执行中任务的资源量。

所谓使得每个执行中任务的最终资源占用量均衡，可以用各种目标来衡量。在一个简单示例中，其指尽量使得每个执行中任务的最终占用资源量相等或大致相等。例如，这些任务可能是大致同类的任务，例如分配给不同用户的虚拟机任务。虽然在某些时刻允许不同用户的虚拟机任务占据或多或少的资源，但通常追求这些用户的占用资源量大致相同。在这种情况下，目标就可以是尽量使得每个执行中任务的最终占用资源量相等或大致相等。可以设想同样存在这种目标的其它情形。在下面的描述中，一般以此目标为例进行描述。

在另一示例中，其指尽量使得每个执行中任务的最终占用资源量与其当前使用资源量(即最开始的当前占用资源量减去当前可释放资源量的差)的比值相等或大致相等。

用于将所需资源量在多个执行中任务之间自动分配以确定每个执行中任务的重分配资源量的方法在下面参考图4和图5来详细描述。

方法100还可包括：在步骤S104，可将每个执行中任务的重分配资源量分配给所述新任务。通过将该新任务的所需资源量多个执行中任务之间自动分配，确定每个执行中任务的重分配资源量之后，即得到了每个执行中任务要分配给新任务的资源量，这些资源量之和等于所接收的执行该任务的请求中所指定的所需资源量，从而该新任务可以使用分配给它的所需资源量来执行。

然而，可以设想，可能出现以下情形：所接收的执行新任务的请求中指定的所需资源量太高，以至于将该服务器中的全部可释放资源量都分配给该新任务，仍然无法满足该新任务的所需资源量。此时，可以向请求方传送该新任务的所需资源量太高的提示。

为此，在上述步骤S102之后且在步骤S103之前，可先执行用于确定新任务的所需资源量是否太高的过程。参考图3，其示出了根据本说明书的实施例的用于确定新任务的所需资源量是否太高的过程300的示例流程图。

过程300可包括：在步骤S301，基于所查询到的每个执行中任务的当前可释放资源量计算所述服务器的总当前可释放资源量。例如，通过将每个执行中任务的当前可释放资源量求和，即可得到服务器的总当前可释放资源量。接上例，假设该服务器当前正在执行三个执行中任务1、任务2、任务3，则该服务器的总当前可释放资源量为任务1、任务2、任务3的当前可释放资源量之和，例如为2GB+0.2GB+0.5GB＝2.7GB内存。

过程300可包括：在步骤S302，可将所述所需资源量与所述总当前可释放资源量进行比较。例如，如果执行该新任务的请求中所指定的所需资源量为3GB，将两者进行比较，可以得到所需资源量3GB大于总当前可释放资源量2.7GB。而如果如果执行该新任务的请求中所指定的所需资源量为2GB，将两者进行比较，可以得到所需资源量2GB小于总当前可释放资源量2.7GB。

过程300还可包括：在步骤S303，如果所述所需资源量大于所述总当前可释放资源量，则可提示所述新任务的所需资源量太高。如上所述，服务器(例如图2的服务器204)可向发送执行新任务的请求的请求方(例如图2的请求方202)传送该新任务的所需资源量太高的提示。此时，该请求方可决定不执行该新任务。替代地，该请求方可决定执行该新任务。如果请求方决定执行该新任务，服务器可根据情况决定是否要减少分配给执行中任务的资源或者直接停止执行中任务的执行来为新任务空出资源。

另一方面，如果所需资源量小于等于总当前可释放资源量，可以继续执行如图1所示的步骤S103，将所需资源量执行自动分配。

参考图4，其示出了根据本说明的一实施例的将所述所需资源量在所述多个执行中任务之间自动分配的过程400的示例流程图。如上所述，该过程可在查询到每个任务的当前占用资源量和当前可释放资源量之后进行。

大致而言，该自动分配过程可通过以下几个步骤实现：首先，可初始化要从中重分配资源量的执行中任务集合。例如，如下面在步骤S401中详细描述的，可将该集合初始化为全部多个执行中任务。

随后，可迭代更新所述执行中任务集合以便所述执行中任务集合中的所有执行中任务的当前占用资源量均大于经重分配资源后的平均占用资源量。最后，可基于所述平均占用资源量来计算经更新的所述执行中任务集合中的执行中任务的重分配资源量。这两个步骤的具体过程可参考下面针对步骤S402-S405的描述。

如图4所示，过程400可包括步骤S401：将要重分配资源量的执行中任务的第一集合初始化为全部所述多个执行中任务，此时所述第一集合中的执行中任务的第一数量等于所述多个执行中任务的数量。

也就是说，在初始化时，假定将所有执行中任务中均重新分配一部分资源量给新任务。

例如，假设该服务器中当前总共存在n个执行中任务，此时所述第一集合中的执行中任务的数量x＝n。

过程400还可包括步骤S402：可通过用所述第一集合内的执行中任务的当前占用资源量Fi之和减去所述所需资源量Msum的差除以第一数量x来确定第一资源量，也就是说：

Favg＝(∑ Fi-Msum)/x (式1)

其中，如上所述，Fi为第一集合内的执行中任务的当前占用资源量，而第一数量x的初始值等于所述多个执行中任务的数量n。在后续过程中，随着迭代的进行，可能需要逐步改变所述第一集合，从而使得第一数量x的值被更新而不再等于n，这将在下文中描述。

上式的含义可以领会如下：

通过对所述第一集合内的执行中任务的当前占用资源量Fi求和，可以得到所述第一集合中的执行中任务(即要重分配资源量的那些执行中任务)的总当前占用资源量∑Fi。

随后，将所述第一集合内的执行中任务的总当前占用资源量∑ Fi减去所述所需资源量Msum，可以得到在将所需资源量Msum分配给新任务后，该服务器的用于该多个执行中任务的总剩余资源量∑ Fi-Msum。如上所述，第一数量反映了拿出其占用资源来重分配给新任务的执行中任务的数量。通过将该第一集合内的总剩余资源量∑ Fi-Msum除以该第一集合内的执行中任务的第一数量x，即可得到该第一集合内的各执行中任务的平均剩余资源量Favg。

过程400还可包括步骤S403：可确定所述第一集合内当前占用资源量Fi大于等于所述第一资源量Favg的那些执行中任务以作为第二集合，其中所述第二集合中的执行中任务的数量为第二数量y。也就是说，将所述第一集合内的每个执行中任务的当前占用资源量Fi与通过式1得到的Favg进行比较，并选择当前占用资源量Fi大于等于第一资源量Favg的那些执行中任务并将其放入第二集合。第二集合中的执行中任务的数量用第二数量y来表示。可以领会，第二数量y小于或等于第一数量x。

过程400还可包括步骤S404：如果所述第二数量y等于所述第一数量x，则可计算所述第一集合内当前占用资源量大于所述第一资源量的执行中任务的重分配资源量Ri，其中所述重分配资源量Ri等于该执行中任务的当前占用资源量Fi减去所述第一资源量，即Ri＝Fi–Favg。可以领会，如果一执行中任务Ti的当前占用资源量Fi大于等于所述第一资源量Favg，则该执行中任务Ti能够被重分配资源；而如果执行中任务Ti的当前占用资源量Fi小于第一资源量Favg，则不应将该执行中任务Ti的资源量重分配给其它任务，否则其资源量将小于平均值。如果第二数量y等于第一数量x，则说明第一集合中的执行中任务均能够被重分配资源，此时可直接计算每个任务需要被重分配的重分配资源量，即其超出平均剩余资源量的量Ri＝Fi–Favg。该量Ri将被重分配给该新任务。在计算了重分配资源量之后，分配过程结束。

过程400还可包括步骤S405：如果所述第二数量y小于所述第一数量x，则可将所述第一集合更新为所述第二集合并将所述第一数量x更新为所述第二数量y，并重复上述步骤S402至S405。可以领会，如果第二数量小于第一数量，则说明第一集合中有些执行中任务的当前占用资源量小于平均剩余资源量，那么这些执行中任务的资源就不应被重分配。此时，只能在第二集合中的第二数量的执行中任务中重新计算平均剩余资源量Favg。因此，应当将用于计算平均剩余资源量Favg的第一集合更新为第二集合(相应地，应当将第一数量更新为第二数量，即令x＝y)，并重复执行步骤S402至S405，直到满足S404中的条件为止。

在一些情况下，并非执行中任务的所有当前占用资源量均可被重分配。例如，执行中任务可能具有最低限度的资源量要求。少于该资源量，则该执行中任务将完全不能运行。在本说明书的实施例中，该最低限度的资源量要求被称为资源基准线。在存在资源基准线的情况下，可能需要停止一个或多个当前执行中任务的执行，来保证新任务的执行。

大致而言，在考虑资源基准线的情况下，可采用以下步骤来实现重分配过程。首先，可确定所述多个执行中任务的每个执行中任务的资源基准线。随后，如果所述多个执行中任务的资源基准线之和与所述所需资源量之和大于等于所述多个执行中任务的总当前占用资源量，则在每个执行中任务的最终占用资源量大于等于其资源基准线的情况下确定每个执行中任务的重分配资源量，而如果所述多个执行中任务的资源基准线之和与所述所需资源量之和不大于所述多个执行中任务的总当前占用资源量，则将每个执行中任务的当前占用资源量中大于其资源基准线的资源量均划入其重分配资源量，并随后按照优先级将一个或多个执行中任务的剩余占用资源量也划入其重分配资源量。具体过程可参考下面的详细描述。

参考图5，其示出了根据本说明的实施例的在考虑资源基准线的情况下，将所述所需资源量在所述多个执行中任务之间自动分配的过程500的示例流程图。

如图5所示，过程500可包括步骤S501：可基于所查询到的每个执行中任务的所述当前占用资源量Fi计算所述服务器的总当前占用资源量Fsum。也就是说，可计算所有当前执行中任务的当前占用资源量Fi的和Fsum。也就是说，Fsum＝∑ Fi，其中求和的范围为该服务器中的所有该多个当前执行中任务的当前占用资源量Fi。

过程500还可包括步骤S502：可确定每个执行中任务的资源基准线Bi。例如，该服务器可维护每个执行中任务的资源基准线的记录。此时，服务器可根据记录来确定每个执行中任务的资源基准线Bi。替代地，还可采用试探法来确定每个执行中任务的资源基准线Bi。

过程500还可包括步骤S503：可确定所述多个执行中任务的资源基准线Bi之和Bsum与所述所需资源量Msum之和是否大于所述总当前占用资源量Fsum，也就是说，可确定∑ Bi+Msum是否大于∑ Fi。如果是，则可认为需要停止一个或多个执行中任务，才可达到所需资源量以便新任务能够执行；否则无需停止任何执行中任务就可达到所需资源量。

因此，如果在步骤S503中确定所述多个执行中任务的资源基准线Bi之和Bsum与所述所需资源量Msum之和大于所述总当前占用资源量Fsum，则可采用以下方式确定所述重分配资源量：

步骤S504：对于当前占用资源量Fi大于资源基准线Bi的执行中任务，将所述当前占用资源量Fi超过所述资源基准线Bi的金额Fi-Bi分配给所述新任务。也就是说，首先将各任务中多于资源基准线的所有资源量(如果存在)分配给新任务；以及

步骤S505：按照所述多个执行中任务的优先级，逐个将其占用资源量分配给所述新任务，直到达到所述所需资源量为止，从而每个执行中任务的重分配资源量为在步骤S504中赎回的金额和在S505中分配给所述新任务的资源量之和。也就是说，在将多于资源基准线的所有资源量均分配给了新任务的情况下，仍无法达到新任务的所需资源量，此时会根据优先级来停止一个或多个执行中任务，并将停止的执行中任务的占用资源量分配给新任务，直到达到了新任务的所需资源量。例如，较低优先级的执行中任务将被停止，且其全部占用资源量(经过上面的步骤S505，各执行中任务当前的占用资源量等于其资源基准线)将被分配给新任务。

另一方面，如果在步骤S503中确定所述多个执行中任务的资源基准线Bi之和Bsum与所述所需资源量Msum之和不大于所述总当前占用资源量Fsum，则采用以下方式确定所述重分配资源量：

步骤S506：将要重分配资源量的执行中任务的第一集合初始化为全部所述多个执行中任务，此时该第一集合中的执行中任务的第一数量x等于所述多个执行中任务的数量n；

步骤S507：通过用所述第一集合内的执行中任务的当前占用资源量Fi与其资源基准线Bi的差之和减去所述所需资源量Msum的差除以所述第一数量x来确定第一资源量Favg，即Favg＝(∑(Fi-Bi)-Msum)/x；

步骤S508：确定所述第一集合内当前占用资源量Fi减去资源基准线Bi大于所述第一资源量Favg的执行中任务以作为第二集合，其中所述第二集合中的执行中任务的数量为第二数量y，以及

步骤S509：如果所述第二数量y等于所述第一数量x，则计算所述第一集合内当前占用资源量减去资源基准线Bi大于所述第一资源量的执行中任务的重分配资源量Ri，其中所述重分配资源量Ri等于该执行中任务的当前占用资源量Fi减去资源基准线Bi，再减去所述第一资源量，即Ri＝Fi–Bi-Favg，以及

步骤S510：如果所述第二数量y小于所述第一数量x，则所述第一集合更新为所述第二集合并将所述第一数量x更新为所述第二数量y，并重复上述步骤S507至S510。

可以看出，上述步骤与过程400的步骤基本一致，不同在于在计算剩余资源量时首先将资源基准线减去。上述步骤的细节可参考过程400的描述。

可以看出，以上过程基本没有考虑可释放资源量与重分配资源量的关系。因为，在一些示例中，执行中任务的资源量具备一定的弹性。例如，在用于多个用户的多个虚拟机任务的示例中，虽然一虚拟机任务的当前可释放资源量(空闲资源量)少于重分配资源量，但该任务实际上占用了比其它任务更多的当前占用资源量，且该虚拟机任务可以被调整为在较低占用资源量(即可腾出更多资源量)下运行。此时该虚拟机任务虽然执行效率可能下降，但仍旧可以运行。因此，不考虑可释放资源量的情况下执行重分配在一些情况下可能是合适的，其适合采用如上所述的过程。在有些场景中，可能需要确保重分配资源量小于等于可释放资源量，此时可采用根据本说明书实施例的附加过程，这些附加过程如下。

参考附图6，其示出了根据本说明书实施例的用于在不同执行中任务之间借用差额的过程600的示例流程图。

如附图6所示，过程600可包括：在步骤S601：可确定所述多个执行中任务中的第一执行中任务的重分配资源量是否大于该第一执行中任务的当前可释放资源量。

过程600还可包括：在步骤S602：如果该第一执行中任务的重分配资源量大于该第一执行中任务的当前可释放资源量，则借用一个或多个第二执行中任务的当前可释放资源量来弥补该第一执行中任务的重分配资源量减去当前可释放资源量的差额。

具体而言，借用一个或多个第二执行中任务的当前可释放资源量来弥补该第一执行中任务的重分配资源量减去当前可释放资源量的差额包括：

在步骤S603，可计算该第一执行中任务的重分配资源量减去当前可释放资源量的差额。

在步骤S604，可确定具有剩余的当前可释放资源量的一个或多个第二执行中任务。

在步骤S605，可将所述差额分配到所述一个或多个第二执行中任务。

在执行完差额借用之后，根据需要，可以在稍后的时间执行差额返还。也就是说，由于原本应从第一执行中任务重分配给新任务的差额是从该一个或多个第二执行中任务重分配的(即从该一个或多个第二执行中任务的资源量中将该差额分配给了新任务)，所以在稍后某个时间，该第一执行中任务可将该差额同样地再分配给该一个或多个第二执行中任务，以使最后各执行中任务的最终占用资源量与上面在过程400或过程500中得到的最终资源占用量一致。

基金请求处理实施例

在其它场景中，例如在线交易或在线提现、在线基金赎回等场景中，也可能涉及资源分配问题或资源撤回问题。在这里，资源可以指资金资源，或货币资源等。

如今，许多第三方平台(例如各种在线支付平台、有支付功能的第三方平台、网上银行等)开始提供基金接口服务。这些第三方平台本身不运营基金，但是与基金提供商(例如基金提供商)合作。该第三方平台的用户可以通过由该平台提供的基金接口来执行基金的申购、查询、赎回等步骤。

一般而言，基金可包括开放式基金和封闭式基金等。开放式基金(Open-endFunds)又称共同基金,是指基金发起人在设立基金时，基金单位或者股份总规模不固定，可视投资者的需求，随时向投资者出售基金单位或者股份，并可以应投资者的要求赎回发行在外的基金单位或者股份的一种基金运作方式。相反，封闭式基金(Closed-end Funds)是指基金发行总额和发行期在设立时已确定，在发行完毕后的规定期限内发行总额固定不变的基金。

目前，在大多数第三方平台中，提供的是开放式基金。开放式基金的一大特点是用户可以随时赎回，虽然赎回有一定的限制，这在下面将进一步描述。

基金有多种投资类型。在第三方平台中，目前通常提供的是货币型基金。货币型基金只投资于货币市场，如短期国债、回购、央行票据、银行存款等等，其相对于其它类型的基金的风险较小。

大多数第三方平台提供了多只基金的接口。然而，目前在第三方平台中，用户在任何时刻通常只能持有一只基金。例如，在一种在线支付平台中，用户如果选择申购并持有基金A，则不能再申购基金B。之所以如此，可能是出于以下原因：第一是为了减少系统的复杂度，同时持有多只基金带来系统复杂度的上升；第二是为了保持好的用户体验，在用户持有多只基金时，用户可能无法用基金账户来收款和支付，或者需要用户手动做出选择。在用户只持有一只基金的情况下，在用户想要赎回和/或支付时，只需要从用户持有的基金中扣减相应的份额并转入用户账户即可。

在本说明书的实施例中，实现了允许用户同时持有多只基金。不仅如此，本说明书的实施例允许用户无需知晓基金层的细节，也能实现简单的赎回甚至收款和支付。

系统框架图

参见图7，其示出了根据本说明书实施例的用于处理赎回请求的系统700的示例框图。如图7所示，系统700可包括前端702、产品层704、核心层706、接入层708四个模块。

前端702是指用于用户交互的模块。前端702例如可以是各种在线支付平台(包括移动支付平台)、网上银行等。该前端702接收用户的指令(例如基金的开户、咨询、申购、查看、赎回；支付、还款等指令)，将指令发送给后续模块(例如产品层704)以供处理。前端702还包括从后续模块(例如产品层704)接收处理结果，并将处理结果呈现给用户。

产品层704接收来自前端702的指令，并处理该指令。具体而言，如附图7所示，产品层704可包括理财平台、支付平台、交易决策平台等。

如其名称所暗示的，理财平台用于处理与理财相关的指令，例如从前端702接收并处理基金开户、申购、查看、赎回等指令。理财平台在处理好与理财相关联的指令后，可将该指令发送该交易决策平台，以便执行具体的交易决策。

支付平台用于处理与支付相关的指令，例如从前端702接收并处理支付指令、收款等指令。如下面将介绍的，可将支付平台与交易决策平台连接。

交易决策平台可接收来自理财平台的申购指令，并决定如何将申购金额在各基金之间分配以申购相应的基金。此外，交易决策平台还可接收来自理财平台的赎回指令，并决定如何将赎回金额在各基金之间分配以在相应的基金中赎回。交易决策平台决定如何将申购金额/赎回金额在各基金之间分配的细节将在后文详细描述。

在本说明书实施例中，优选地，可将支付平台与交易决策平台连接并使其相互通信。在此情况下，交易决策平台还可接收来自支付平台的支付指令，将其转换为赎回指令，并决定如何将赎回金额在各基金之间分配。类似地，交易决策平台还可接收来自支付平台的收款指令，将其转换为申购指令，并决定如何将申购金额在各基金之间分配。

用户在支付时，不是从用户的现金账户中支付，而是可以从各基金账户中赎回并使用赎回的资金来执行支付步骤；类似地，用户在收款时，不是将其存入现金账户，而是可以直接将其存储基金账户。通过这种方式，可允许用户在享受类似现金的支付便利的同时，还能享受到资金的基金收益。

在本说明书实施例的多基金平台的情况下，将支付平台与交易平台连接尤其具有优势。利用本说明书的实施例，即便在用户持有多只基金(从而享受更低的风险和更高的申购额度以及赎回限额)的情况下，用户也无需考虑与基金相关联的事项，而只需输入支付金额，就可以实现支付步骤。类似地，用户也可以实现收款步骤。

从上面的描述可以领会，本说明书实施例并单纯涉及金融方面，而是需要对自动化系统的架构和连接方式、数据流向、以及处理流程进行重新设计，从而提升用户体验。

随后，产品层704随后向核心层706发送相应的指令以执行仅仅的申购/赎回，以及支付/收款/还款等步骤。

核心层706接收来自产品层704的指令，并执行相应的步骤。例如，资产交换模块具体执行相应的资产交换。核算中心执行与核算相关的步骤。理财核心执行与基金的开户、申购、查看、赎回等相关的步骤。清算中心执行与资产清算相关的步骤。产品合约模块对相应的产品合约执行处理。价格中心执行与基金行情(例如基金价格等)的同步、查看相关的步骤。在存在借/贷相关步骤的情况下，借记账务模块执行与借/贷相关的步骤。

随后，核心层706将其处理结果传送至接入层708。接入层708负责与各基金提供商的数据接口对接，以执行相关数据接收和发送等操作。例如，接入层708中可包括数据接口，其经由金融网络与各基金提供商(例如图7中的示例基金提供商)中的相应数据接口对接。接入层708还可包括文件工厂。文件工厂可产生各种相关的文件，以实现对各种金融操作的规范化处理和记录。

在本文中，将不对各平台或模块的操作进行具体描述。在阅读上文描述的内容后，本领域技术人员知晓如何具体实现各平台、中心或模块的功能。此外，本说明书实施例可采用不同于以上系统700的任何其它系统来实现。

账户结构及开户

参见图8，其示出了根据本说明书的实施例的用于实现多基金账户的系统的示意图。

如图8所示，用户可通过用户客户端802来向第三方平台804传送赎回请求。例如，客户端802可采用安装在用户的设备(例如智能电话、平板、台式机、膝上型计算机等)上的应用(例如在线支付平台客户端、网上银行客户端等)的形式。替代地，客户但802可采用浏览器等形式，而无需安装特定应用。例如，用户可使用浏览器来访问网页，以直接与服务器交互。

如图8所示，每个用户可在第三方平台804中具有一个总账户，且该总账户下可具有多个子账户，每个子账户可对应于一只基金。而在相应的基金提供商中，根据相应规定，该用户也应当具有一只基金账户以便持有该只基金。用户在第三方平台中的总账户的每个子账户可与其在相应基金中的账户相对接，从而实现基金数据的传送和接收，以及其它相关操作。因此，用户在开户时，可能需要同意其想要持有的每只基金的开户条款，以便在对应基金提供商开立相应的基金账户。

第三方平台804可采用本说明书实施例的方案来处理来自用户客户端802的赎回请求，如下面详细描述的。

从上文可以看出，本说明书的实施例设计了单独的数据结构和数据接口，以便于实现上述方法。例如，该数据结构可包括用户持有的基金名称、每只基金的剩余总份额，每只基金的可用份额、每只基金的限额、每只基金的剩余限额等。此外，各只基金的相应项目可被关联，例如通过每只基金的限额可以容易地确定总限额，通过每只基金的剩余份额可以容易地确定总剩余份额、总可用份额、总剩余限额等。

此外，该数据结构还可将各只基金的步骤历史相关联。例如，在某天的步骤中，可容易地查找该步骤所对应的每只基金的步骤。例如，在查询2019年12月01日的赎回步骤时，可查询到执行该步骤时每只基金的被赎回份额以及剩余份额。通过这种数据结构，可以容易地、相互关联地管理多只基金。

该数据接口允许第三方平台与各基金提供商之间传递数据，从而实现相应的查询和请求，从而使得上述方法的各操作能够被实现。

基金申购

在申购时，用户可选择单独申购特定基金并指定申购金额。此时，用户所输入的申购金额将从其总账户划归到相应的子账户，随后发送申购请求并将该申购金额打入到相应的基金账户，从而转换为该基金账户中的基金份额。

替代地，用户可仅输入想要申购的金额。在此情况下，可在各基金之间分配该金额，例如平均分配份额。随后，可将相应金额划归到相应子账户，随后发送申购请求并将所分配的申购金额打入相应的基金账户，从而转换为相应基金账户中的基金份额。

在将支付平台与基金平台打通的示例中，用户在收款后，可直接使用所收到的款项来申购基金。此时，用所收到的款项的金额作为申购的金额，随后如上所述地执行基金申购步骤。

基金赎回

在赎回时，用户可选择单独赎回特定基金并指定赎回金额。此时，系统将向用户所选择的基金发送赎回请求，该赎回请求中包括该赎回金额。基金在接收到赎回请求后，会将基金账户中的基金份额转换为资金并打入到第三方平台的相应子账户中，并划归到总账户中。

替代地，用户可仅输入想要赎回的总金额。在此情况下，可采用本说明书的实施例来决定如何在各基金之间分配该总金额。随后，系统将向各基金发送赎回请求，该赎回请求中包括相应基金所分配的赎回金额。基金在接收到赎回请求后，会将基金账户中的基金份额转换为资金并打入到第三方平台的相应子账户中，并划归到总账户中。

在将支付平台与基金平台打通的示例中，用户在收到支付请求后，可将该支付请求中的金额作为赎回金额，采用上述基金赎回步骤来赎回资金，并支付给另一用户。

多基金赎回请求处理实施例

参见图9，其示出了根据本说明书实施例的用于在服务器上执行新任务的方法900的示例流程图。

如图9所示，方法900可包括：在步骤S901，可接收来自用户的对多只基金的赎回请求。所述赎回请求可指定对所述多只基金的总赎回金额。

例如，用户可使用如图8中所示的用户客户端802输入总赎回金额，并点击赎回按钮。此时，用户客户端802可将相应的赎回请求传送给该第三方平台804。

优选地，用户可不分别输入每只基金的赎回金额或赎回比例等信息，而只是简单地赎回其想要赎回的总赎回金额。这大大地简化了用户所需要执行的操作和所需进行的计算，提升了用户体验。

方法900还可包括：在步骤S902，对于所述多只基金中的每只基金，可向该基金的基金提供商提供的基金数据接口传送对所述用户当前持有的该基金的当前持有金额和/或当前可赎回金额的查询请求。例如，可例如经由图7所示的接口层708，通过基金提供商提供的基金数据接口向基金提供商查询所述用户当前持有的该基金的当前持有金额和当前赎回金额。例如，该查询请求可包括该用户在该基金提供商处的基金账户的用户标识(例如用户ID)、该第三方平台的平台标识(例如平台的标识符，如平台名称、代号等)以及要查询的数据(例如当前持有金额和/或当前可赎回金额)。该查询请求还可包括对其它信息的查询，例如该用户当日在该基金中的已赎回金额、该用户在该基金中的冻结金额、以及其它信息。

方法900还可包括：在步骤S903，可从所述多只基金中的每只基金的基金提供商接收所查询到的所述当前持有金额和/或所述当前可赎回金额。基金的基金提供商在接收到来自第三方平台的查询之后，可经由其基金数据接口向该第三方平台传送所查询到的信息，例如该用户在该基金中的当前持有金额和/或当前可赎回金额等。在查询其它信息(例如已赎回金额、冻结金额或其它信息)的情况下，基金提供商同样可经由其基金数据接口向该第三方平台传送该其它信息。第三方平台例如可经由图7所示的接口层708接收从基金提供商传送的信息。

方法900还可包括：在步骤S904，可基于所查询到的所述多只基金中的每只基金的所述当前持有金额和/或所述当前可赎回金额，将所述总赎回金额自动分配给所述多只基金以确定每只基金的分配赎回金额，以使所述用户对每只基金的最终持有金额均衡。也就是说，将该多只基金中的一只或多只基金的当前持有金额的一部分作为所分配的赎回金额来赎回，使得从该一只或多只基金中赎回的总金额等于从用户接收的赎回请求中的总赎回金额。该赎回金额可能对于每只基金是不同的，且可能并非每只基金都将被赎回。最终持有金额是指在赎回结束后该用户在基金中的持有金额，其是在从该用户在该基金的当前持有金额中减去对该基金的赎回金额之后该用户最终在该基金中持有的金额。

所谓使得每只基金的最终持有金额均衡，可以用各种目标来衡量。在一个简单示例中，其指尽量使得每只基金的最终持有金额相等或大致相等。使得用户在每只基金的最终持有金额大致相等有额外的好处。根据分散投资理论，在每只基金的风险度大致相似的情况下，使得用户在每只基金的最终持有金额大致相等，可以在用户预期收益不变的情况下，使得用户风险最小化。此外，使得用户在每只基金的最终持有金额大致相等，还可使用户更清楚简便地掌握其资金分配情况。而且，在每个用户在每个基金的持有金额大致相等的情况下，更容易实现各基金的盘子大致相同，从而方便第三方平台对基金公司的管理。在下面的示例中，主要以此情形为例来进行说明。

使得每只基金的最终持有金额均衡还可具有其它形式。例如，可计算每只基金的风险度，并且在经风险调整的情况下，使得用户在每只基金中的预期风险大致相等。

用于将所述总赎回金额自动分配给所述多只基金以确定每只基金的分配赎回金额的方法在下面参考图12和图13来详细描述。

方法900还可包括：在步骤S905，可对于所述多只基金中的一只或多只基金，向该基金的基金提供商提供的基金数据接口传送赎回请求，所述赎回请求包括该基金的所述分配赎回金额。正如上面所提及的并且将在下面详细描述的，在许多情况下，许多基金被分配到的分配赎回金额为0。也就是说，可仅向分配赎回金额不为0的基金的基金提供商传送赎回请求，而可不向分配赎回金额为0的基金的基金提供商传送赎回请求。在接收到赎回请求之后，基金提供商将执行赎回、结算、清算等操作，并将赎回结果传送给该第三方平台。如果赎回成功，所赎回的资金将被从该用户在该基金的基金账户转移至该用户在该第三方平台的与该基金对应的子账户，并最终被归集到该用户在该第三方平台的总账户。此时，赎回操作完成，该用户所持有的基金份额被转换为资金存入该用户在该第三方平台的子账户或总账户中。

然而，可以设想，可能出现以下情形：来自用户的赎回请求中指定的总赎回金额太高，以至于即便将全部基金中的可赎回金额全部赎回，也无法达到该总赎回金额。此时，可以向请求方传送该新任务的总赎回金额太高的提示。具体而言，在此情况下，可向用户的客户端设备传送“额度不足！”的提示。

为此，在上述步骤S903之后且在步骤S904之前，可先执行用于确定赎回请求中指定的总赎回金额是否太高的过程。参考图10，其示出了根据本说明书的实施例的用于确定赎回请求指定的总赎回金额是否太高的过程1000的示例流程图。

过程1000可包括：在步骤S1001，可基于所查询到的每只基金的所述当前可赎回金额计算所述用户的总当前可赎回金额。例如，通过将每只基金的当前可赎回金额求和，即可得到服务器的总当前可赎回金额。

过程1000可包括：在步骤S1002，可将所述总赎回金额与所述总当前可赎回金额进行比较。

过程1000还可包括：在步骤S1003，如果所述总赎回金额大于所述总当前可赎回金额，则可提示所述赎回请求指定的总赎回金额太高。如上所述，第三方平台可向用户的客户端设备传送“额度不足！”的提示。用户在接收到此提示之后，可基于总当前可赎回金额调整其总赎回金额。

另一方面，如果总赎回金额小于等于总当前可赎回金额，可以继续执行如图9所示的步骤S904，将总赎回金额执行自动分配。

对于基金而言，可能存在一些附加的限制。例如，根据监管机构(例如证监会)的规定，可能某一只或多只基金每天最多只能赎回一定限额(例如5000元)，该限额可被称为当日赎回限额。在存在赎回限额的情况下，可能还需要保证用户的赎回请求中指定的总赎回金额不超过所有基金的赎回限额之和，否则将不可能达到该总赎回金额。

为此，在上述步骤S903之后且在步骤S904之前，可先执行用于相对于总赎回限额确定赎回请求中指定的总赎回金额是否太高的另一过程。参考图11，其示出了根据本说明书的实施例的用于相对于总赎回限额确定赎回请求指定的总赎回金额是否太高的过程1100的示例流程图。

过程1100可包括：在步骤S1101，可基于所述多只基金中的每只基金的赎回限额来计算所述多只基金的总当日赎回限额。例如，通过将每只基金的当前可赎回金额求和，即可得到服务器的总当日赎回限额。例如，假设每只基金的赎回限额为5000元，则10只基金的总当日赎回限额将为5000*10＝50000元。另外，假设用户在当日已对一只或多只基金执行过赎回，则当日赎回限额应当是监管机构规定的每日限额减去当日已经赎回的金额，然后再计算所述多只基金的总当日赎回限额。

过程1100可包括：在步骤S1102，可将所述总赎回金额与所述总当日赎回限额进行比较。

过程1100还可包括：在步骤S1103，如果所述总赎回金额大于所述总当日赎回限额，则提示所述用户无法赎回所述总赎回金额。此时的提示可与上面针对过程1000所述的提示相同或者不同。例如，第三方平台可向用户的客户端设备传送“赎回超限！”的提示。用户在接收到此提示之后，可基于总当日赎回限额调整其总赎回金额。

另一方面，如果总赎回金额小于等于总当日赎回限额，可以继续执行如图9所示的步骤S904，将总赎回金额执行自动分配。

参考图12，其示出了根据本说明的一实施例的将所述总赎回金额在所述多只基金之间自动分配的过程1200的示例流程图。如上所述，该过程可在接收到每只基金的当前持有金额和当前可赎回金额之后进行。

如图12所示，过程1200可包括步骤S1201：将要赎回的基金的第一集合初始化为全部所述多只基金，此时所述第一集合中的基金的第一数量等于所述多只基金的数量。

为了使得用户在每只基金的最终持有金额大致相同，可能未必从所有基金赎回资金。例如，一些当前持有金额较少的基金可能不会被赎回任何资金。因为可能并非从所有基金均赎回资金，所以定义第一集合，其包括要从中赎回资金的基金。在初始化时，将第一集合设置为全部多只基金。也就是说，在初始化时，假定在所有基金中均赎回一部分资金，以作为后续处理的初始条件。

例如，假设该用户总共持有n只基金，此时所述第一集合中的基金的数量x＝n。

过程1200还可包括步骤S1202：可通过用所述第一集合内的基金的当前持有金额Fi之和减去所述总赎回金额Msum的差除以第一数量x来确定第一金额Favg，也就是说：

Favg＝(∑ Fi-Msum)/x (式1)

其中，如上所述，Fi为第一集合内的基金的当前持有金额，而第一数量x的初始值等于所述多只基金的数量n。在后续过程中，随着迭代的进行，可能需要逐步改变所述第一集合，从而使得第一数量x的值被更新而不再等于n，这将在下文中描述。

上式的含义可以领会如下：

通过对所述第一集合内的基金的当前持有金额Fi求和，可以得到所述第一集合中的基金(即要被赎回一些资金的那些基金)的总当前持有金额∑ Fi。

随后，将所述第一集合内的基金的总当前持有金额∑ Fi减去所述总赎回金额Msum，可以得到在将总赎回金额Msum赎回后，该用户所持有的该多只基金的总剩余持有金额∑ Fi-Msum。如上所述，第一数量x反映了要赎回一些资金的基金的数量。通过将该第一集合内的总剩余持有金额∑ Fi-Msum除以该第一集合内的基金的第一数量x，即可得到该第一集合内的各基金的平均剩余持有金额Favg。也就是说，Favg＝(∑ Fi–Msum)/x。

过程1200还可包括步骤S1203：可确定所述第一集合内当前持有金额Fi大于等于所述第一金额Favg的基金以作为第二集合，其中所述第二集合中的基金的数量为第二数量y。也就是说，将所述第一集合内的每只基金的当前持有金额Fi与通过式1得到的平均剩余持有金额Favg进行比较，并选择当前持有金额Fi大于等于第一金额Favg的那些基金并将其放入第二集合。第二集合中的基金的数量用第二数量y来表示。可以领会，第二数量y小于或等于第一数量x。

过程1200还可包括步骤S1204：如果所述第二数量y等于所述第一数量x，则可计算所述第一集合内当前持有金额大于所述第一金额的基金的分配赎回金额Ri，其中所述分配赎回金额Ri等于该基金的当前持有金额Fi减去所述第一金额，即Ri＝Fi–Favg。可以领会，如果一基金Ti的当前持有金额Fi大于等于所述第一金额Favg，则该基金Ti能够被赎回一些资金；而如果基金Ti的当前持有金额Fi小于第一金额Favg，则不应将该基金Ti赎回任何资金，否则其剩余持有金额将小于平均值。如果第二数量y等于第一数量x，则说明第一集合中的基金均能够被赎回一些资金，此时可直接计算每只基金需要赎回的分配赎回金额，即其超出平均剩余持有金额的量Ri＝Fi–Favg。该分配赎回金额Ri将被从该基金Ti中赎回。在计算了分配赎回金额之后，分配过程结束。

在一些情况下，由于基金提供商对用户赎回金额的基本单位有规定或者其它原因，所计算的分配赎回金额Ri可能出现尾差。假设所计算的某个基金的分配赎回金额Ri为(2000/3)元，即1333.333…元(例如，假设该基金的当前持有金额为5000元，而第一金额Favg为26000/6元，此时该基金的分配赎回金额为5000-26000/6＝2000/3＝1333.333…元)。在一个示例中，有些基金提供商规定只能赎回以元为单位的金额。例如，仅允许赎回例如1333元，而不允许赎回1333.3元。此时，在计算分配赎回金额时，通常会将尾差舍去，即将该基金的分配赎回金额Ri确定为1333元。通常其它基金也存在尾差。此时，实际上将每个基金的分配赎回金额相加，与总赎回金额之比，可能会少一些。例如，所有基金的尾差之和(总尾差)例如可能是1元。此时每个基金的分配赎回金额加起来可能比总赎回金额少1元。在这种情况下，可将该总尾差分配给仍存在持有金额的任何基金。替代地，可将该总尾差分配给仍存在可赎回金额的任何基金。

在另一个示例中，即便没有上述规定，通常也支持赎回以分(即0.01元)为单位的金额。例如，通常基金仅允许赎回例如1333.33元，而不允许赎回1333.333元。此时，1333(或者1333.33)元后面的差值即为尾差。此时总尾差可能是1分钱或几分钱。同样地，总尾差也可被分配给仍存在持有金额或可赎回金额的任何基金。

过程1200还可包括步骤S1205：如果所述第二数量y小于所述第一数量x，则可将所述第一集合更新为所述第二集合并将所述第一数量x更新为所述第二数量y，并重复上述步骤S1202至S1205。可以领会，如果第二数量小于第一数量，则说明第一集合中有些基金的当前持有金额小于平均剩余持有金额，那么这些基金就不应被赎回。此时，只能在第二集合中的第二数量的基金中重新计算平均剩余持有金额Favg。因此，应当将用于计算平均剩余持有金额Favg的第一集合更新为第二集合(相应地，应当将第一数量更新为第二数量，即令x＝y)，并重复执行步骤S1202至S1205，直到满足S1204中的条件为止。

对于基金而言，通常存在赎回基准线。所谓赎回基准线是指某基金的最小持有金额。基金提供商可不允许持有少于赎回基准线的基金。该赎回基准线可能来自基金为了方便管理的规定，也可能来自监管机构的规定。例如，一些基金规定赎回基准线为1000元。当用户持有的基金的金额小于1000元时，用户在赎回时应当赎回全部金额。在一些情况下，可能希望保留该基金而争取不被完全赎回，即尽量保证最终持有金额大于赎回基准线。

参考图13，其示出了根据本说明的实施例的在考虑赎回基准线的情况下，将所述总赎回金额在所述多只基金之间自动分配的过程1300的示例流程图。

如图13所示，过程1300可包括步骤S1301：可基于所查询到的每只基金的所述当前持有金额Fi计算所述用户的总当前持有金额Fsum。也就是说，可计算用户持有的所有基金的当前持有金额Fi的和Fsum。也就是说，Fsum＝∑ Fi。

过程1300还可包括步骤S1302：可确定每只基金的赎回基准线Bi。在许多情况下，每只基金的赎回基准线可能相同，例如均为1000元。在另一些情况下，一只或多只基金的赎回基准线可能不同。此时，该第三方平台可记录每只基金的赎回基准线。替代地，第三方平台可使用基金提供商提供的接口来查询其赎回基准线。

过程1300还可包括步骤S1303：可确定所述多只基金的赎回基准线Bi之和Bsum与所述总赎回金额Msum之和是否大于所述总当前持有金额Fsum，也就是说，可确定∑ Bi+Msum是否大于∑ Fi。如果是，则可认为需要全部赎回一只或多只基金，才可达到总赎回金额；否则无需全部赎回任何基金就可达到总赎回金额。

因此，如果在步骤S1303中确定所述多只基金的赎回基准线Bi之和Bsum与所述总赎回金额Msum之和大于所述总当前持有金额Fsum，则可采用以下方式确定所述分配赎回金额：

步骤S1304：对于当前持有金额Fi大于赎回基准线Bi的基金，可将所述当前持有金额Fi超过所述赎回基准线Bi的金额Fi-Bi赎回。也就是说，首先将各基金中多于赎回基准线的所有资金(如果存在)赎回；以及

步骤S1305：按照所述多只基金的优先级，逐个将其剩余资金赎回，直到达到所述总赎回金额为止，从而最终每只基金的分配赎回金额为在步骤S1304中赎回的金额和在S1305中赎回的金额之和。也就是说，在将多于赎回基准线的所有资源量均分配给了新任务的情况下，仍无法达到新任务的总赎回金额，此时会根据优先级来赎回一个或多只基金的剩余资金，直到达到了新任务的总赎回金额。例如，较低优先级的基金中的剩余金额(经过上面的步骤S1305，各基金当前的剩余金额等于其赎回基准线)将被赎回。

另一方面，如果在步骤S1303中确定所述多只基金的赎回基准线Bi之和Bsum与所述总赎回金额Msum之和不大于所述总当前持有金额Fsum，则采用以下方式确定所述分配赎回金额：

步骤S1306：可将要赎回的基金的第一集合初始化为全部所述多只基金，此时所述第一集合中的基金的第一数量x等于所述多只基金的数量n；

步骤S1307：可通过用所述第一集合内的基金的当前持有金额Fi与其赎回基准线Bi的差之和减去所述总赎回金额Msum的差除以所述第一数量x来确定第一金额Favg，即Favg＝(∑(Fi-Bi)-Msum)/x；

步骤S1308：可确定所述第一集合内当前持有金额Fi减去赎回基准线Bi大于所述第一金额Favg的基金以作为第二集合，其中所述第二集合中的基金的数量为第二数量y，以及

步骤S1309：如果所述第二数量y等于所述第一数量x，则可计算所述第一集合内当前持有金额减去赎回基准线Bi大于所述第一金额的基金的分配赎回金额Ri，其中所述分配赎回金额Ri等于该基金的当前持有金额Fi减去赎回基准线Bi，再减去所述第一金额，即Ri＝Fi–Bi-Favg，以及

步骤S1310：如果所述第二数量y小于所述第一数量x，则可将所述第一集合更新为所述第二集合并将所述第一数量x更新为所述第二数量y，并重复上述步骤S1307至S1310。

特别地，在上面的步骤S1309中，如果存在总尾差，可将该总尾差分配给持有金额大于赎回基准线的任何基金。如果没有任何基金的持有金额大于赎回基准线，则可跳到步骤S1310进行重新分配。

可以看出，上述步骤与过程1200的步骤基本一致，不同在于在计算剩余金额时首先将赎回基准线减去。上述步骤的细节可参考过程1200的描述。

对于基金而言，如上所述，可能存在当日赎回限额。有时候，为一只或多只基金分配的分配赎回金额可能大于其当日赎回限额。也就是说，在其分配赎回金额和当日赎回限额之间存在差额。此时可利用基金的特性，首先借用其它基金的赎回限额，并在次日或以后归还。这种行为可被称为过桥。

在参考附图14，其示出了根据本说明书实施例的用于在不同基金之间借用差额的过程1400的示例流程图。

如附图14所示，过程1400可包括：在步骤S1401，可确定所述多只基金中的第一基金的分配赎回金额是否大于该第一基金的当日赎回限额。例如，假如一只基金(例如基金A)的当日赎回限额为5000元(且未被使用)，但为其分配了6000元的分配赎回金额，则其分配赎回金额大于当日赎回限额。

过程1400还可包括：在步骤S1402：如果该第一基金的分配赎回金额大于该第一基金的当日赎回限额，则借用一个或多个第二基金的当日赎回限额来弥补该第一基金的分配赎回金额减去当日赎回限额的差额。接上例，分配赎回金额与当日赎回限额之间存在差额6000-5000＝1000元。此时，第一基金可向一个或多个第二基金来借用该差额。

具体而言，借用一个或多个第二基金的当日赎回限额来弥补该第一基金的分配赎回金额减去当日赎回限额的差额可包括：

在步骤S1403，可计算该第一基金的分配赎回金额减去当日赎回限额的差额。在上例中，该差额为1000元。

在步骤S1404，可确定具有剩余的当日赎回限额的一个或多个第二基金。例如，假设基金B被分配了2000元的分配赎回金额，则该基金B的当日赎回限额还剩余5000-2000＝3000元。此时，可确定该基金B具有剩余的当日赎回限额。在一些其它上例中，可能需要多只第二基金来共同凑够该差额。

在步骤S1405，可将所述差额分配到所述一个或多个第二基金。接上例，可将该1000元的差额从基金A分配给基金B。具体而言，可基金A的分配赎回金额调整为其当日赎回限额5000元(减少差额1000元)，而将基金B的分配赎回金额增加该差额1000元，即此时基金B的分配赎回金额为2000+10000＝3000元。即，当天基金A赎回5000元，基金B赎回3000元。可以看出，总赎回金额不变。

优选地，在执行完差额借用之后，根据需要，可以在次日或以后执行差额返还。具体而言，优选地，过程S1400还可包括以下步骤：在赎回次日或以后，从该第一基金赎回该差额，并向所述一个或多个第二基金申购所述差额。接上例，在次日或以后，当基金A具有了赎回额度后，可从基金A赎回该差额1000元。但是，该差额并不会被转移至第三方平台的现金账户，而是被用于申购基金B。也就是说，用赎回的1000元差额来申购基金B。通过返还，可使最后各基金的最终持有金额与上面在过程1200或过程1300中得到的最终持有金额一致。

当然，也可以不执行此返还步骤。

处理基金赎回请求的简单示例

假定一用户持有的基金组合如下表所示，其总共包括10只基金，其中基金A-E的当前持有金额和当前可赎回金额均为10000元，而基金F-J的当前持有金额和当前可赎回金额均为2000元。可以看出，其总当前持有金额和总当前可赎回金额为60000元。

现在，假设用户请求赎回30000元。

如上面的示例所述，在初始化时，令第一集合为全部基金A-J，第一数量为10。

随后，可计算第一金额Favg＝(60000-30000)/10＝3000元。

经过比较，发现基金A-E的当前持有金额大于该第一金额3000元，因此将基金A-E放入第二集合，第二数量为5。

可以看出，第二数量5小于第一数量10，此时将第一集合更新为基金A-E，并将第一数量更新为5，重新计算第一金额Favg＝(50000-30000)/5＝4000元。

经过比较，发现基金A-E的当前持有金额大于该第一金额4000元，因此将基金A-E放入第二集合，第二数量为5。此时第一数量等于第二数量，因此可以计算基金A-E的每一个的分配赎回金额Ri＝10000–4000＝6000元。

如果不考虑当日赎回限额，则可从基金A-E各赎回6000元而不从基金F-J赎回。

如果考虑赎回限额，假设每只基金的当日赎回限额大于等于6000元，仍旧是从基金A-E各赎回6000元而不从基金F-J赎回。

如果假设每只基金的当日赎回限额均为5000元，由于对于基金A-E中的每一者而言当日赎回限额5000元均小于其分配赎回金额6000元，因此需要借用其它基金F-J的赎回额度。

例如，可在当日从基金A-E各赎回5000元(赎回限额)，而其差额1000元从基金F-J赎回，即在当日从基金F-J各赎回1000元。总赎回金额等于用户请求赎回的金额30000元。

而在次日或以后，可将该差额返还。具体而言，在次日或以后，可从基金A-E各再赎回1000元，以达到其分配赎回金额6000元。随后，用赎回的5000元对基金F-J各申购1000元。

通过这种方式，在最后仍旧达到了不考虑赎回限额的情况下的分配赎回金额。

其表格示例如下表1所示：

表1

处理交易请求的方法实施例

如同上面提及的，可以将支付平台和基金管理平台打通。例如，可将用户所收到的收款直接在多只基金中执行申购。还可以在用户支付给其它用户时，首先在多只基金中执行赎回，随后将赎回的资金支付给其它用户。通常，这需要事先通知用户并得到用户的确认。

参考图15，其示出了根据本说明书的实施例的用于处理支付请求的方法1500的流程图。

如图15所示，方法1500可包括：在步骤S1501中，可接收来自第一用户的支付请求，所述支付请求指定将一支付金额支付给第二用户。例如，第一用户在使用在线支付平台购买物品、转账或执行将资金转移至其它账户的其它操作时，该第三方平台可接收来自该第一用户的支付请求。通常，该支付请求将指定所需支付的支付金额以及该支付金额将被转移给的第二用户，即目标用户。

方法1500还可包括：在步骤S1502中，可将所述支付金额作为总赎回金额，采用以上任何实施例中的处理基金赎回请求的方法，从所述第一用户所持有的多只基金中赎回所述总赎回金额。

方法1500还可包括：在步骤S1503中，可将所述总赎回金额支付给所述第二用户。在该支付金额被赎回并回到该第三方平台的该用户的总账户之后，该第三方平台可将该支付金额转移给该第二用户，从而完成支付操作。

类似地，在第一用户接收到来自其它用户的转账时，也可将其所接收的转账金额作为申购金额，自动申购该第一用户所持有的多只基金。

其它资源撤回实施例

需要领会，在许多场景中，可能需要从多个资源池中撤回一定量的资源。本文中所称的“资源”，可指各种资源，包括现实资源、虚拟资源等等。本文中所称的“资源池”，是指包括或利用所述资源的容器。

上面的多基金赎回(甚至前面的任务处理)的实施例均可视为下面描述的从多个资源池中撤回一定量的资源的实施例的特例。在上面详细描述的基金申购和赎回场景的实施例中，用户的资金是资源，而用户所持有的基金可被当作资源池，此时用户的资金以基金份额的形式存在于基金这种资源池中。

在其它实施例中，也可能存在其它资源和资源池。例如，在通信场景中，可能多个蜂窝小区要利用其资源来服务其覆盖范围内的用户。此时，每个蜂窝小区可被设想为资源池，而蜂窝小区的资源(例如频率资源、时隙资源等)就是资源池内的资源。假设由于某种原因一个或多个蜂窝小区变得不可用(例如故障)，则该不可用的蜂窝小区所服务的用户需要变为由其它蜂窝小区来提供服务。此时，可能需要在仍可用的多个蜂窝小区内进行资源的重新分配(例如在所述多个可用蜂窝小区的资源中抽调出变得不可用的蜂窝小区的资源)，以便继续提供服务。

又例如，在货物集散场景中，对于某些电商而言，可能需要将货物囤积在多个地区的多个仓库中。此时，货物是一种资源，而仓库可被认为是资源池。如果要从该多个仓库中取走一定量的货物，则可被认为是从多个资源池中撤回一定量的资源。

再例如，在云服务场景中，可能存在多个虚拟机(VM)。这些虚拟机占用着服务器的实际资源(例如I/O资源、存储资源、CPU处理能力资源等)。此时，一个虚拟机可对应于一个资源池。有时候可能需要缩减这些虚拟机所占用的资源量。例如，由于需要创建新的虚拟机，则可能需要为新的虚拟机分配资源，而这些资源需要从该多个原虚拟机中撤回。又例如，可能服务器由于宕机或者例如磁盘损坏等问题，可能使得总资源量减少，这些减少的资源量也需要被从该多个原虚拟机中撤回。

可以领会，还存在从多个资源池中撤回一定量的资源的其它情景，其均可利用如本说明书实施例所述的方案。

下面，一般性地介绍从多个资源池中撤回一定量的资源的过程的具体实施例。

参见图16，其公开了根据本说明书实施例的用于处理资源撤回请求的方法1600的示例流程图。在下面的示例中，在多数情况下使用虚拟机场景作为示例，但本领域技术人员可以领会，该方法可适用于其它场景。

方法1600可包括：在步骤S1601，接收对多个资源池的资源撤回请求，所述资源撤回请求指定对所述多个资源池的总撤回资源量。这种资源撤回请求可以是显式的或隐式的。例如，在虚拟机的示例中，系统管理员可以发出撤回一定的资源量(总撤回资源量)的显式请求。替代地，该资源撤回请求可由部分服务器宕机或磁盘损坏等事件来触发(例如由监督程序传送)。此时，该总撤回资源量可以等于由于该事件而损失的资源量。

方法1600还可包括：在步骤S1602，对于所述多个资源池中的每个资源池，可传送对该资源池的当前持有资源量和/或当前可用资源量的查询请求。例如，在虚拟机示例中，负责统筹资源分配的监督程序可向每个资源池(例如每个虚拟机)传送对该资源池的当前持有资源量和/或当前可用资源量的查询请求。例如，该当前持有资源量可以指该虚拟机被分配的资源量，而当前可用资源量可以指该虚拟机中当前空闲而可被其它虚拟机使用的资源量。

方法1600还可包括：在步骤S1603，可接收所查询到的每个资源池的当前持有资源量和/或所述当前可用资源量。例如，监督程序可从每个虚拟机接收所查询到的当前持有资源量和/或当前可用资源量。在一些情况下，监督程序本身可能知晓每个虚拟机的当前持有资源量和/或当前可用资源量，在此情况下，步骤S1602和步骤S1603可被省略或隐式执行。

方法1600还可包括：在步骤S1604，基于所查询到的所述多个资源池中的每个资源池的所述当前持有资源量和/或所述当前可用资源量，可将所述总撤回资源量自动分配给所述多个资源池以确定每个资源池的分配撤回资源量，以使每个资源池的最终持有资源量均衡。所谓最终持有资源量均衡，在虚拟机示例中，可指每个虚拟机的最终持有资源量相等或大致相等。

方法1600还可包括：在步骤S1605，对于所述多个资源池中的一个或多个资源池，可从该资源池撤回相应的分配撤回资源量。

与上面的基金赎回或者新任务处理的示例类似，为了避免总撤回资源量太多，可在自动分配步骤之前执行以下操作。首先，可基于所查询到的每个资源池的所述当前可用资源量计算总当前可用资源量。随后，可将所述总撤回资源量与所述总当前可用资源量进行比较。如果所述总撤回资源量大于所述总当前可用资源量，则可提示无法撤回所述总撤回资源量。

在一些特殊情况下，服务器对于资源的撤回可能有一些规定。例如，在当前周期内(例如当日)，可能具有周期撤回限额(例如当日撤回限额)。例如，为了保证当前周期内任务的平稳执行，可能每个周期不允许撤回大于撤回限额的资源量。此时，可执行以下操作：首先，可基于所述多个资源池中的每个资源池的当日撤回限额来计算所述多个资源池的总当日撤回限额。随后，可将所述总撤回资源量与所述总当日撤回限额进行比较。如果所述总撤回资源量大于所述总当日撤回限额，则可提示无法撤回所述总撤回资源量。

大致而言，上述自动分配操作可按以下方式来执行。

首先，可初始化要从中撤回资源的资源池集合。例如，该资源池集合可被初始化为全部虚拟机。替代地，该资源池集合可被初始化为其它集合，例如由系统管理员或监督程序指定的集合。

随后，可迭代更新所述资源池集合以便所述资源池集合中的所有资源池的当前持有资源量均大于经撤回资源后的平均持有资源量。

接着，可基于所述平均持有资源量来计算经更新的所述资源池集合中的资源池的分配撤回资源量。

上述步骤的具体细节可参考过程400和500和/或过程1200和1300的示例，在此不再赘述。

与上面的新任务处理或多基金赎回实施例类似，在其它场景下，也可能遇到资源池具有资源基准线的情形。例如，对于虚拟机示例，可能每个虚拟机(资源池)具有最小资源要求，该最小资源要求可被视为资源基准线(其类似于赎回基准线)。在存在资源基准线的情况下，该自动分配操作还可包括以下操作。

可确定所述多个资源池的每个资源池的资源基准线。例如，监督程序或系统管理员可查询或以其它方式来确定每个虚拟机的最小资源要求。如果所述多个资源池的资源基准线之和与所述总撤回资源量之和大于等于所述多个资源池的总当前持有资源量，则可在每个资源池的最终持有资源量大于等于其资源基准线的情况下确定每个资源池的分配撤回资源量。如果所述多个资源池的资源基准线之和与所述总撤回资源量之和不大于所述多个资源池的总当前持有资源量，则可将每个资源池的当前持有资源量中大于其资源基准线的资源量均划入其分配撤回资源量，并随后可按照优先级将一个或多个资源池的剩余持有资源量也划入其分配撤回资源量。

上述步骤的具体细节可参考过程400和500和/或过程1200和1300的示例，在此不再赘述。

在一些情况下，在每个资源池(例如虚拟机)具有当日撤回限额(或其它周期撤回限额)的情况下，可在不同资源池之间执行借用，以在满足周期撤回限额的情况下，仍能撤回该总撤回资源量。该借用过程可通过以下步骤来实现。

首先，可确定所述多个资源池中的第一资源池的分配撤回资源量是否大于该第一资源池的当日撤回限额。如果该第一资源池的分配撤回资源量大于该第一资源池的当日撤回限额，则可借用一个或多个第二资源池的当日撤回限额来弥补该第一资源池的分配撤回资源量减去当日撤回限额的差额。所述借用具体可通过以下方式来实现。

例如，可计算该第一资源池的分配撤回资源量减去当日撤回限额的差额。随后，可确定具有剩余的当日撤回限额的一个或多个第二资源池。随后，可将所述差额分配到所述一个或多个第二资源池。

在后续周期(例如次日或以后)，可归还借用的差额。该归还操作可通过以下方式来实现。例如，在撤回次日或以后，可从该第一资源池撤回该差额，并向所述一个或多个第二资源池补充所述差额。

需要领会，由于资金是一种资源且基金可被视为资源池，因此在阅读上面的一般性的资源撤回过程时，可参考上面针对多基金赎回实施例所描述的细节。

本申请还公开了一种包括存储于其上的计算机可执行指令的计算机可读存储介质，所述计算机可执行指令在被处理器执行时使得所述处理器执行本文所述的各实施例的方法。

此外，本申请还公开了一种系统，该系统包括用于实现本文所述的各实施例的方法的装置。

可以理解，根据本说明书的一个或多个实施例的方法可以用软件、固件或其组合来实现。

应该理解，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置和系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。需要领会的是，本说明书公开了多个实施例，这些实施例所公开的内容可以互相参照来理解。

应该理解，上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

应该理解，本文用单数形式描述或者在附图中仅显示一个的元件并不代表将该元件的数量限于一个。此外，本文中被描述或示出为分开的模块或元件可被组合为单个模块或元件，且本文中被描述或示出为单个的模块或元件可被拆分为多个模块或元件。

还应理解，本文采用的术语和表述方式只是用于描述，本说明书的一个或多个实施例并不应局限于这些术语和表述。使用这些术语和表述并不意味着排除任何示意和描述(或其中部分)的等效特征，应认识到可能存在的各种修改也应包含在权利要求范围内。其他修改、变化和替换也可能存在。相应的，权利要求应视为覆盖所有这些等效物。

同样，需要指出的是，虽然已参照当前的具体实施例来描述，但是本技术领域中的普通技术人员应当认识到，以上的实施例仅是用来说明本说明书的一个或多个实施例，在没有脱离本发明精神的情况下还可做出各种等效的变化或替换，因此，只要在本发明的实质精神范围内对上述实施例的变化、变型都将落在本申请的权利要求书的范围内。

Claims (17)

1.一种用于在服务器上执行新任务的方法，包括：

接收在所述服务器上执行新任务的请求，所述请求指定执行所述新任务的所需资源量，所述服务器目前正在执行多个执行中任务；

对于所述多个执行中任务中的每个执行中任务，查询该执行中任务的当前占用资源量以及当前可释放资源量；

基于所查询到的所述多个执行中任务中的每个执行中任务的所述当前占用资源量和/或所述当前可释放资源量，将所述所需资源量在所述多个执行中任务之间自动分配以确定每个执行中任务的重分配资源量，以使每个执行中任务的最终占用资源量均衡；以及

将每个执行中任务的重分配资源量分配给所述新任务。

2.如权利要求1所述的方法，所述方法还包括：

基于所查询到的每个执行中任务的当前可释放资源量计算所述服务器的总当前可释放资源量；

将所述所需资源量与所述总当前可释放资源量进行比较；以及

如果所述所需资源量大于所述总当前可释放资源量，则提示所述新任务的所需资源量太高。

3.如权利要求1所述的方法，将所述所需资源量在所述多个执行中任务之间自动分配包括：

初始化要从中重分配资源量的执行中任务集合；

迭代更新所述执行中任务集合以便所述执行中任务集合中的所有执行中任务的当前占用资源量均大于经重分配资源后的平均占用资源量；

基于所述平均占用资源量来计算经更新的所述执行中任务集合中的执行中任务的重分配资源量。

4.如权利要求1所述的方法，将所述所需资源量在所述多个执行中任务之间自动分配包括：

确定所述多个执行中任务的每个执行中任务的资源基准线；

如果所述多个执行中任务的资源基准线之和与所述所需资源量之和大于等于所述多个执行中任务的总当前占用资源量，则在每个执行中任务的最终占用资源量大于等于其资源基准线的情况下确定每个执行中任务的重分配资源量；

如果所述多个执行中任务的资源基准线之和与所述所需资源量之和不大于所述多个执行中任务的总当前占用资源量，则将每个执行中任务的当前占用资源量中大于其资源基准线的资源量均划入其重分配资源量，并随后按照优先级将一个或多个执行中任务的剩余占用资源量也划入其重分配资源量。

5.如权利要求1所述的方法，所述方法还包括：

确定所述多个执行中任务中的第一执行中任务的重分配资源量是否大于该第一执行中任务的当前可释放资源量；以及

如果该第一执行中任务的重分配资源量大于该第一执行中任务的当前可释放资源量，则借用一个或多个第二执行中任务的当前可释放资源量来弥补该第一执行中任务的重分配资源量减去当前可释放资源量的差额。

6.如权利要求5所述的方法，借用一个或多个第二执行中任务的当前可释放资源量来弥补该第一执行中任务的重分配资源量减去当前可释放资源量的差额包括：

计算该第一执行中任务的重分配资源量减去当前可释放资源量的差额；

确定具有剩余的当前可释放资源量的一个或多个第二执行中任务；

将所述差额分配到所述一个或多个第二执行中任务。

7.如权利要求1所述的方法，资源量包括计算资源量、存储资源量、网络资源量中的一者或多者。

8.一种用于处理资源撤回请求的方法，包括：

接收对多个资源池的资源撤回请求，所述资源撤回请求指定对所述多个资源池的总撤回资源量；

对于所述多个资源池中的每个资源池，传送对该资源池的当前持有资源量和/或当前可用资源量的查询请求；

接收所查询到的每个资源池的当前持有资源量和/或所述当前可用资源量；

基于所查询到的所述多个资源池中的每个资源池的所述当前持有资源量和/或所述当前可用资源量，将所述总撤回资源量自动分配给所述多个资源池以确定每个资源池的分配撤回资源量，以使每个资源池的最终持有资源量均衡；以及

对于所述多个资源池中的一个或多个资源池，从该资源池撤回相应的分配撤回资源量。

9.如权利要求8所述的方法，所述方法还包括：

基于所查询到的每个资源池的所述当前可用资源量计算总当前可用资源量；

将所述总撤回资源量与所述总当前可用资源量进行比较；以及

如果所述总撤回资源量大于所述总当前可用资源量，则提示无法撤回所述总撤回资源量。

10.如权利要求8所述的方法，所述方法还包括：

基于所述多个资源池中的每个资源池的当日撤回限额来计算所述多个资源池的总当日撤回限额；

将所述总撤回资源量与所述总当日撤回限额进行比较；以及

如果所述总撤回资源量大于所述总当日撤回限额，则提示无法撤回所述总撤回资源量。

11.如权利要求8所述的方法，将所述总撤回资源量自动分配给所述多个资源池以确定每个资源池的分配撤回资源量包括：

初始化要从中撤回资源的资源池集合；

迭代更新所述资源池集合以便所述资源池集合中的所有资源池的当前持有资源量均大于经撤回资源后的平均持有资源量；

基于所述平均持有资源量来计算经更新的所述资源池集合中的资源池的分配撤回资源量。

12.如权利要求8所述的方法，将所述总撤回资源量自动分配给所述多个资源池以确定每个资源池的分配撤回资源量包括：

确定所述多个资源池的每个资源池的资源基准线；

如果所述多个资源池的资源基准线之和与所述总撤回资源量之和大于等于所述多个资源池的总当前持有资源量，则在每个资源池的最终持有资源量大于等于其资源基准线的情况下确定每个资源池的分配撤回资源量；

如果所述多个资源池的资源基准线之和与所述总撤回资源量之和不大于所述多个资源池的总当前持有资源量，则将每个资源池的当前持有资源量中大于其资源基准线的资源量均划入其分配撤回资源量，并随后按照优先级将一个或多个资源池的剩余持有资源量也划入其分配撤回资源量。

13.如权利要求8所述的方法，所述方法还包括：

确定所述多个资源池中的第一资源池的分配撤回资源量是否大于该第一资源池的当日撤回限额；以及

如果该第一资源池的分配撤回资源量大于该第一资源池的当日撤回限额，则借用一个或多个第二资源池的当日撤回限额来弥补该第一资源池的分配撤回资源量减去当日撤回限额的差额。

14.如权利要求13所述的方法，借用一个或多个第二资源池的当日撤回限额来弥补该第一资源池的分配撤回资源量减去当日撤回限额的差额包括：

计算该第一资源池的分配撤回资源量减去当日撤回限额的差额；

确定具有剩余的当日撤回限额的一个或多个第二资源池；

将所述差额分配到所述一个或多个第二资源池。

15.如权利要求14所述的方法，借用一个或多个第二资源池的当日撤回限额来弥补该第一资源池的分配撤回资源量减去当日撤回限额的差额还包括：

在撤回次日或以后，从该第一资源池撤回该差额，并向所述一个或多个第二资源池补充所述差额。

16.一种存储指令的计算机可读存储介质，所述指令当被计算机执行时，使所述计算机执行如权利要求1-7中任一项所述的方法。

17.一种存储指令的计算机可读存储介质，所述指令当被计算机执行时，使所述计算机执行如权利要求8-15中任一项所述的方法。

Images