CN111240841B - Method and system for executing new tasks or processing resource withdrawal requests - Google Patents

Abstract

The application relates to a method for performing a new task, comprising: receiving a request to execute a new task on the server, the request specifying an amount of resources required to execute the new task, the server currently executing a plurality of executing tasks; for each of the plurality of executing tasks, querying a current amount of occupied resources and a current amount of releasable resources for the executing task; automatically allocating the required amount of resources among the plurality of executing tasks based on the queried amount of currently occupied resources and/or the current releasable amount of resources for each of the plurality of executing tasks to determine an amount of reallocated resources for each executing task to equalize an amount of final occupied resources for each executing task; and allocating the reallocated resource amount for each executing task to the new task. The application also relates to a method for handling resource withdrawal requests. The application can improve efficiency and user experience.

Description

Method and system for executing new tasks or processing resource withdrawal requests

Technical Field

One or more embodiments of the present specification relate to methods and systems for performing new tasks or processing resource withdrawal requests.

Background

Today, it is often necessary in real life to handle tasks or requests. And resources may need to be allocated in order to process a task or request, thus encountering a resource allocation problem. For example, in current distributed computing or cloud computing scenarios, it is often necessary to allocate new resources or reallocate original resources due to an increase or decrease in tasks and an increase or decrease in server resources.

Another case is to process resource withdrawal requests for multiple resource pools and to substantially equalize the holding resources of the final multiple resource pools. Such resource withdrawal requests may occur in a number of different scenarios. This also relates to allocation of resources. However, there is a lack of solutions in the prior art to automatically and efficiently handle resource withdrawal requests for multiple resource pools.

Thus, there is a need for methods and systems that automatically, efficiently, and experienced well in performing new tasks or processing resource withdrawal requests.

Disclosure of Invention

To overcome the deficiencies of the prior art, one or more embodiments of the present specification provide a solution that enables efficient, experienced performance of new tasks or processing of resource withdrawal requests.

One or more embodiments of the present specification achieve the above objects by the following technical means.

In one aspect, a method for performing a new task on a server is disclosed, comprising: receiving a request to execute a new task on the server, the request specifying an amount of resources required to execute the new task, the server currently executing a plurality of executing tasks; for each of the plurality of executing tasks, querying a current amount of occupied resources and a current amount of releasable resources for the executing task; automatically allocating the required amount of resources among the plurality of executing tasks based on the queried current amount of resources occupied and/or the current amount of releasable resources for each of the plurality of executing tasks to determine an amount of reallocated resources for each executing task to equalize an amount of final occupied resources for each executing task; and allocating an amount of reallocated resources for each executing task to the new task.

In another aspect, a method for processing a resource withdrawal request is disclosed, comprising: receiving a resource withdrawal request for a plurality of resource pools, the resource withdrawal request specifying a total withdrawn resource amount for the plurality of resource pools; for each of the plurality of resource pools, transmitting a query request for a currently held resource amount and/or a currently available resource amount for the resource pool; receiving the queried currently held resource quantity and/or the currently available resource quantity of each resource pool; automatically allocating the total withdrawn resource amount to the plurality of resource pools based on the queried currently held resource amount and/or the currently available resource amount of each of the plurality of resource pools to determine an allocation withdrawn resource amount for each resource pool to equalize a final held resource amount for each resource pool; and for one or more of the plurality of resource pools, withdrawing a respective allocation withdrawal resource amount from the resource pool.

In yet another aspect, a computer-readable storage medium storing instructions that, when executed by a computer, cause the computer to perform the above-described method is disclosed.

In yet another aspect, a system is disclosed that includes means for performing the above method.

One or more embodiments of the present description may have the following advantages over the prior art:

the efficiency of processing tasks or requests can be improved;

the efficiency of resource management tasks or funds can be improved; and

the user experience can be improved.

Of course, it is not necessary for any of the above technical solutions to be practiced simultaneously.

Drawings

The foregoing summary, as well as the following detailed description, is better understood when read in conjunction with the appended drawings. It is to be noted that the drawings are merely examples of the claimed application. In the drawings, like reference numbers indicate identical or similar elements.

Fig. 1 shows an example flowchart of a method for performing a new task on a server according to an embodiment of the present description.

Fig. 2 shows a schematic block diagram of a system for performing new tasks on a server according to an embodiment of the present description.

Fig. 3 shows an example flowchart of a process for determining whether the required amount of resources for a new task is too high, according to an embodiment of the present description.

FIG. 4 illustrates an example flow chart of a process of automatically allocating a required amount of resources among a plurality of executing tasks according to an embodiment of the present description.

Fig. 5 shows an example flowchart of a process for automatically allocating a required amount of resources among a plurality of executing tasks in consideration of a resource baseline, according to an embodiment of the present description.

FIG. 6 illustrates an example flow chart of a process for borrowing a difference between tasks in different executions according to an embodiment of the present description.

Figure 7 shows an example block diagram of a system for processing redemption requests in accordance with an embodiment of the present specification.

Figure 8 shows a schematic diagram of a system for implementing multi-fund accounts according to an embodiment of the present description.

Fig. 9 shows an example flowchart of a method for performing a new task on a server according to an embodiment of the present description.

Figure 10 illustrates an example flow chart of a process for determining whether the total redemption amount specified by the redemption request is too high in accordance with an embodiment of the present specification.

Figure 11 illustrates an example flow chart of a process for determining whether a total redemption amount specified by a redemption request is too high relative to a total redemption limit in accordance with an embodiment of the present specification.

Figure 12 shows an example flow chart of a process for automatically distributing a total redemption amount among multiple funds in accordance with one embodiment of the present description.

Figure 13 shows an example flow chart of a process for automatically distributing a total redemption amount among a plurality of funds in consideration of a redemption reference line in accordance with an embodiment of the present description.

FIG. 14 illustrates an example flow chart of a process for borrowing a differential between different funds according to embodiments of the present description.

Fig. 15 shows a flow chart of a method for processing a payment request according to an embodiment of the present description.

Fig. 16 shows a flow chart of a method for handling a resource withdrawal request according to an embodiment of the present description.

Detailed Description

The following detailed description is presented to enable any person skilled in the art to make and use the teachings of one or more embodiments of the present disclosure and to enable those skilled in the art to readily understand the objects and advantages associated with one or more embodiments of the present disclosure based on the disclosure, claims and drawings disclosed herein.

In real life, resource allocation problems are often encountered.

For example, in environments such as cloud computing, tasks are often performed on multiple servers. At this time, server resources need to be allocated for the tasks.

The server resources may include, for example, computing resources and/or storage resources. The computing resources are, for example, CPU resources, GPU resources, or other processing resources, etc. The storage resource is, for example, a memory resource, a flash memory, a hard disk, or the like. The server resources may also include network resources, such as bandwidth resources, and the like. The server resources may also include other resources such as I/O resources, power resources, and the like.

In the above scenario, a scenario is often encountered in which a new task needs to be added. In some cases, while adding new tasks, it may be less than or not desirable to increase the amount of server resources. At this time, existing server resources need to be allocated to new tasks.

Task request processing embodiment

Referring to FIG. 1, an example flow diagram of a method 100 for performing a new task on a server according to an embodiment of the present description is shown. This method can be understood with reference to fig. 2. Fig. 2 shows a schematic block diagram of a system 200 for performing new tasks on a server according to an embodiment of the present description.

As shown in fig. 1, the method 100 may include: at step S101, a request to perform a new task on the server (e.g., server 202 in fig. 2) may be received.

The server 202 may be various types of servers, such as a mainframe, mini-machine, etc. The server may also be a server cluster or a virtual machine cluster, such as a cloud server or the like. In general, a server may be executing multiple tasks (e.g., task 1, task 2 … … task n in fig. 2), and the task currently executing on the server may be referred to hereinafter as an executing task.

The new task and/or the executing task may be any type of task, such as collecting data, processing requests from users, and so forth.

The request may come from a requestor 202, which may be, for example, a client, from a user, from the server itself, and/or from one or more other servers, etc. The request may specify the amount of resources needed to execute the new task, the server 204 is currently executing multiple executing tasks (e.g., task 1, task 2 … … task n). As described above, the amount of resources may be an amount of computing resources (e.g., number of CPU cycles), an amount of storage resources (e.g., amount of memory, amount of hard disk, etc.), an amount of network resources (e.g., amount of bandwidth), etc. The amount of resources may also be other amounts of resources, such as I/O resources, power resources, etc.

The method 100 may further include: in step S102, for each executing task, the current amount of occupied resources and the current amount of releasable resources for the executing task may be queried.

The current occupied resource amount refers to the current resource amount allocated for the task in execution. For example, the server may allocate a respective amount of resources for each task, which may or may not be the same. For example, the server may allocate 2GB of memory for executing task A, 3GB of memory for executing task B, and 3GB of memory … … for executing task C. The currently allocated amount of resources of an executing task is hereinafter referred to as the currently occupied amount of resources of the executing task.

However, the amount of resources allocated to an executing task may not be fully utilized. For example, of the 3GB of memory allocated for task 1 in execution, only 1GB may be used, while the remaining 2GB of memory is unused; of the 2GB of memory allocated for executing task 2, only 1.8GB may be used, while the remaining 0.2GB of memory is unused; of the 3GB of memory allocated for executing task 3, only 2.5GB may be used, while the remaining 0.5GB of memory is unused … …, the remaining unused amount of resources may be freed up and allocated for use by other tasks, which may be referred to hereinafter as the current releasable amount of resources.

The method 100 may further include: in step S103, the required resource amount may be automatically allocated among the plurality of executing tasks based on the queried current occupied resource amount and/or the current releasable resource amount of each of the plurality of executing tasks to determine a reallocated resource amount for each executing task to equalize the final occupied resource amount for each executing task. That is, a portion of the currently occupied amount of resources of one or more of the plurality of executing tasks is taken as a reallocated amount of resources for allocation to a new task to enable the new task to be executed. The amount of reallocated resources may be different for each executing task. The final occupied resource amount refers to the occupied resource amount obtained by subtracting the reallocated resource amount of each executing task from the current occupied resource amount of the executing task, and is the resource amount reserved for the executing task to continue executing the executing task after the reallocated resource amount is allocated to a new task.

So-called balancing the final resource occupancy of each executing task can be measured by various objectives. In a simple example, it refers to minimizing the amount of resources ultimately consumed for each executing task to be equal or approximately equal. For example, the tasks may be substantially homogeneous tasks, such as virtual machine tasks assigned to different users. While virtual machine tasks for different users are allowed to occupy more or less resources at some point in time, it is generally pursued that these users occupy approximately the same amount of resources. In this case, the goal may be to make the final amount of resources occupied by each executing task equal or approximately equal as much as possible. Other situations are envisaged in which such an objective is also present. In the following description, this object is generally described as an example.

In another example, it refers to minimizing the ratio of the final occupied resource amount of each executing task to its current used resource amount (i.e., the difference of the current occupied resource amount at the beginning minus the current releasable resource amount) to be equal or approximately equal.

A method for automatically allocating a required amount of resources among a plurality of executing tasks to determine a reallocated amount of resources for each executing task is described in detail below with reference to fig. 4 and 5.

The method 100 may further include: in step S104, the new task may be allocated an amount of reallocated resources for each executing task. By automatically allocating the required amount of resources for the new task among the plurality of executing tasks, after determining the reallocated amount of resources for each executing task, the amount of resources to be allocated for the new task for each executing task is obtained, and the sum of these amounts of resources is equal to the required amount of resources specified in the received request for executing the task, so that the new task can be executed using the required amount of resources allocated thereto.

However, it is contemplated that the following may occur: the amount of required resources specified in the received request to execute a new task is so high that the total amount of releasable resources in the server is allocated to the new task, and still the amount of required resources for the new task cannot be met. At this point, an indication may be transmitted to the requestor that the required amount of resources for the new task is too high.

For this reason, after the above-described step S102 and before step S103, a process for determining whether the required amount of resources for the new task is too high may be performed first. Referring to FIG. 3, an example flow diagram of a process 300 for determining whether the required amount of resources for a new task is too high is shown, according to an embodiment of the present description.

The process 300 may include: in step S301, the total current releasable resource amount of the server is calculated based on the queried current releasable resource amount of each executing task. For example, the total current releasable resource amount of the server may be obtained by summing the current releasable resource amounts of each executing task. For example, assuming that the server is currently executing three executing tasks 1, 2, and 3, the total current releasable resource amount of the server is the sum of the current releasable resource amounts of task 1, task 2, and task 3, for example, 2gb+0.2gb+0.5gb=2.7 GB memory.

The process 300 may include: in step S302, the required amount of resources may be compared to the total current amount of releasable resources. For example, if the required amount of resources specified in the request to perform the new task is 3GB, comparing the two may result in a required amount of resources of 3GB greater than the total current releasable amount of resources of 2.7GB. If the required amount of resources specified in the request to perform the new task is 2GB, then comparing the two results in a required amount of resources of 2GB less than the total current releasable amount of resources of 2.7GB.

The process 300 may further include: in step S303, if the required amount of resources is greater than the total current releasable amount of resources, it may be prompted that the required amount of resources for the new task is too high. As described above, a server (e.g., server 204 of fig. 2) may transmit a prompt to a requestor (e.g., requestor 202 of fig. 2) that sends a request to perform a new task that the amount of resources needed for the new task is too high. At this point, the requestor may decide not to execute the new task. Alternatively, the requestor may decide to perform the new task. If the requestor decides to execute the new task, the server may decide, depending on the circumstances, whether to reduce the resources allocated to the executing task or directly stop execution of the executing task to free up resources for the new task.

On the other hand, if the required resource amount is equal to or less than the total current releasable resource amount, the step S103 shown in fig. 1 may be continued to be performed, and automatic allocation may be performed on the required resource amount.

Referring to FIG. 4, an example flow diagram of a process 400 for automatically allocating the required amount of resources among the plurality of executing tasks is shown, according to an embodiment of the present description. As described above, this process may be performed after querying the current amount of occupied resources and the current amount of releasable resources for each task.

Generally, the automatic dispensing process may be accomplished by the following steps: first, a set of executing tasks from which to reallocate an amount of resources may be initialized. For example, as described in detail below in step S401, the set may be initialized to all of the plurality of executing tasks.

The set of executing tasks may then be iteratively updated such that the current amount of occupied resources for all executing tasks in the set of executing tasks is greater than the average amount of occupied resources after reallocation of resources. Finally, a reallocated amount of resources for an executing task of the updated set of executing tasks may be calculated based on the average amount of occupied resources. For a specific procedure of these two steps, reference is made to the following description for steps S402-S405.

As shown in fig. 4, the process 400 may include step S401: initializing a first set of executing tasks to reallocate an amount of resources to all of the plurality of executing tasks when a first number of executing tasks in the first set is equal to a number of the plurality of executing tasks.

That is, at the time of initialization, it is assumed that a part of the resource amount is newly allocated to a new task among all the executing tasks.

For example, assume that there are currently a total of n executing tasks in the server, at which time the number of executing tasks in the first set x=n.

The process 400 may further include step S402: the first amount of resources may be determined by dividing the difference of the required amount of resources Msum by the first number x by the sum of the currently occupied amounts of resources Fi of the executing tasks within the first set, that is:

favg= (Σfi-Msum)/x (formula 1)

Wherein Fi is the current amount of occupied resources of the executing tasks within the first set, and the initial value of the first number x is equal to the number n of the plurality of executing tasks, as described above. In a subsequent process, it may be necessary to change the first set step by step as the iteration proceeds, so that the value of the first number x is updated to no longer equal n, as will be described below.

The meaning of the above formula can be appreciated as follows:

by summing the current amounts of occupied resources Fi of the executing tasks within the first set, the total current amounts of occupied resources Σfi of the executing tasks in the first set (i.e. those executing tasks for which the amounts of resources are to be reallocated) can be obtained.

Then, subtracting the required resource amount Msum from the total current occupied resource amount Σfi of the executing tasks in the first set may obtain a total remaining resource amount Σfi-Msum of the server for the plurality of executing tasks after the required resource amount Msum is allocated to the new task. As described above, the first number reflects the number of executing tasks that take out their resources to reallocate to a new task. The average remaining resource amount Favg of each executing task in the first set can be obtained by dividing the total remaining resource amount Σfi-Msum in the first set by the first number x of executing tasks in the first set.

The process 400 may further include step S403: those executing tasks within the first set that have a current amount of occupied resources Fi that is greater than or equal to the first amount of resources Favg may be determined as a second set, where the number of executing tasks in the second set is a second number y. That is, the current occupied resource amount Fi of each executing task within the first set is compared with Favg obtained by equation 1, and those executing tasks whose current occupied resource amount Fi is equal to or greater than the first resource amount Favg are selected and put into the second set. The number of executing tasks in the second set is denoted by a second number y. It will be appreciated that the second number y is less than or equal to the first number x.

The process 400 may further include step S404: if the second number y is equal to the first number x, a reallocated resource amount Ri of the executing task in the first set, where the currently occupied resource amount is greater than the first resource amount, is calculated, where the reallocated resource amount Ri is equal to the currently occupied resource amount Fi of the executing task minus the first resource amount, i.e. ri=fi-Favg. It may be appreciated that, if the current occupied resource amount Fi of the task Ti in execution is greater than or equal to the first resource amount Favg, the task Ti in execution can be reallocated with resources; and if the current occupied resource quantity Fi of the executing task Ti is smaller than the first resource quantity Favg, the resource quantity of the executing task Ti is not re-allocated to other tasks, otherwise, the resource quantity is smaller than the average value. If the second number y is equal to the first number x, it indicates that all the executing tasks in the first set can be reallocated with resources, and at this time, the amount of reallocated resources that each task needs to be reallocated, that is, the amount ri=fi-Favg that exceeds the average remaining amount of resources, can be directly calculated. The amount Ri will be reassigned to the new task. After the amount of reallocated resources is calculated, the allocation process ends.

The process 400 may further include step S405: if the second number y is smaller than the first number x, the first set may be updated to the second set and the first number x may be updated to the second number y, and the above steps S402 to S405 may be repeated. It will be appreciated that if the second number is less than the first number, indicating that the current amount of occupied resources for some of the executing tasks in the first set is less than the average amount of remaining resources, then the resources for those executing tasks should not be reallocated. At this time, the average remaining resource amount Favg can only be recalculated in the second number of executing tasks in the second set. Therefore, the first set for calculating the average remaining resource amount Favg should be updated to the second set (accordingly, the first number should be updated to the second number, i.e., let x=y), and steps S402 to S405 are repeatedly performed until the condition in S404 is satisfied.

In some cases, not all of the currently occupied resource amounts of the executing task may be reallocated. For example, an executing task may have minimal resource requirements. Less than the amount of resources, the executing task will be completely inoperable. In the embodiments of the present specification, this minimum resource amount requirement is referred to as a resource baseline. In the presence of a resource reference line, it may be desirable to stop execution of one or more currently executing tasks to ensure execution of the new task.

In general, the following steps may be employed to implement the reassignment process with consideration of the resource reference line. First, a resource reference line for each of the plurality of executing tasks may be determined. Then, if the sum of the resource reference lines of the plurality of executing tasks and the required resource amount is equal to or greater than the total current occupied resource amount of the plurality of executing tasks, determining a reallocated resource amount of each executing task if the final occupied resource amount of each executing task is equal to or greater than the resource reference line thereof, and if the sum of the resource reference lines of the plurality of executing tasks and the required resource amount is not greater than the total current occupied resource amount of the plurality of executing tasks, then allocating resource amounts greater than the resource reference line thereof in the current occupied resource amount of each executing task to the reallocated resource amount thereof, and then allocating the remaining occupied resource amount of one or more executing tasks to the reallocated resource amount thereof according to the priority. Reference is made to the following detailed description for specific procedures.

Referring to fig. 5, an example flow chart of a process 500 for automatically allocating the required amount of resources among the plurality of executing tasks in consideration of a resource baseline is shown in accordance with an embodiment of the present description.

As shown in fig. 5, the process 500 may include step S501: the total current occupied resource amount Fsum of the server may be calculated based on the queried current occupied resource amount Fi of each executing task. That is, the sum Fsum of the currently occupied resource amounts Fi of all currently executing tasks may be calculated. That is, fsum= Σfi, where the sum ranges from the current amount of occupied resources Fi for all of the plurality of currently executing tasks in the server.

The process 500 may further include step S502: a resource reference Bi for each executing task may be determined. For example, the server may maintain a record of the resource reference line for each executing task. At this time, the server may determine a resource reference Bi for each executing task from the record. Alternatively, heuristics may also be employed to determine a resource baseline Bi for each executing task.

The process 500 may further include step S503: it may be determined whether the sum Bsum of the resource reference lines Bi of the plurality of executing tasks and the sum of the required resource amounts Msum are greater than the total current occupied resource amount Fsum, that is, it may be determined whether Σbi+msum is greater than Σfi. If so, it may be deemed necessary to stop one or more executing tasks to achieve the desired amount of resources so that the new task can be executed; otherwise, the required amount of resources can be achieved without stopping any executing tasks.

Therefore, if it is determined in step S503 that the sum Bsum of the resource reference lines Bi of the plurality of executing tasks and the sum of the required resource amount Msum are greater than the total currently occupied resource amount Fsum, the reallocation resource amount may be determined in the following manner:

step S504: and for the executing task with the current occupied resource quantity Fi larger than the resource reference line Bi, distributing the sum Fi-Bi of the current occupied resource quantity Fi exceeding the resource reference line Bi to the new task. That is, all the resource amounts (if any) in each task that are more than the resource reference line are first allocated to the new task; and

step S505: and allocating the occupied resource amounts of the plurality of executing tasks to the new task one by one according to the priorities of the plurality of executing tasks until the required resource amount is reached, so that the reallocated resource amount of each executing task is the sum of the amount redeemed in step S504 and the resource amount allocated to the new task in step S505. That is, in the case where all the resource amounts more than the resource reference line are allocated to the new task, the required resource amount of the new task cannot be reached, at this time, one or more executing tasks are stopped according to the priority, and the occupied resource amount of the stopped executing task is allocated to the new task until the required resource amount of the new task is reached. For example, the lower priority executing task will be stopped and its total amount of occupied resources (the current amount of occupied resources for each executing task is equal to its resource reference line, via step S505 above) will be allocated to the new task.

On the other hand, if it is determined in step S503 that the sum Bsum of the resource reference lines Bi of the plurality of executing tasks and the sum of the required resource amount Msum are not greater than the total currently occupied resource amount Fsum, the reallocation resource amount is determined in the following manner:

step S506: initializing a first set of executing tasks to be reallocated in an amount of resources to all of the plurality of executing tasks, wherein a first number x of executing tasks in the first set is equal to a number n of the plurality of executing tasks;

step S507: determining a first resource amount Favg, i.e. favg= (Σ (Fi-Bi) -Msum)/x by dividing the difference of the required resource amount Msum by the first amount x by the sum of the differences of the currently occupied resource amount Fi of the executing task within the first set and its resource reference line Bi;

step S508: determining the currently occupied resource quantity Fi minus the resource reference line Bi which is larger than the first resource quantity Favg in the first set as a second set, wherein the number of the executing tasks in the second set is a second number y, and

step S509: if the second number y is equal to the first number x, calculating a reallocated resource amount Ri of the executing task in which the current occupied resource amount in the first set minus a resource reference line Bi is greater than the first resource amount, wherein the reallocated resource amount Ri is equal to the current occupied resource amount Fi of the executing task minus the resource reference line Bi, and subtracting the first resource amount, i.e., ri=fi-Bi-Favg, and

Step S510: if the second number y is smaller than the first number x, the first set is updated to the second set and the first number x is updated to the second number y, and the above steps S507 to S510 are repeated.

It can be seen that the above steps are substantially identical to those of process 400, except that the resource reference line is first subtracted in calculating the amount of remaining resources. For details of the above steps reference is made to the description of process 400.

It can be seen that the above procedure does not substantially consider the releasable resource amount versus the reallocated resource amount. Because, in some examples, the amount of resources of the executing task is somewhat flexible. For example, in the example of multiple virtual machine tasks for multiple users, while the current amount of releasable resources (amount of free resources) of a virtual machine task is less than the amount of reallocated resources, the task actually occupies more of the currently occupied amount of resources than other tasks, and the virtual machine task may be adapted to run at a lower amount of occupied resources (i.e., more amount of resources may be made available). At this point, the virtual machine task may still be running, although the execution efficiency may be reduced. Thus, it may be appropriate in some cases to perform the reallocation without taking into account the amount of releasable resources, which is suitable to employ the procedure as described above. In some scenarios, it may be desirable to ensure that the amount of reallocated resources is less than or equal to the amount of releasable resources, at which point additional processes according to embodiments of the present description may be employed, as follows.

Referring to FIG. 6, an example flow diagram of a process 600 for borrowing a gap between tasks in different executions is shown, according to an embodiment of the present disclosure.

As shown in fig. 6, process 600 may include: in step S601: it may be determined whether an amount of reallocated resources of a first executing task of the plurality of executing tasks is greater than a current amount of releasable resources of the first executing task.

The process 600 may further include: in step S602: if the amount of reallocated resources of the first executing task is greater than the amount of current releasable resources of the first executing task, borrowing the amount of current releasable resources of one or more second executing tasks to compensate for the difference of the amount of reallocated resources of the first executing task minus the amount of current releasable resources.

Specifically, borrowing the current releasable resource amount of the one or more second executing tasks to compensate for the difference of the reallocated resource amount of the first executing task minus the current releasable resource amount includes:

in step S603, a difference of the reallocation resource amount of the first executing task minus the current releasable resource amount may be calculated.

In step S604, one or more second executing tasks having a remaining current amount of releasable resources may be determined.

In step S605, the deficit may be assigned to the one or more second executing tasks.

After performing the differential borrowing, differential returns may be performed at a later time, as desired. That is, since the deficit that would otherwise be reassigned from the first executing task to the new task is reassigned from the one or more second executing tasks (i.e., the deficit is assigned to the new task from the amount of resources of the one or more second executing tasks), at some later time, the first executing task may similarly reassign the deficit to the one or more second executing tasks such that the final amount of resources occupied by the last executing task corresponds to the final amount of resources occupied by the process 400 or the process 500 above.

Fund request processing embodiment

In other scenarios, such as online transactions or online redemption of funds, etc., resource allocation issues or resource withdrawal issues may also be involved. Here, the resource may refer to a funding resource, or a monetary resource, or the like.

Today, many third party platforms (e.g., various online paymate platforms, third party platforms with payment capabilities, online banking, etc.) are beginning to provide foundation interface services. These third party platforms do not themselves operate the funds, but rather cooperate with the funds provider (e.g., the funds provider). The user of the third party platform may perform the steps of buying, querying, redeeming, etc. the funds through the fund interface provided by the platform.

Generally, funds may include open funds, closed funds, and the like. Open-end Funds (Open-end Funds), also known as mutual Funds, refers to a type of operation of Funds in which the total size of the units or shares of Funds is not fixed when a sponsor of the Funds sets up the Funds, the units or shares of Funds can be sold to investors at any time according to the needs of the investors, and the units or shares of Funds released outside can be redeemed according to the needs of the investors. In contrast, closed Funds (Closed-end Funds) refer to Funds in which the total amount of issue and the period of issue of the Funds are determined at the time of set-up, and the total amount of issue is fixed within a prescribed period after the end of issue.

Currently, in most third party platforms, an open fund is provided. A big feature of open funds is that the user can redeem at any time, although redemption has certain restrictions, as will be further described below.

Funds come in a variety of investment types. In third party platforms, monetary funds are currently commonly provided. Monetary funds only invest in monetary markets such as short term national debts, buyback, central notes, bank deposits, etc., which are less risky than other types of funds.

Most third party platforms provide interfaces for multiple funds. However, currently in third party platforms, a user typically holds only one fund at any time. For example, in an online paymate, if a user chooses to purchase and hold fund a, then fund B cannot be purchased any more. This may be the case for the following reasons: firstly, in order to reduce the complexity of the system, multiple funds are held at the same time to bring about the increase of the complexity of the system; second, to maintain a good user experience, the user may not be able to collect and pay with the fund account or may be required to manually make a selection while the user holds multiple funds. In the case where the user holds only one fund, when the user wishes to redeem and/or pay, the user simply deducts the corresponding share from the fund held by the user and transfers it to the user account.

In embodiments of the present description, it is achieved that a user is allowed to hold multiple funds simultaneously. Moreover, embodiments of the present description allow a user to achieve simple redemption and even collection and payment without knowing the details of the fund layer.

System frame diagram

Referring to fig. 7, an example block diagram of a system 700 for processing redemption requests in accordance with an embodiment of the present specification is shown. As shown in fig. 7, the system 700 may include four modules, a front end 702, a product layer 704, a core layer 706, and an access layer 708.

Front end 702 refers to a module for user interaction. Front end 702 may be, for example, various online paymate platforms (including mobile paymate platforms), online banking, and the like. The front end 702 receives user instructions (e.g., instructions for the opening, consultation, purchase, viewing, redemption, payment, repayment, etc. of the fund) and sends the instructions to a subsequent module (e.g., the product layer 704) for processing. Front end 702 also includes receiving the processing results from a subsequent module (e.g., product layer 704) and presenting the processing results to the user.

The product layer 704 receives instructions from the front end 702 and processes the instructions. Specifically, as shown in FIG. 7, the product layer 704 may include a financial platform, a paymate, a transaction decision platform, and the like.

As its name implies, the financial platform is used to process instructions related to financial, such as receive and process fund opening, buying, viewing, redeeming, etc. instructions from the front end 702. After processing the instruction associated with financial accounting, the financial accounting platform may send the instruction to the transaction decision platform to perform a specific transaction decision.

The paymate is operable to process instructions related to payment, such as receiving and processing payment instructions, cash-out instructions, etc., from the front end 702. As will be described below, the paymate may be connected to a transaction decision platform.

The transaction decision platform receives the purchase requisition instruction from the financial platform and decides how to distribute the purchase requisition amount among the funds to purchase the corresponding funds. In addition, the transaction decision platform may also receive redemption instructions from the financial platform and decide how to distribute redemption amounts among the funds for redemption in the respective funds. Details of how the transaction decision platform decides to distribute the applied/redeemed amount between funds will be described in detail later.

In the present description, the paymate may preferably be connected to and in communication with a transaction decision-making platform. In this case, the transaction decision platform may also receive payment instructions from the payoff platform, convert them into redemption instructions, and decide how to distribute the redemption amount among the funds. Similarly, the transaction decision platform may also receive a cash instruction from the paymate, convert it into a buy instruction, and decide how to distribute the buy amount among the funds.

The user, upon payment, may instead of paying from the user's cash account, redeem from each fund account and use the redeemed funds to perform the payment step; similarly, the user may store the cash account directly at the time of collection, rather than depositing it into the cash account. In this way, the user may be allowed to enjoy the fund benefits of funds while enjoying cash-like payment convenience.

In the case of the multi-fund platform of the embodiments of the present description, it is particularly advantageous to connect the paymate platform with the transaction platform. With the embodiments of the present description, even in the case where the user holds multiple funds (thereby enjoying lower risk and higher line of purchase and redemption limits), the user need not consider matters associated with the base metallographic phase, but need only input payment amounts to effect the payment step. Similarly, the user may also implement the checkout step.

It will be appreciated from the above description that the embodiments of the present disclosure relate purely to financial aspects, but rather require redesign of the architecture and connectivity, data flow, and process flows of the automation system, thereby enhancing the user experience.

The product layer 704 then sends corresponding instructions to the core layer 706 to perform the only claims/redemption, and payment/receipt/repayment steps.

The core layer 706 receives instructions from the product layer 704 and performs the corresponding steps. For example, the asset exchange module specifically performs a corresponding asset exchange. The accounting center performs steps related to accounting. The financial core performs steps related to the opening, the reimbursement, the viewing, the redemption, etc. of the funds. The clearing house performs steps related to asset clearing. The product contract module performs processing on the corresponding product contract. The price center performs steps related to synchronizing and viewing of the fund quotations (e.g., fund prices, etc.). In the case where there is a debit/credit-related step, the debit accounting module performs the debit/credit-related step.

The core layer 706 then passes its processing results to the access layer 708. The access layer 708 is responsible for interfacing with the data interfaces of the various fund providers to perform related data reception and transmission, and the like. For example, a data interface may be included in the access layer 708 that interfaces with a corresponding data interface in each of the fund providers (e.g., the example fund provider in fig. 7) via a financial network. The access layer 708 may also include a file factory. The file factory may generate various related files to enable standardized processing and recording of various financial operations.

The operation of each platform or module will not be described in detail herein. After reading the above description, one of ordinary skill in the art will know how to implement the functionality of each platform, center, or module. Furthermore, the present description embodiments may be implemented using any other system than the system 700 above.

Account structure and account opening

Referring to FIG. 8, a schematic diagram of a system for implementing multi-fund accounts according to an embodiment of the present description is shown.

As shown in fig. 8, a user may communicate a redemption request to a third party platform 804 through a user client 802. For example, client 802 may take the form of an application (e.g., an online paymate client, an online banking client, etc.) installed on a user's device (e.g., a smart phone, tablet, desktop, laptop, etc.). Alternatively, the client 802 may take the form of a browser or the like without installing a particular application. For example, a user may use a browser to access a web page to interact directly with a server.

As shown in fig. 8, each user may have a general account in third party platform 804 and may have multiple sub-accounts under the general account, each of which may correspond to a fund. In the corresponding fund provider, the user should also have a fund account to hold the fund according to the corresponding specifications. Each sub-account of the user's total account in the third party platform may be docked with its account in the corresponding fund, thereby enabling the transfer and receipt of fund data, as well as other related operations. Thus, the user may need to agree to the terms of the opening of each fund he or she wants to hold at the time of opening the account in order to open the corresponding fund account at the corresponding fund provider.

The third party platform 804 may employ aspects of embodiments of the present description to process redemption requests from the user clients 802, as described in detail below.

From the foregoing, it can be seen that embodiments of the present specification devise separate data structures and data interfaces to facilitate the above-described methods. For example, the data structure may include the name of the funds held by the user, the total share remaining for each of the funds, the available share for each of the funds, the quota for each of the funds, the remaining quota for each of the funds, and the like. Further, the respective items of the respective funds may be correlated, e.g., a total quota may be readily determined by the quota of each fund, a total remaining share, a total available share, a total remaining quota, etc., may be readily determined by the remaining share of each fund.

In addition, the data structure may also correlate step histories for each fund. For example, in a step on a certain day, a step of each fund corresponding to the step can be easily found. For example, at the redemption step of inquiry 2019, 12, 01, the redeemed shares of each fund, as well as the remaining shares, may be inquired when the step is performed. By such a data structure, a plurality of funds can be easily managed in association with each other.

The data interface allows data to be transferred between the third party platform and the respective fund providers to enable corresponding queries and requests to enable the operations of the above-described method to be performed.

Fund purchase

At the time of purchase, the user may choose to purchase a particular fund alone and specify the amount to purchase. At this time, the purchase amount inputted by the user will be credited from its total account to the corresponding sub-account, and then a purchase request is sent and the purchase amount is credited to the corresponding fund account, thereby converting to the fund share in the fund account.

Alternatively, the user may simply input the amount desired to be applied. In this case, the amount may be distributed among the funds, such as by equally distributing shares. The corresponding amount may then be credited to the corresponding sub-account, and a request for purchase may then be sent and the assigned amount credited to the corresponding fund account, thereby converting to a fund share in the corresponding fund account.

In an example of a paymate being opened to a fund platform, a user may use the received funds directly to purchase the fund after collection. At this time, the amount of the received money is used as the amount of the purchase, and then the fund purchase step is performed as described above.

Fund(s)Redemption of

At redemption, the user may choose to redeem the particular funds individually and specify the redemption amount. At this point, the system will send a redemption request to the user's selected funds, including the redemption amount. The funds, upon receipt of the redemption request, will convert the share of the funds in the fund account into funds and deposit the funds into the corresponding sub-account of the third party platform and credit the general account.

Alternatively, the user may only input the total amount that is desired to be redeemed. In this case, embodiments of the present description may be employed to determine how to allocate the total amount among funds. The system will then send a redemption request to each of the funds, the redemption request including the redemption amount allocated to the corresponding funds. The funds, upon receipt of the redemption request, will convert the share of the funds in the fund account into funds and deposit the funds into the corresponding sub-account of the third party platform and credit the general account.

In an example of a payoff deck being opened to a fund deck, upon receipt of a payment request, a user may redeem funds using the fund redemption step described above with the amount in the payment request as a redemption amount and pay another user.

Multi-fund redemption request processing embodiment

Referring to fig. 9, an example flow diagram of a method 900 for performing new tasks on a server according to an embodiment of the present description is shown.

As shown in fig. 9, method 900 may include: at step S901, a redemption request for a plurality of funds from a user may be received. The redemption request may specify a total redemption amount for the plurality of funds.

For example, the user may enter the total redemption amount using the user client 802 as shown in FIG. 8 and click the redemption button. At this point, the user client 802 may transmit a corresponding redemption request to the third party platform 804.

Preferably, the user may not separately input information such as the redemption amount or the redemption rate for each fund, but simply redeem the total redemption amount that he wants to redeem. This greatly simplifies the operations and calculations that the user needs to perform, enhancing the user experience.

The method 900 may further include: for each of the plurality of funds, a query request for a currently held amount and/or a currently redeemable amount of the funds currently held by the user may be transmitted to a funds data interface provided by a funds provider of the funds, at step S902. For example, the currently held amount and the currently redeemed amount of the funds currently held by the user may be queried to the funds provider through a funds data interface provided by the funds provider, such as via interface layer 708 shown in FIG. 7. For example, the query request may include a user identification (e.g., user ID) of the user's fund account at the fund provider, a platform identification (e.g., an identifier of the platform, such as a platform name, code number, etc.) of the third party platform, and data to query (e.g., a current holding amount and/or a current redeemable amount). The query request may also include a query for other information, such as the amount the user has redeemed in the fund on the current day, the amount the user has frozen in the fund, and other information.

The method 900 may further include: the queried currently held amount and/or the currently redeemable amount may be received from the fund provider of each of the plurality of funds at step S903. The fund provider of the fund, upon receiving the query from the third party platform, may transmit the queried information, such as the current holding amount and/or the current redeemable amount of the user in the fund, etc., to the third party platform via its fund data interface. In the event that other information (e.g., redeemed amount, frozen amount, or other information) is queried, the funds provider may likewise transmit the other information to the third-party platform via its funds data interface. The third party platform may receive information transmitted from the fund provider, for example, via interface layer 708 shown in fig. 7.

The method 900 may further include: at step S904, the total redemption amount may be automatically assigned to the plurality of funds based on the currently held amount and/or the currently redeemable amount of each of the plurality of funds queried to determine an assigned redemption amount for each of the funds to balance the final hold amount for each of the funds by the user. That is, a portion of the currently held amount of one or more of the plurality of funds is redeemed as the allocated redemption amount such that the total amount redeemed from the one or more funds is equal to the total redemption amount in the redemption request received from the user. The redemption amount may be different for each fund and not every fund may be to be redeemed. The final hold amount refers to the amount the user holds in the fund after the redemption is completed, which is the amount the user eventually holds in the fund after subtracting the redemption amount for the fund from the user's current hold amount in the fund.

So-called balancing the final holding amount of each fund, can be measured by various objectives. In a simple example, it refers to making the final holding amount of each fund equal or approximately equal as much as possible. There is an additional benefit to making the final holding amount for each fund approximately equal. According to the decentralized investment theory, in the case that the risk degree of each fund is approximately similar, the final holding amount of each fund by the user is approximately equal, and the risk of the user can be minimized under the condition that the expected benefit of the user is unchanged. In addition, the final holding amount of each fund is approximately equal for the user, and the user can clearly and conveniently grasp the fund distribution condition. Moreover, under the condition that the holding amount of each fund is approximately equal for each user, the dishes of each fund are more easily and approximately the same, so that the management of a third party platform to a fund company is facilitated. In the following examples, this is mainly described as an example.

So that the final holding amount for each fund is balanced and may have other forms as well. For example, the risk level for each fund may be calculated and, with the risk adjusted, the expected risk for the user in each fund is made approximately equal.

A method for automatically distributing the total redemption amount to the plurality of funds to determine the distributed redemption amount for each of the funds is described in detail below with reference to figures 12 and 13.

The method 900 may further include: at step S905, a redemption request may be communicated to a fund data interface provided by a fund provider of one or more of the plurality of funds, the redemption request including the distributed redemption amount for the fund. As mentioned above and as will be described in detail below, in many cases, a number of funds are allocated to an allocated redemption amount of 0. That is, the redemption request may be transmitted only to the fund provider that distributes the funds with the redemption amount other than 0, and the redemption request may not be transmitted to the fund provider that distributes the funds with the redemption amount of 0. Upon receipt of the redemption request, the funds provider will perform redemption, settlement, clearing, etc., and communicate the redemption result to the third party platform. If redemption is successful, the redeemed funds will be transferred from the user's fund account at the fund to the user's sub-account at the third-party platform corresponding to the fund and eventually be collected into the user's total account at the third-party platform. At this point, the redemption operation is completed and the share of the funds held by the user is converted to funds for deposit in the user's sub-or total account on the third party platform.

However, it is contemplated that the following may occur: the total redemption amount specified in the redemption request from the user is too high to be reached even if the redeemable amount in the total funds are fully redeemed. At this point, an indication may be transmitted to the requestor that the total redemption amount for the new mission is too high. Specifically, in this case, a "under-limit-! "prompt.

For this purpose, after the above-described step S903 and before step S904, a process for determining whether the total redemption amount specified in the redemption request is too high may be performed. Referring to FIG. 10, an example flow chart of a process 1000 for determining whether a total redemption amount specified by a redemption request is too high is shown in accordance with an embodiment of the present specification.

Process 1000 may include: at step S1001, a total current redeemable amount of the user may be calculated based on the current redeemable amount of each fund queried. For example, the total current redeemable amount of the server may be obtained by summing the current redeemable amounts of each fund.

Process 1000 may include: at step S1002, the total redeemable amount may be compared to the total current redeemable amount.

Process 1000 may also include: if the total redemption amount is greater than the total current redeemable amount, the redemption request may be prompted to specify that the total redemption amount is too high, step S1003. As described above, the third party platform may transmit a "under-credit-! "prompt. After receiving this prompt, the user can adjust his total redemption amount based on the total current redeemable amount.

On the other hand, if the total redemption amount is less than or equal to the total current redeemable amount, the process may continue to step S904, as shown in FIG. 9, where automatic dispensing of the total redemption amount is performed.

There may be some additional restrictions on the fund. For example, under the regulation of a regulatory authority (e.g., a license agency), it is possible that one or more funds will be redeemable at most a certain limit (e.g., 5000 yuan) per day, which may be referred to as a redemption limit on the day. In the presence of a redemption limit, it may also be necessary to ensure that the total redemption amount specified in the user's redemption request does not exceed the sum of the redemption limits for all funds that would otherwise not be possible.

To this end, after the above-described step S903 and before step S904, another process for determining whether the total redemption amount specified in the redemption request is too high relative to the total redemption limit may be performed. Referring to FIG. 11, an example flow diagram of a process 1100 for determining whether a total redemption amount specified by a redemption request is too high relative to a total redemption limit is shown in accordance with an embodiment of the present specification.

Process 1100 may include: at step S1101, a total daily redemption limit for the plurality of funds may be calculated based on the redemption limits for each of the plurality of funds. For example, the total daily redemption limit for the server may be obtained by summing the current redeemable amounts for each fund. For example, assuming a redemption limit of 5000 yuan per fund, the total daily redemption limit of 10 funds would be 5000 x 10 = 50000 yuan. In addition, assuming the user has performed redemption on one or more funds on the same day, the daily redemption limit should be a regulatory agency-specified daily limit minus the amount that has been redeemed on the same day, and then the total daily redemption limit for the plurality of funds is calculated.

Process 1100 may include: at step S1102, the total redemption amount can be compared to the total current day redemption limit.

Process 1100 may also include: at step S1103, if the total redemption amount is greater than the total current day redemption limit, the user is prompted to fail to redeem the total redemption amount. The hints at this time can be the same as or different from those described above for process 1000. For example, the third party platform may transmit a "redemption overrun-! "prompt. After receiving this prompt, the user can adjust his total redemption amount based on the total current day redemption limit.

On the other hand, if the total redemption amount is less than or equal to the total current day redemption limit, the process may continue to step S904, as shown in FIG. 9, where automatic dispensing of the total redemption amount is performed.

Referring to FIG. 12, an example flow chart of a process 1200 for automatically distributing the total redemption amount among the multiple funds in accordance with one embodiment of the description is shown. As described above, this process may be performed after receiving the currently held and currently redeemable amounts for each fund.

As shown in fig. 12, the process 1200 may include step S1201: the first set of funds to be redeemed is initialized to all of the plurality of funds, at which point the first number of funds in the first set is equal to the number of the plurality of funds.

In order for the user to have approximately the same final holding amount at each fund, funds may not necessarily be redeemed from all funds. For example, some funds currently held in a lesser amount may not be redeemed for any funds. Because funds may not be redeemed from all funds, a first set is defined that includes funds from which funds are to be redeemed. At initialization, the first set is set to all of the plurality of funds. That is, at initialization, it is assumed that a portion of funds are redeemed in all funds as an initial condition for subsequent processing.

For example, suppose that the user holds n funds in total, at which point the number of funds in the first set x=n.

The process 1200 may further include step S1202: the first amount Favg may be determined by dividing the difference of the total redemption amount Msum subtracted from the sum of the currently held amounts Fi of funds within the first set by the first amount x, that is:

favg= (Σfi-Msum)/x (formula 1)

Wherein Fi is the currently held amount of funds in the first set and the initial value of the first quantity x is equal to the quantity n of the plurality of funds, as described above. In a subsequent process, it may be necessary to change the first set step by step as the iteration proceeds, so that the value of the first number x is updated to no longer equal n, as will be described below.

The meaning of the above formula can be appreciated as follows:

by summing the currently held amounts Fi of funds within the first set, the total currently held amounts Σfi of the funds in the first set (i.e., those funds to be redeemed for some funds) can be obtained.

Then, subtracting the total redemption amount Msum from the total currently held amount ΣFi of funds in the first set, the total remaining held amount ΣFi-Msum of the plurality of funds held by the user after the total redemption amount Msum is redeemed. As described above, the first quantity x reflects the quantity of funds to be redeemed for some funds. The average remaining holding amount Favg for each fund in the first set is obtained by dividing the total remaining holding amount Σfi-Msum in the first set by the first number x of funds in the first set. That is, favg= (Σfi-Msum)/x.

The process 1200 may further include step S1203: a fund in the first set having a current holding amount Fi that is greater than or equal to the first amount Favg may be determined as a second set, wherein the number of funds in the second set is a second number y. That is, the currently held amount Fi of each of the funds in the first set is compared with the average remaining held amount Favg obtained by equation 1, and those funds having the currently held amount Fi equal to or greater than the first amount Favg are selected and put into the second set. The number of funds in the second set is represented by a second number y. It will be appreciated that the second number y is less than or equal to the first number x.

The process 1200 may further include step S1204: if the second number y is equal to the first number x, an allocated redemption amount Ri of funds within the first set that are currently held in an amount greater than the first amount can be calculated, wherein the allocated redemption amount Ri is equal to the currently held amount Fi of the funds minus the first amount, i.e., ri = Fi-Favg. It will be appreciated that if a currently held amount Fi of a fund Ti is equal to or greater than the first amount Favg, the fund Ti can be redeemed for some funds; and if the currently held amount Fi of the fund Ti is less than the first amount Favg, the fund Ti should not be redeemed for any funds, otherwise its remaining held amount will be less than the average. If the second quantity y is equal to the first quantity x, then it is stated that the funds in the first set can each be redeemed for some funds, at which point the allocated redemption amount that each funds needs to be redeemed, i.e., its amount ri=fi-Favg that exceeds the average remaining holding amount, can be directly calculated. The distributed redemption amount Ri will be redeemed from the fund Ti. After the redemption amount has been calculated, the dispensing process ends.

In some cases, the calculated distributed redemption amount Ri may be subject to tail-end due to the fund provider's specification of the base unit of the user's redemption amount or other reasons. Assuming that the calculated redemption amount Ri for a particular fund is (2000/3) units, i.e., 1333.333 … units (e.g., assuming that the currently held amount of the fund is 5000 units and the first amount Favg is 26000/6 units, the redemption amount for the fund is 5000-26000/6=2000/3= 1333.333 … units). In one example, some fund providers specify that only amounts in units of elements can be redeemed. For example, only the 1333 yuan is allowed to be redeemed, for example, and the 1333.3 yuan is not allowed to be redeemed. At this time, when calculating the distributed redemption amount, the tail slip is typically discarded, i.e., the distributed redemption amount Ri for the fund is determined to be 1333 yuan. Typically there is also a tail drop for other funds. At this point, the amount of each fund dispensed redemption is actually added, and the ratio to the total redemption amount may be somewhat less. For example, the sum of the tail differences (total tail difference) of all funds may be 1 yuan, for example. The allocated redemption amount for each fund may add up to 1 yuan less than the total redemption amount. In this case, the total tail differential may be allocated to any funds for which a holding amount still exists. Alternatively, the total tail differential may be allocated to any funds for which a redeemable amount still exists.

In another example, redemption of an amount in minutes (i.e., 0.01 yuan) is typically supported, even if not specified above. For example, funds are typically only allowed to redeem, for example 1333.33 yuan, and not 1333.333 yuan. At this time, the difference after 1333 (or 1333.33) element is the tail difference. The total tail difference may be 1 minute or a few minutes at this time. Likewise, the total tail margin may also be assigned to any funds where there is still a hold or redeemable amount.

The process 1200 may further include step S1205: if the second number y is smaller than the first number x, the first set may be updated to the second set and the first number x may be updated to the second number y, and the above steps S1202 to S1205 may be repeated. It will be appreciated that if the second quantity is less than the first quantity, indicating that the current holding amount of some funds in the first set is less than the average remaining holding amount, then those funds should not be redeemed. At this time, the average remaining holding amount Favg can only be recalculated in the second number of funds in the second set. Therefore, the first set for calculating the average remaining holding amount Favg should be updated to the second set (accordingly, the first number should be updated to the second number, i.e., let x=y), and steps S1202 to S1205 are repeatedly performed until the condition in S1204 is satisfied.

For funds, there is typically a redemption reference line. The redemption reference line refers to the minimum holding amount of a fund. The fund provider may not be permitted to hold funds less than the redemption reference line. The redemption reference line may be from the fund's regulation for ease of administration or from the regulatory agency's regulation. For example, some funds provide for redemption reference lines of 1000 yuan. When the amount of funds held by the user is less than 1000 yuan, the user should redeem the full amount at redemption. In some cases, it may be desirable to retain the funds without being fully redeemed, i.e., to try to ensure that the final holding amount is greater than the redemption reference.

Referring to FIG. 13, an example flow chart of a process 1300 for automatically distributing the total redemption amount among the multiple funds considering redemption reference lines in accordance with an embodiment of the description is shown.

As shown in fig. 13, the process 1300 may include step S1301: the total current holding amount Fsum of the user may be calculated based on the current holding amount Fi of each fund queried. That is, the sum Fsum of the currently held amounts Fi of all funds held by the user may be calculated. That is, fsum= Σfi.

The process 1300 may further include step S1302: a redemption reference Bi for each fund can be determined. In many cases, the redemption reference line for each fund may be the same, for example, 1000 yuan. In other cases, the redemption reference for one or more funds may be different. At this point, the third party platform may record redemption reference lines for each fund. Alternatively, the third party platform may use the interface provided by the fund provider to query its redemption reference.

The process 1300 may further include step S1303: it may be determined whether the sum Bsum of redemption reference lines Bi for the multiple funds and the sum of the total redemption amount Msum are greater than the total currently held amount Fsum, that is, whether Σbi+msum is greater than Σfi. If so, it may be deemed necessary to fully redeem one or more funds in order to reach the total redemption amount; otherwise the total redemption amount is reached without completely redeeming any funds.

Thus, if it is determined in step S1303 that the sum Bsum of redemption reference lines Bi for the multiple funds and the total redemption amount Msum is greater than the total currently-held amount Fsum, the distributed redemption amount may be determined in the following manner:

step S1304: for funds having a current holding amount Fi greater than the redemption reference line Bi, the current holding amount Fi may be redeemed beyond the redemption reference line Bi by an amount Fi-Bi. That is, all funds (if any) of the funds that are more than the redemption reference line are redeemed first; and

Step S1305: the remaining funds of the plurality of funds are redeemed one by one according to the priority of the plurality of funds until the total redemption amount is reached, such that the final allocated redemption amount for each of the funds is the sum of the amount redeemed in step S1304 and the amount redeemed in S1305. That is, in the event that more than the total amount of resources of the redemption reference line are allocated to the new mission, the total redemption amount for the new mission is not yet reached, at which time the remaining funds of the one or more funds are redeemed according to priority until the total redemption amount for the new mission is reached. For example, the remaining amount in the lower priority funds (through step S1305 above, the current remaining amount for each funds is equal to its redemption reference line) will be redeemed.

On the other hand, if it is determined in step S1303 that the sum Bsum of redemption reference lines Bi of the plurality of funds and the sum of the total redemption amount Msum is not greater than the total currently-held amount Fsum, the distributed redemption amount is determined in the following manner:

step S1306: initializing a first set of funds to be redeemed to all of the plurality of funds, wherein a first number x of funds in the first set is equal to a number n of the plurality of funds;

Step S1307: a first amount Favg, favg= (Σ (Fi-Bi) -Msum)/x, may be determined by dividing the difference of the total redemption amount Msum by the first amount x by the sum of the differences of the currently held amounts Fi of funds within the first set and their redemption reference lines Bi;

step S1308: a fund of the first set, which is currently held in the first set and whose redemption reference Bi is greater than the first amount Favg, can be determined as a second set, wherein the number of funds in the second set is a second number y, and

step S1309: if the second quantity y is equal to the first quantity x, an allocated redemption amount Ri for funds within the first collection having a current hold amount minus a redemption reference Bi greater than the first amount can be calculated, wherein the allocated redemption amount Ri is equal to the current hold amount Fi of the funds minus the redemption reference Bi, and minus the first amount, i.e., ri = Fi-Bi-Favg, and

step S1310: if the second number y is smaller than the first number x, the first set may be updated to the second set and the first number x may be updated to the second number y, and the above steps S1307 to S1310 may be repeated.

In particular, in step S1309 above, if there is a total tail differential, the total tail differential can be allocated to any funds having a holding amount greater than the redemption reference line. If none of the funds have a hold amount greater than the redemption reference line, then step S1310 may be skipped for reassignment.

It can be seen that the above steps are substantially identical to those of process 1200, except that the redemption reference line is first subtracted in calculating the remaining amount. For details of the above steps reference may be made to the description of process 1200.

For funds, as described above, there may be a redemption limit on the day. Sometimes, the allocated redemption amount allocated to one or more funds may be greater than its daily redemption limit. That is, there is a difference between its allocated redemption amount and the current day redemption limit. The characteristics of the funds may be utilized at this point, with the redemption limits of other funds being borrowed first and returned the next day or later. This behavior may be referred to as bridging.

Referring now to FIG. 14, there is illustrated an example flow chart of a process 1400 for borrowing a difference between different funds in accordance with an embodiment of the disclosure.

As shown in fig. 14, process 1400 may include: in step S1401, it may be determined whether the allocated redemption amount of a first fund of the plurality of funds is greater than the current daily redemption limit for the first fund. For example, if a funds (e.g., funds A) has a redemption limit of 5000 yuan (and is not used) on the day, but is assigned a 6000 yuan assigned redemption amount, then its assigned redemption amount is greater than the redemption limit on the day.

Process 1400 may also include: in step S1402: if the allocated redemption amount of the first fund is greater than the current daily redemption limit of the first fund, borrowing one or more current daily redemption limits of the second funds to compensate for the difference of the allocated redemption amount of the first fund minus the current daily redemption limit. In the above example, there is a difference 6000-5000=1000 between the amount dispensed for redemption and the limit for redemption on the day. At this point, the first fund may borrow the deficit from one or more second funds.

Specifically, borrowing the daily redemption limit for one or more second funds to compensate for the difference of the first funds' allocated redemption amount minus the daily redemption limit may include:

at step S1403, the difference of the allocated redemption amount for the first fund minus the current redemption limit can be calculated. In the above example, the difference is 1000 yuan.

At step S1404, one or more second funds with a remaining current day redemption limit may be determined. For example, assuming that fund B is assigned a value of 2000 units of the redemption amount allocated, the current daily redemption limit for this fund B remains 5000-2000=3000 units. At this point, it can be determined that the fund B has a remaining redemption limit on the day. In some other examples, multiple second funds may be required to share the balance.

At step S1405, the spread may be allocated to the one or more second funds. As an example, the 1000-ary spread may be allocated from Fund A to Fund B. Specifically, the allocated redemption amount of fund a is adjusted to 5000 yuan of its daily redemption limit (1000 yuan of the difference is reduced), and the allocated redemption amount of fund B is increased by 1000 yuan of the difference, i.e., the allocated redemption amount of fund B at this time is 2000+10000=3000 yuan. That is, the day the fund A redeems 5000 yuan and the fund B redeems 3000 yuan. It can be seen that the total redemption amount is unchanged.

Preferably, after performing the differential borrowing, differential returns may be performed the next day or later, as desired. Specifically, preferably, the process S1400 may further include the steps of: the balance is redeemed from the first fund the next day or after redemption and the balance is purchased from the one or more second funds. In the example above, the difference 1000 yuan can be redeemed from the fund A the next day or later, when the fund A has a redemption amount. However, this difference is not transferred to the cash account of the third party platform, but is used to purchase fund B. That is, fund B is purchased with a 1000 yuan differential of redemption. By returning, the final holding amount of the final funds may be made consistent with the final holding amount obtained in process 1200 or process 1300 above.

Of course, this return step may not be performed.

Simple example of processing Fund redemption requests

Suppose that a user holds a combination of funds as shown in the following table, which includes a total of 10 funds, where the currently held and redeemable amounts of funds A-E are 10000 yuan, and the currently held and redeemable amounts of funds F-J are 2000 yuan. It can be seen that its total current held and total current redeemable amounts are 60000 yuan.

Now, suppose that the user requests redemption of 30000 yuan.

As in the example above, at initialization, the first set is made to be all funds A-J, the first number being 10.

Subsequently, a first amount favg= (60000-30000)/10=3000 yuan may be calculated.

By comparison, funds A-E were found to be currently held for a greater amount than 3000 yuan from this first amount, and thus funds A-E were placed in the second set, a second amount of 5.

It can be seen that the second number 5 is smaller than the first number 10, at which point the first set is updated to funds a-E and the first number is updated to 5, the first amount favg= (50000-30000)/5 = 4000 yuan is recalculated.

By comparison, funds A-E were found to be currently held for an amount greater than 4000 yuan from the first amount, and thus funds A-E were placed in the second set, a second amount of 5. The first quantity is then equal to the second quantity, so the distributed redemption amount ri=10000-4000=6000 yuan for each of the funds a-E can be calculated.

If the limit is redeemed regardless of the day, 6000 yuan can be redeemed from funds A-E each and not from funds F-J.

If the redemption limit is considered, assuming that the daily redemption limit for each fund is equal to or greater than 6000 yuan, 6000 yuan are still redeemed from funds A-E and not from funds F-J.

If it is assumed that the daily redemption limit for each fund is 5000 yuan, the redemption limit for the other funds F-J needs to be borrowed because the daily redemption limit 5000 yuan is less than its allocated redemption amount 6000 yuan for each of the funds A-E.

For example, 5000 elements (redemption limits) can be redeemed from funds A-E each on the day, while 1000 elements of the balance are redeemed from funds F-J, i.e., 1000 elements are redeemed from funds F-J each on the day. The total redemption amount is equal to 30000 units of the amount the user requested to be redeemed.

And the balance may be returned the next day or later. Specifically, 1000 units can be redeemed from each of funds A-E the next day or later to reach 6000 units of their allocated redemption amount. Subsequently, 1000 points are purchased for each of funds F-J with 5000 points redeemed.

In this way, the distributed redemption amount is eventually reached without consideration of the redemption limit.

Examples of tables are shown in table 1 below:

TABLE 1

Method embodiment of processing transaction request

As mentioned above, the paymate and fund management platforms may be opened. For example, the collection received by the user may be directly applied to multiple funds. It is also possible to first perform redemption in a plurality of funds and then pay the redeemed funds to other users as they pay the other users. Typically, this requires the user to be notified in advance and to be confirmed by the user.

Referring to fig. 15, a flow chart of a method 1500 for processing a payment request according to an embodiment of the present description is shown.

As shown in fig. 15, method 1500 may include: in step S1501, a payment request may be received from a first user specifying that a payment amount be paid to a second user. For example, the third party platform may receive a payment request from a first user when the first user purchases an item using an online paymate, transfers money, or performs other operations to transfer funds to other accounts. Typically, the payment request will specify the payment amount to be paid and the second user, the target user, to whom the payment amount will be transferred.

The method 1500 may further comprise: in step S1502, the payment amount can be taken as a total redemption amount that is redeemed from the plurality of funds held by the first user using the method of processing a fund redemption request in any of the embodiments above.

The method 1500 may further comprise: in step S1503, the total redemption amount may be paid to the second user. After the payment amount is redeemed and returned to the user's general account with the third party platform, the third party platform may transfer the payment amount to the second user, thereby completing the payment operation.

Similarly, when the first user receives transfers from other users, the transfer amount received by the first user can be used as a purchase amount to automatically purchase a plurality of funds held by the first user.

Other resource revocation embodiments

It will be appreciated that in many scenarios, it may be desirable to withdraw an amount of resources from multiple resource pools. The term "resource" as referred to herein may refer to various resources, including real resources, virtual resources, and the like. The term "resource pool" as referred to herein refers to a container that includes or utilizes the resources.

The above embodiments of multi-fund redemption (and even the previous task processing) can all be considered as special cases of the embodiments described below in which a certain amount of resources are withdrawn from a plurality of resource pools. In the embodiment of the fund purchase and redemption scenario described in detail above, the funds of the user are resources, and the funds held by the user can be considered as a pool of resources, where the funds of the user exist in the form of a fund share in such a pool of resources.

In other embodiments, other resources and resource pools may also exist. For example, in a communication scenario, it is possible that multiple cells are to use their resources to serve users within their coverage area. At this time, each cell may be considered as a resource pool, and the resources (e.g., frequency resources, time slot resources, etc.) of the cell are the resources within the resource pool. Assuming that one or more cells become unavailable (e.g., failed) for some reason, users served by the unavailable cells need to become served by other cells. At this point, it may be necessary to reallocate resources within the plurality of cells that are still available (e.g., to tap out the resources of the cells that become unavailable among the resources of the plurality of available cells) in order to continue providing the service.

For another example, in a cargo distribution scenario, it may be desirable for some electronic commerce to stock cargo in multiple warehouses in multiple areas. At this point, the good is a resource and the warehouse may be considered a pool of resources. If an amount of cargo is to be removed from the plurality of warehouses, it may be considered to withdraw an amount of resources from the plurality of resource pools.

As another example, in a cloud service scenario, there may be multiple Virtual Machines (VMs). These virtual machines occupy the actual resources (e.g., I/O resources, storage resources, CPU processing power resources, etc.) of the server. At this time, one virtual machine may correspond to one resource pool. It may sometimes be desirable to reduce the amount of resources occupied by these virtual machines. For example, since a new virtual machine needs to be created, resources may need to be allocated for the new virtual machine, which resources need to be withdrawn from the plurality of original virtual machines. As another example, the total amount of resources may be reduced by a server due to downtime or problems such as disk damage, which may also need to be retired from the plurality of original virtual machines.

It will be appreciated that there are other scenarios in which a certain amount of resources are withdrawn from multiple resource pools, all of which may utilize the scheme as described in embodiments of the present specification.

In the following, a specific embodiment of a process for withdrawing an amount of resources from a plurality of resource pools is generally described.

Referring to fig. 16, an example flow diagram of a method 1600 for processing a resource withdrawal request is disclosed, according to an embodiment of the present disclosure. In the examples below, virtual machine scenes are used as examples in most cases, but those skilled in the art will appreciate that the method is applicable to other scenes.

The method 1600 may include: in step S1601, a resource withdrawal request for a plurality of resource pools is received, the resource withdrawal request specifying a total withdrawn resource amount for the plurality of resource pools. Such resource withdrawal requests may be explicit or implicit. For example, in the example of a virtual machine, a system administrator may issue an explicit request to relinquish a certain amount of resources (total relinquish amount of resources). Alternatively, the resource withdrawal request may be triggered by an event such as a partial server downtime or disk corruption (e.g., transmitted by a supervisor). At this point, the total amount of retired resources may be equal to the amount of resources lost due to the event.

The method 1600 may further include: in step S1602, for each of the plurality of resource pools, a query request for a currently held resource amount and/or a currently available resource amount for the resource pool may be transmitted. For example, in a virtual machine example, a hypervisor responsible for orchestrating resource allocation may transmit to each resource pool (e.g., each virtual machine) a query request for the currently held and/or currently available amounts of resources for that resource pool. For example, the currently held amount of resources may refer to the amount of resources allocated by the virtual machine, while the currently available amount of resources may refer to the amount of resources in the virtual machine that are currently free and available for use by other virtual machines.

The method 1600 may further include: in step S1603, the currently held resource amount and/or the currently available resource amount of each of the queried resource pools may be received. For example, the hypervisor may receive the queried currently held resource amount and/or currently available resource amount from each virtual machine. In some cases, the hypervisor itself may be aware of the current amount of held resources and/or the current amount of available resources for each virtual machine, in which case step S1602 and step S1603 may be omitted or implicitly performed.

The method 1600 may further include: in step S1604, the total withdrawal amount of resources may be automatically allocated to the plurality of resource pools based on the queried current holding amount of resources and/or the current available amount of resources for each of the plurality of resource pools to determine an allocation withdrawal amount of resources for each resource pool to equalize a final holding amount of resources for each resource pool. By final holding resource amount balancing, in the virtual machine example, it may be meant that the final holding resource amount of each virtual machine is equal or approximately equal.

The method 1600 may further include: in step S1605, for one or more of the plurality of resource pools, a corresponding allocation withdrawal resource amount may be withdrawn from the resource pool.

Similar to the fund redemption or new mission process example above, to avoid too much total withdrawn resources, the following operations may be performed prior to the automatic allocation step. First, a total current amount of available resources may be calculated based on the current amount of available resources for each resource pool queried. The total withdrawn resource amount may then be compared to the total current available resource amount. If the total amount of relinquished resources is greater than the total amount of currently available resources, a failure to relinquish the total amount of relinquished resources may be prompted.

In some special cases, the server may have some provisions for the withdrawal of resources. For example, during the current period (e.g., the day), there may be a period withdrawal limit (e.g., the day withdrawal limit). For example, to ensure smooth execution of tasks within the current cycle, it is possible that an amount of resources greater than the withdrawal limit is not allowed to be withdrawn per cycle. At this time, the following operations may be performed: first, a total current day withdrawal limit for each of the plurality of resource pools may be calculated based on the current day withdrawal limit for the plurality of resource pools. The total revoked resource amount may then be compared to the total current day revocation limit. If the total amount of revoked resources is greater than the total current day revocation limit, a failure to revoke the total amount of revoked resources may be prompted.

Generally, the above-described automatic dispensing operation may be performed in the following manner.

First, a set of resource pools from which resources are to be withdrawn may be initialized. For example, the set of resource pools may be initialized to all virtual machines. Alternatively, the resource pool set may be initialized to other sets, such as a set specified by a system administrator or supervisor.

The set of resource pools may then be iteratively updated such that the current amount of held resources for all resource pools in the set of resource pools is greater than the average amount of held resources after the resources are retired.

Then, an allocation grant resource amount for a resource pool in the updated set of resource pools may be calculated based on the average holding resource amount.

For specific details of the above steps, reference may be made to examples of processes 400 and 500 and/or processes 1200 and 1300, which are not described in detail herein.

Similar to the new mission process or multi-fund redemption embodiment above, in other scenarios, situations may also be encountered where the resource pool has a resource benchmark. For example, for the virtual machine example, it is possible that each virtual machine (resource pool) has a minimum resource requirement that can be considered a resource benchmark (which is similar to a redemption benchmark). In the case where a resource reference line exists, the automatic allocation operation may further include the following operations.

A resource reference line for each of the plurality of resource pools may be determined. For example, a hypervisor or system administrator may query or otherwise determine the minimum resource requirements for each virtual machine. If the sum of the resource reference lines of the plurality of resource pools and the sum of the total withdrawn resource amounts is greater than or equal to the total currently held resource amount of the plurality of resource pools, the allocation withdrawn resource amount of each resource pool may be determined if the final held resource amount of each resource pool is greater than or equal to its resource reference line. If the sum of the resource reference lines of the plurality of resource pools and the sum of the total withdrawal resource amounts are not greater than the total currently held resource amount of the plurality of resource pools, then the resource amount of each of the currently held resource amounts greater than its resource reference line may be divided into its allocation withdrawal resource amount, and then the remaining held resource amounts of one or more resource pools may be divided into its allocation withdrawal resource amount as well by priority.

For specific details of the above steps, reference may be made to examples of processes 400 and 500 and/or processes 1200 and 1300, which are not described in detail herein.

In some cases, where each resource pool (e.g., virtual machine) has a current day withdrawal limit (or other period withdrawal limit), borrowing may be performed between different resource pools to still withdraw the total withdrawn amount of resources if the period withdrawal limit is satisfied. The borrowing process may be implemented by the following steps.

First, it may be determined whether an allocation withdrawal resource amount of a first resource pool of the plurality of resource pools is greater than a current day withdrawal limit for the first resource pool. If the amount of allocated withdrawal resources of the first resource pool is greater than the current day withdrawal limit of the first resource pool, the current day withdrawal limit of one or more second resource pools may be borrowed to compensate for the difference of the amount of allocated withdrawal resources of the first resource pool minus the current day withdrawal limit. The borrowing may be achieved in particular in the following way.

For example, the difference of the allocated relinquish resource amount of the first resource pool minus the current day relinquish quota may be calculated. Subsequently, one or more second resource pools with remaining current day withdrawal limits may be determined. The deficit may then be allocated to the one or more second resource pools.

The borrowed margin may be returned in a subsequent period (e.g., the next day or later). This return operation may be achieved in the following manner. For example, the deficit may be withdrawn from the first resource pool and the deficit may be replenished to the one or more second resource pools after or after the next withdrawal.

It will be appreciated that since funds are one type of resource and funds can be considered a pool of resources, upon reading the general resource revocation procedure above, reference is made to the details described above for the multi-fund redemption embodiment.

Also disclosed is a computer-readable storage medium comprising computer-executable instructions stored thereon, which when executed by a processor, cause the processor to perform the methods of the embodiments described herein.

Furthermore, a system is disclosed, comprising means for implementing the methods of the embodiments described herein.

It is to be understood that methods in accordance with one or more embodiments of the present description may be implemented in software, firmware, or a combination thereof.

It should be understood that each embodiment in this specification is described in an incremental manner, and the same or similar parts between each embodiment are all referred to each other, and each embodiment focuses on differences from other embodiments. In particular, for apparatus and system embodiments, the description is relatively simple, as it is substantially similar to method embodiments, with reference to the description of method embodiments in part. It will be appreciated that the present specification discloses a number of embodiments, the disclosure of which may be understood with reference to each other.

It should be understood that the foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

It should be understood that elements described herein in the singular or shown in the drawings are not intended to limit the number of elements to one. Furthermore, modules or elements described or illustrated herein as separate may be combined into a single module or element, and modules or elements described or illustrated herein as a single may be split into multiple modules or elements.

It is also to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting. The use of these terms and expressions is not meant to exclude any equivalents of the features shown and described (or portions thereof), and it is recognized that various modifications are possible and are intended to be included within the scope of the claims. Other modifications, variations, and alternatives are also possible. Accordingly, the claims should be looked to in order to cover all such equivalents.

Also, it should be noted that while the above-mentioned embodiments have been described with reference to the present specific embodiments, those skilled in the art will recognize that the above-mentioned embodiments are merely illustrative of one or more embodiments of the present application, and that various equivalent changes or substitutions can be made without departing from the spirit of the application, and therefore, all changes and modifications to the above-mentioned embodiments are within the scope of the appended claims.

Claims (15)

1. A method for performing a new task on a server, comprising:

receiving a request to execute a new task on the server, the request specifying an amount of resources required to execute the new task, the server currently executing a plurality of executing tasks;

for each of the plurality of executing tasks, querying a current amount of occupied resources and a current amount of releasable resources for the executing task;

automatically allocating the required amount of resources among the plurality of executing tasks based on the queried current amount of resources occupied and/or the current amount of releasable resources for each of the plurality of executing tasks to determine an amount of reallocated resources for each executing task to equalize an amount of final occupied resources for each executing task; and

the new task is allocated an amount of reallocation resources for each executing task,

wherein automatically allocating the required amount of resources among the plurality of executing tasks comprises:

initializing an executing task set from which the amount of resources is to be reallocated;

iteratively updating the executing task set so that the current occupied resource quantity of all the executing tasks in the executing task set is larger than the average occupied resource quantity after the resources are reallocated;

An amount of reallocated resources for an executing task of the updated set of executing tasks is calculated based on the average amount of occupied resources.

2. The method of claim 1, the method further comprising:

calculating the total current releasable resource amount of the server based on the queried current releasable resource amount of each executing task;

comparing the required amount of resources with the total current releasable amount of resources; and

if the required amount of resources is greater than the total current releasable amount of resources, then the required amount of resources for the new task is prompted to be too high.

3. The method of claim 1, wherein automatically allocating the required amount of resources among the plurality of executing tasks comprises:

determining a resource reference line for each of the plurality of executing tasks;

if the sum of the resource reference lines of the plurality of executing tasks and the sum of the required resource amounts is more than or equal to the total current occupied resource amount of the plurality of executing tasks, determining the reallocation resource amount of each executing task under the condition that the final occupied resource amount of each executing task is more than or equal to the resource reference line;

if the sum of the resource reference lines of the plurality of executing tasks and the sum of the required resource amounts are not greater than the total currently occupied resource amount of the plurality of executing tasks, the resource amount of each of the currently occupied resource amounts of the executing tasks, which is greater than the resource reference line thereof, is divided into the reallocated resource amounts thereof, and then the remaining occupied resource amounts of one or more executing tasks are also divided into the reallocated resource amounts thereof according to priorities.

4. The method of claim 1, the method further comprising:

determining whether an amount of reallocated resources of a first executing task of the plurality of executing tasks is greater than a current amount of releasable resources of the first executing task; and

if the amount of reallocated resources of the first executing task is greater than the amount of current releasable resources of the first executing task, borrowing the amount of current releasable resources of one or more second executing tasks to compensate for the difference of the amount of reallocated resources of the first executing task minus the amount of current releasable resources.

5. The method of claim 4, borrowing the current amount of releasable resources of the one or more second executing tasks to compensate for the difference of the amount of reallocated resources of the first executing task minus the current amount of releasable resources comprising:

calculating a difference of the reallocated resource amount of the first executing task minus the current releasable resource amount;

determining one or more second executing tasks having a remaining current amount of releasable resources;

the deficit is assigned to the one or more second executing tasks.

6. The method of claim 1, the amount of resources comprising one or more of an amount of computing resources, an amount of storage resources, an amount of network resources.

7. A method for processing a resource withdrawal request, comprising:

receiving a resource withdrawal request for a plurality of resource pools, the resource withdrawal request specifying a total withdrawn resource amount for the plurality of resource pools;

for each of the plurality of resource pools, transmitting a query request for a currently held resource amount and/or a currently available resource amount for the resource pool;

receiving the queried currently held resource quantity and/or the currently available resource quantity of each resource pool;

automatically allocating the total withdrawn resource amount to the plurality of resource pools based on the queried currently held resource amount and/or the currently available resource amount of each of the plurality of resource pools to determine an allocation withdrawn resource amount for each resource pool to equalize a final held resource amount for each resource pool; and

for one or more of the plurality of resource pools, withdrawing a corresponding allocation withdrawal resource amount from the resource pool,

wherein automatically allocating the total withdrawn resource amount to the plurality of resource pools to determine an allocation withdrawn resource amount for each resource pool comprises:

initializing a resource pool set from which resources are to be withdrawn;

Iteratively updating the resource pool set so that the current holding resource amount of all resource pools in the resource pool set is larger than the average holding resource amount after the resources are withdrawn;

an allocation withdrawal resource amount for a resource pool in the updated set of resource pools is calculated based on the average holding resource amount.

8. The method of claim 7, the method further comprising:

calculating a total current available resource amount based on the current available resource amount of each queried resource pool;

comparing the total withdrawn amount of resources with the total current amount of available resources; and

if the total amount of revoked resources is greater than the total amount of currently available resources, then prompting that the total amount of revoked resources cannot be revoked.

9. The method of claim 7, the method further comprising:

calculating a total current day withdrawal limit for each of the plurality of resource pools based on the current day withdrawal limit for the plurality of resource pools;

comparing the total revoked resource amount with the total current day revocation limit; and

if the total amount of revoked resources is greater than the total current day revocation limit, prompting that the total amount of revoked resources cannot be revoked.

10. The method of claim 7, automatically allocating the total withdrawn resource amount to the plurality of resource pools to determine an allocated withdrawn resource amount for each resource pool comprises:

Determining a resource reference line for each of the plurality of resource pools;

if the sum of the resource reference lines of the plurality of resource pools and the sum of the total withdrawal resource amounts are greater than or equal to the total current holding resource amount of the plurality of resource pools, determining the allocation withdrawal resource amount of each resource pool under the condition that the final holding resource amount of each resource pool is greater than or equal to the resource reference line;

if the sum of the resource reference lines of the plurality of resource pools and the sum of the total withdrawal resource amounts are not greater than the total currently held resource amount of the plurality of resource pools, then the resource amount of each resource pool that is greater than its resource reference line in the currently held resource amount is divided into its allocation withdrawal resource amount, and then the remaining held resource amounts of one or more resource pools are also divided into their allocation withdrawal resource amounts by priority.

11. The method of claim 7, the method further comprising:

determining whether an allocation withdrawal resource amount of a first resource pool of the plurality of resource pools is greater than a current day withdrawal limit for the first resource pool; and

if the allocation withdrawal resource amount of the first resource pool is greater than the current day withdrawal limit of the first resource pool, borrowing the current day withdrawal limit of one or more second resource pools to compensate for the difference of the allocation withdrawal resource amount of the first resource pool minus the current day withdrawal limit.

12. The method of claim 11, borrowing the current day withdrawal limit for one or more second resource pools to offset the difference of the allocated withdrawal resource amount for the first resource pool minus the current day withdrawal limit comprising:

calculating a difference of the allocation withdrawal resource quantity of the first resource pool minus the withdrawal allowance of the current day;

determining one or more second resource pools having remaining current day withdrawal limits;

the deficit is allocated to the one or more second resource pools.

13. The method of claim 12, borrowing the current day withdrawal limit for one or more second resource pools to offset the difference of the allocated withdrawal resource amount for the first resource pool minus the current day withdrawal limit further comprising:

the deficit is withdrawn from the first resource pool and the deficit is replenished to the one or more second resource pools after or after the next withdrawal.

14. A computer readable storage medium storing instructions which, when executed by a computer, cause the computer to perform the method of any one of claims 1-6.

15. A computer readable storage medium storing instructions which, when executed by a computer, cause the computer to perform the method of any one of claims 7-13.