Resource allocation method, device, electronic device and storage medium

Abstract

The present invention provides a resource allocation method, apparatus, electronic device, and storage medium. The method comprises: receiving a task request from a requester; allocating a resource token to the task request based on a token queue, and forwarding the task request to an executor corresponding to the resource token. The token queue is determined based on resource tokens corresponding to multiple executors, each of which represents the resources required by a single executor to execute a single task request. The method, apparatus, electronic device, and storage medium provided by the present invention are suitable for execution environments with heterogeneous resources, adjustable resource availability, and shared resources, thereby improving resource allocation efficiency.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a resource allocation method, device, electronic device and storage medium. Background Art

[0002] Systems serving large numbers of users often have numerous computing nodes, forming a distributed system. Within this system, the number of task requests initiated by users fluctuates over time, with the fluctuation curve exhibiting certain periodicity, randomness, and event correlation. The total available resources, however, are the sum of all computing node resources within the system. This total available resources cannot be arbitrarily changed in the short term (seconds, levels, or even hours or days).

[0003] In existing technologies, resource allocation within a system assumes that worker nodes are homogeneous, with each node having the same computing power. Resource allocation is performed by setting upper and lower limits for worker nodes. This existing resource allocation method cannot adapt to execution environments with fluctuating resource quantities, heterogeneous worker nodes, and resource sharing, resulting in resource waste and low resource allocation efficiency. Summary of the Invention

[0004] The present invention provides a resource allocation method, device, electronic device and storage medium to solve the technical problems in the prior art that the resource allocation method cannot adapt to the execution environment with changing resource quantity, heterogeneous working nodes and resource sharing, and has low resource allocation efficiency.

[0005] The present invention provides a resource allocation method, comprising:

[0006] Receive task requests sent by requesters;

[0007] Allocating a resource token to the task request based on a token queue, and forwarding the task request to an executor corresponding to the resource token;

[0008] The token queue is determined based on resource tokens corresponding to multiple executors, and the resource token represents the resources required by a single executor to execute a single task request.

[0009] According to the resource allocation method provided by the present invention, the token queue is updated based on the following steps:

[0010] If the executor list change event is monitored, the new version of the executor information list is obtained, and the old version of the executor information list is obtained based on the token queue;

[0011] Determine available executors and resource tokens of the available executors based on the new version executor information list and the old version executor information list;

[0012] The token queue is updated based on the resource tokens of the available performers.

[0013] According to the resource allocation method provided by the present invention, the token queue is updated based on the following steps:

[0014] If a timer event is monitored, the resource tokens corresponding to each executor in the token queue are adjusted.

[0015] According to the resource allocation method provided by the present invention, adjusting the resource tokens corresponding to the respective executors in the token queue includes:

[0016] Based on the number of resource tokens of any executor and the sum of the number of successful executions of all resource tokens in the current adjustment period, as well as the number of resource tokens of any executor and the sum of the number of successful executions of all resource tokens in the previous adjustment period, the number of resource tokens of any executor in the next adjustment period is adjusted.

[0017] According to the resource allocation method provided by the present invention, the number of resource tokens of any executor in the next adjustment period is adjusted based on the number of resource tokens of any executor and the sum of the number of successful executions of all resource tokens in the current adjustment period, and the number of resource tokens of any executor and the sum of the number of successful executions of all resource tokens in the previous adjustment period, including:

[0018] Determining the execution status of any executor based on the number of resource tokens of any executor in the current adjustment period and the previous adjustment period respectively;

[0019] Determining a task execution amount change status of any executor based on the sum of the number of successful executions of all resource tokens of any executor in the current adjustment period and the previous adjustment period;

[0020] Based on the execution status of any one of the executors and the task execution amount change status, the number of resource tokens of any one of the executors in the next adjustment period is adjusted.

[0021] According to the resource allocation method provided by the present invention, allocating resource tokens to the task request based on a token queue includes:

[0022] If the task request cannot be allocated a resource token, the task request is set to a waiting state.

[0023] According to the resource allocation method provided by the present invention, the information in the resource token includes at least one of connection information, total usage times, current execution times, current failure times, available information and allocation information.

[0024] The present invention provides a resource allocation device, comprising:

[0025] A receiving unit, configured to receive a task request sent by a requester;

[0026] an allocating unit, configured to allocate a resource token to the task request based on a token queue, and forward the task request to an executor corresponding to the resource token;

[0027] The token queue is determined based on resource tokens corresponding to multiple executors, and the resource token represents the resources required by a single executor to execute a single task request.

[0028] The present invention also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the resource allocation method when executing the program.

[0029] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the steps of the resource allocation method when executed by a processor.

[0030] The resource allocation method, device, electronic device and storage medium provided by the present invention use resource tokens to represent the resources carried by an executor when executing a task request, and allocate corresponding executors to the received task requests according to the token queue. The token queue is determined based on multiple executors and the resource tokens corresponding to each executor, and can be dynamically adjusted according to changes in the executors. It is suitable for execution environments with heterogeneous resources, adjustable resource quantities, and shared resources, thereby improving resource allocation efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0032] Figure 1 A schematic diagram of the flow of the resource allocation method provided by the present invention;

[0033] Figure 2 A working principle diagram of the decision-making state machine provided by the present invention;

[0034] Figure 3 A diagram showing the working principle of the coordinator provided by the present invention;

[0035] Figure 4 A schematic diagram of the structure of the resource allocation device provided by the present invention;

[0036] Figure 5 This is a schematic structural diagram of the electronic device provided by the present invention. DETAILED DESCRIPTION

[0037] To make the objectives, technical solutions, and advantages of the present invention more clear, the technical solutions of the present invention will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the embodiments described are only some of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0038] In a distributed system, each user request consumes a certain amount of computing resources. The total number of user requests at a given moment determines the total resource demand. Due to the volatility of the resource demand curve, determining the total resource supply of a distributed system is a challenge. The total resource supply is generally not determined based on the troughs and peaks of the demand fluctuation curve. The troughs of demand may be zero. Peaks of demand are difficult to predict due to their randomness. Furthermore, determining the total resource supply based on peaks of demand will result in long periods of idleness, resulting in significant resource waste and high costs. Therefore, the total resource supply of a distributed system is generally set, based on experience, to fall between the troughs and peaks of the demand curve.

[0039] In a cloud computing environment, the total amount of available resources can be prepared in advance or released in a timely manner based on historical demand forecasts, allowing the total amount of available resources to fluctuate over a longer period of time. Whether the system's available resources are fixed or adjustable, they are both preliminary, coarse-grained, and non-instantaneous resource allocation methods. The resources of the entire distributed system still need to be divided into a large amount of small-grained computing resources that can satisfy individual user requests. How to match these small-grained resources with each user request event is also a challenge.

[0040] Each user request is a task, and the system needs to allocate a certain amount of resources to each task. Once the task is completed, the resources are released and available for the next task. The client sends a request; the scheduler receives the request and allocates resources; the worker node executes the task and returns the result.

[0041] Figure 1 A schematic diagram of the resource allocation method provided by the present invention is shown in FIG. Figure 1 As shown, the method includes:

[0042] Step 110: Receive a task request sent by a requester.

[0043] Specifically, according to the functions of various processes, hosts, gateways, etc. in a distributed system, they can be divided into requesters, coordinators, and executors. The method provided in the embodiment of the present invention is applied to the coordinator.

[0044] The requester primarily initiates requests, generates tasks, or triggers events, waiting for other roles to complete their execution and return results. For example, a browser initiates a request to Nginx, a Duboo Consumer initiates a remote procedure call to a Provider, and an ActiveMQ producer sends a message to a consumer requiring a result. The coordinator receives and temporarily stores all tasks, manages all executable resources, adaptively identifies and adjusts the amount of executable resources, and attempts to pair tasks with resources to ensure task execution while achieving full resource utilization and load balancing. The executor is a worker or service provider that can concurrently execute multiple received tasks.

[0045] The requester can be an independent process or co-located with the coordinator. The coordinator and executors are independent processes, typically distributed across multiple nodes. Executor processes can share node resources with other systems. The number of executors can be increased or decreased. The nodes where executors reside can have heterogeneous resources, such as varying processing speeds. The number of requesters and executors is typically greater than the number of coordinators.

[0046] If the requester is an independent process, it can initiate requests to multiple coordinators simultaneously, such as sending an authentication request to the login coordinator and a service request to a specific service coordinator. Multiple coordinators run independently and can simultaneously assign tasks to the same executor.

[0047] Step 120, allocates a resource token to the task request based on the token queue, and forwards the task request to the executor corresponding to the resource token; wherein the token queue is determined based on the resource tokens corresponding to multiple executors, and the resource token represents the resources required for a single executor to execute a single task request.

[0048] Specifically, the coordinator includes a token queue. The token queue stores all resource tokens. Each resource token represents a small-grained resource capable of executing a single request. An executor is typically associated with multiple resource tokens, indicating that the executor can execute multiple requests or tasks simultaneously. The number of resource tokens associated with an executor can be adjusted to suit the executor's current execution capacity. The token queue is a shared space that supports concurrent access.

[0049] When a task request is received, the coordinator allocates resource tokens in FIFO (first-in, first-out) order. Resource tokens are acquired using the FIFO principle, starting with the first available, unoccupied resource token. If a resource token is acquired, a task token mapping is established and the task is forwarded to the executor specified by the resource token. Upon the executor's return, the mapping logic modifies the resource token statistics and releases the corresponding resource token, completing the execution of the task request. If a resource token is not acquired, the task is blocked or temporarily stored until a resource token becomes available and an acquisition attempt is made again.

[0050] Token queues can be determined based on multiple executors and the resource tokens associated with each executor. For example, a service discovery mechanism can be used to accept executor registration and deregistration requests. Alternatively, executors can be proactively discovered and promptly notified to a coordinator that monitors executor list changes. The coordinator monitors the service discovery mechanism for executor list update events and promptly adjusts the state of the internal tokens representing resources. Executors can have internal concurrency management mechanisms or, in the simplest case, immediately and concurrently execute every request they receive.

[0051] The resource allocation method provided by the present invention adopts resource tokens to represent the resources carried by an executor when executing a task request, and allocates the corresponding executor to the received task request according to the token queue. The token queue is determined based on multiple executors and the resource tokens corresponding to each executor, and can be dynamically adjusted according to the changes of the executors. It is suitable for execution environments with heterogeneous resources, adjustable resource quantities, and shared resources, thereby improving the efficiency of resource allocation.

[0052] Based on the above embodiment, the token queue is updated based on the following steps:

[0053] If the executor list change event is monitored, the new version of the executor information list is obtained, and the old version of the executor information list is obtained based on the token queue;

[0054] Based on the new version executor information list and the old version executor information list, determine the available executors and the resource tokens of the available executors;

[0055] The token queue is updated based on the available executors' resource tokens.

[0056] Specifically, the coordinator can establish a request temporary storage space to store multiple task requests received. In the initial stage of the coordinator's operation, the token queue and the request temporary storage space are empty, that is, there are no available resources and no task requests. It is possible that the token queue is not empty first, or the request temporary storage space is not empty first, but it is not until the token queue and the request temporary storage space are not empty at the same time that a token is allocated to the request, and a task token mapping is formed to start execution. When the requester initiates a request, the request temporary storage space starts to be in a non-empty state; when the token generator receives the executor list change event notified by the service discovery mechanism, and finds an available execution node and creates a resource token, the token queue starts to be in a non-empty state.

[0057] The coordinator can also include a token generator, which determines the token queue. When the token generator listens for executor list changes, it first extracts the latest executor list, including their connection information and availability. It then collects the old executor information known to the coordinator from the token queue, including their connection information and availability, and updates the token queue according to the following rules.

[0058] First, define "executors included in the new version of the executor information list but not in the old version" as set A; define "executors included in both versions" as set B; define "executors not included in the new version of the executor information list but included in the old version of the executor information list" as set C.

[0059] Secondly, for the unavailable executor information in set A, it is directly ignored; for the available executor information in set A, resource tokens are created for the available executors, and the number is the average number of tokens per executor calculated based on the old version of the executor information list; for the unavailable executor information in set B, all tokens of the executor are merged into one, and the availability flag is set to no; for the available executor information in set B, the availability flag of all tokens of the executor is set to yes; for the executor information in set C, it is directly ignored.

[0060] The resource allocation method provided by the present invention updates available executors according to monitored executor list change events, determines resource tokens of available executors, thereby determining token queues, and realizes instant recognition of fluctuating available resource amounts.

[0061] Based on any of the above embodiments, the token queue is updated based on the following steps:

[0062] If a timer event is monitored, the resource tokens corresponding to each executor in the token queue are adjusted.

[0063] Specifically, the coordinator uses a timer to generate an adjustment cycle and listens for timer events. The token generator executes the token adjustment algorithm once during each adjustment cycle. The token generator first obtains all executors from the token queue and then independently adjusts the resource token of each executor in turn.

[0064] Based on any of the above embodiments, adjusting the resource tokens corresponding to each executor in the token queue includes:

[0065] Based on the number of resource tokens of any executor and the sum of the number of successful executions of all resource tokens in the current adjustment period, as well as the number of resource tokens of the executor and the sum of the number of successful executions of all resource tokens in the previous adjustment period, the number of resource tokens of the executor in the next adjustment period is adjusted.

[0066] Specifically, the number of resource tokens of an executor can be used to measure the executor's ability to handle task requests. The number of successful executions of all resource tokens of an executor can be used to measure the executor's processing capacity when executing task requests.

[0067] The number of resource tokens allocated to an executor in the next adjustment cycle can be adjusted based on the number of resource tokens and successful executions of resource tokens in the current adjustment cycle, as well as the number of resource tokens and successful executions of resource tokens in the previous adjustment cycle. For example, if the number of resource tokens and the number of successful executions of all resource tokens of an executor in the current adjustment cycle both increase compared to the previous adjustment cycle, this indicates that the executor is able to handle more business.

[0068] Based on any of the above embodiments, based on the number of resource tokens of any executor and the sum of the number of successful executions of all resource tokens in the current adjustment period, and the number of resource tokens of any executor and the sum of the number of successful executions of all resource tokens in the previous adjustment period, the number of resource tokens of any executor in the next adjustment period is adjusted, including:

[0069] Determine the execution status of any executor based on the number of resource tokens of any executor in the current adjustment period and the previous adjustment period;

[0070] Determine the task execution amount change status of any executor based on the sum of the number of successful executions of all resource tokens of any executor in the current adjustment period and the previous adjustment period;

[0071] Based on the execution status of any executor and the change status of task execution volume, the number of resource tokens of any executor in the next adjustment cycle is adjusted.

[0072] Specifically, adjusting the number of resource tokens of any executor in the next adjustment period can be achieved through a token adjustment algorithm.

[0073] At the beginning of adjusting the token of a certain executor, the token adjustment algorithm first counts the number of tokens x of the executor from the token queue in the current adjustment cycle. t , and the sum of the number of successful executions of all tokens of the executor y t At the same time, obtain the number of tokens x stored by the executor in the previous adjustment cycle t-1 The sum of the number of successful executions of all the information of the executor y t-1 If there is no last record at startup, set the last record to 0. And calculate Δx according to the following formula t ,Δy t .

[0074]

[0075]

[0076] According to the function F(Δx t , Δy t )→Δx t+1 , substitute Δx t , Δy t , we can get Δx t+1 .

[0077] Where Δx t is the state of the executor. t =1 is the expansion state, indicating that the executor can carry more tasks or requests; Δx t = -1 is the contraction state, which means that the executor cannot continue to carry new tasks because it carries too many tasks or the shared node where it is located is occupied by too many resources by other systems, and it needs to reduce the number of concurrent tasks it carries. t =1 is the initial state.

[0078] Δy t is the change in task execution volume, Δy t =1 indicates growth, which means that the current executor has executed more tasks, which may be due to the increase in concurrency or the increase in available resources. t =-1 indicates a decrease, which means that the current executor has performed fewer tasks in this cycle.

[0079] The above function F can adopt a decision state machine model. Figure 2 The working principle diagram of the decision state machine provided by the present invention is as follows: Figure 2 As shown, the circle with numbers is Δx t , the directed edge with a number is Δy t .

[0080] According to the decision state machine model, based on the execution status of any executor and the change status of task execution volume, the number of resource tokens of any executor in the next adjustment cycle is adjusted according to the following rules:

[0081] If the execution status of any executor is expansion and the task execution amount change status is increase, the execution status of the executor in the next adjustment cycle will be expansion;

[0082] If the execution state of any executor is expansion state and the task execution amount change state is reduction, the execution state of the executor in the next adjustment cycle will be contraction state;

[0083] If the execution status of any executor is in the contraction state and the task execution amount change state is increasing, the execution status of the executor in the next adjustment cycle will be in the contraction state;

[0084] If the execution state of any executor is contraction state and the task execution amount change state is reduction, the execution state of the executor in the next adjustment cycle is expansion state;

[0085] When the execution state of the executor in the next adjustment cycle is an expansion state, one resource token may be added; when the execution state of the executor in the next adjustment cycle is a contraction state, one resource token may be reduced.

[0086] The directed arrow indicates that the corresponding task execution amount change Δy occurs in the current state t The next state to be transferred. The next state also indicates the adjustment action to be taken. For example, Δx t =1,Δy t =1, it should migrate to Δx t+1 =1, indicating that tokens have been added in the past and the amount of task execution has also increased, so tokens should continue to be added.

[0087] The resource allocation method provided by the present invention uses a decision state machine model to adjust the number of resource tokens of any executor in the next adjustment cycle according to the execution status of any executor and the change status of task execution volume, and can allocate resources for task request volumes that fluctuate at any time.

[0088] Based on any of the above embodiments, step 120 includes:

[0089] If the task request cannot be allocated a resource token, the task request is set to a waiting state.

[0090] Specifically, the request spooling mechanism primarily places each request, event, or task in a waiting state before resources are allocated. This mechanism can be implemented in a variety of ways, including blocking threads, connection state storage, message queues, and internal queues. The blocking thread approach uses a thread upper limit to control the number of spooled tasks. Each task and its corresponding thread are blocked if a token cannot be obtained. Connection state storage processes each task asynchronously, with each connection corresponding to a task. The amount of task spooling is controlled by controlling the connection upper limit. Similar to the internal queue, the message queue stores each task in a queue format.

[0091] Based on any of the above embodiments, the information in the resource token includes at least one of connection information, total usage times, current execution times, current failure times, available information, and allocation information.

[0092] Specifically, each resource token contains the following information:

[0093] The connection information is used to find the corresponding executor. The total number of uses is the number of times the token has been used from its creation to its destruction. Each number represents a task executed by a small-grained resource of the executor. The current number of executions is the number of times the token has been used since the last statistic and before the next statistic begins. The current number of failures is the number of times the token has been used but failed due to resource anomalies since the last statistic and before the next statistic begins. The availability information is used to indicate whether the token is available. If the corresponding executor is offline, inaccessible, or cannot provide services for other reasons, the flag is no, otherwise it is yes. The allocation information indicates whether the token has been allocated.

[0094] Based on any of the above embodiments, Figure 3 The working principle diagram of the coordinator provided by the present invention is as follows: Figure 3 As shown, the coordinator includes a token generator, a token queue, a request spooling mechanism, and a mapping group. The coordinator listens for request events triggered by requesters, token adjustment events triggered by timers, and executor list change events triggered by the service discovery mechanism. The service discovery mechanism accepts executor registration and deregistration requests, proactively discovers executors, and promptly notifies the coordinator, which listens for executor list change events.

[0095] The resource allocation method provided in the embodiments of the present invention is applied to a coordinator. In an execution environment with heterogeneous resources, variable resource availability, and resource sharing, it instantly identifies the fluctuating upper limit of available resources and allocates resources accordingly to the fluctuating task request volume, thereby forming a high-throughput distributed system with the highest possible task request processing rate. It also adapts to differences in computing power among different resource nodes; to fluctuations in available resources caused by shared resources being occupied by other systems; and to the increase, decrease, and failure of the number of working nodes.

[0096] Based on any of the above embodiments, Figure 4 A schematic diagram of the structure of the resource allocation device provided by the present invention, such as Figure 4 As shown, the device includes:

[0097] The receiving unit 410 is configured to receive a task request sent by a requester;

[0098] An allocating unit 420 is configured to allocate a resource token to a task request based on a token queue, and forward the task request to an executor corresponding to the resource token;

[0099] The token queue is determined based on the resource tokens corresponding to multiple executors. The resource token represents the resources required by a single executor to execute a single task request.

[0100] The resource allocation device provided by an embodiment of the present invention uses resource tokens to represent the resources carried by an executor when executing a task request, and allocates corresponding executors to the received task requests according to the token queue. The token queue is determined based on multiple executors and the resource tokens corresponding to each executor, and can be dynamically adjusted according to changes in the executors. It is suitable for execution environments with heterogeneous resources, adjustable resource quantities, and shared resources, thereby improving resource allocation efficiency.

[0101] Based on any of the above embodiments, the device includes:

[0102] The first update unit is used to obtain a new version of the executor information list if an executor list change event is monitored, and obtain an old version of the executor information list based on the token queue; determine the available executors and the resource tokens of the available executors based on the new version of the executor information list and the old version of the executor information list; and update the token queue based on the resource tokens of the available executors.

[0103] Based on any of the above embodiments, the device includes:

[0104] The second updating unit is configured to adjust the resource tokens corresponding to the respective executors in the token queue if a timer event is monitored.

[0105] Based on any of the foregoing embodiments, the second updating unit is specifically configured to:

[0106] Based on the number of resource tokens of any executor and the sum of the number of successful executions of all resource tokens in the current adjustment period, and the number of resource tokens of any executor and the sum of the number of successful executions of all resource tokens in the previous adjustment period, the number of resource tokens of any executor in the next adjustment period is adjusted.

[0107] Based on any of the above embodiments, the second updating unit includes:

[0108] An execution status determination subunit, configured to determine the execution status of any executor based on the number of resource tokens of any executor in the current adjustment period and the previous adjustment period respectively;

[0109] An execution amount change state determination subunit, configured to determine a task execution amount change state of any executor based on the sum of the number of successful executions of all resource tokens of any executor in the current adjustment period and the previous adjustment period;

[0110] The token update subunit is used to adjust the number of resource tokens of any executor in the next adjustment cycle based on the execution status of any executor and the change status of the task execution amount.

[0111] Based on any of the above embodiments, the device further includes:

[0112] The request temporary storage unit is used to set the task request to a waiting state if the task request cannot be allocated a resource token.

[0113] Based on any of the above embodiments, the information in the resource token includes at least one of connection information, total usage times, current execution times, current failure times, available information, and allocation information.

[0114] Based on any of the above embodiments, Figure 5 A schematic diagram of the structure of the electronic device provided by the present invention, such as Figure 5 As shown, the electronic device may include: a processor (Processor) 510, a communication interface (Communications Interface) 520, a memory (Memory) 530 and a communication bus (Communications Bus) 540, wherein the processor 510, the communication interface 520, and the memory 530 communicate with each other via the communication bus 540. The processor 510 may call the logic commands in the memory 530 to execute the following method:

[0115] Receive a task request sent by a requester; allocate a resource token to the task request based on a token queue, and forward the task request to the executor corresponding to the resource token; wherein the token queue is determined based on the resource tokens corresponding to multiple executors, and the resource token represents the resources required for a single executor to execute a single task request.

[0116] In addition, the logical commands in the above-mentioned memory 530 can be implemented in the form of software functional units and can be stored in a computer-readable storage medium when sold or used as an independent product. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several commands to enable a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0117] The processor in the electronic device provided by the embodiment of the present invention can call the logic instructions in the memory to implement the above method. Its specific implementation method is consistent with the implementation method of the above method and can achieve the same beneficial effects, which will not be repeated here.

[0118] An embodiment of the present invention further provides a non-transitory computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the method provided in each of the above embodiments is implemented, for example, including:

[0119] Receive a task request sent by a requester; allocate a resource token to the task request based on a token queue, and forward the task request to the executor corresponding to the resource token; wherein the token queue is determined based on the resource tokens corresponding to multiple executors, and the resource token represents the resources required for a single executor to execute a single task request.

[0120] When the computer program stored on the non-transitory computer-readable storage medium provided by the embodiment of the present invention is executed, the above method is implemented. Its specific implementation method is consistent with the implementation method of the aforementioned method and can achieve the same beneficial effects, which will not be repeated here.

[0121] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, i.e., they may be located in one location or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of the present embodiment. Persons of ordinary skill in the art will be able to understand and implement the present invention without inventive effort.

[0122] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a necessary general hardware platform, or of course, by hardware. Based on this understanding, the essence of the above technical solution or the part that contributes to the existing technology can be embodied in the form of a software product. The computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of commands for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or certain parts of the embodiment.

[0123] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A resource allocation method, characterized in that: include: Receive task requests sent by requesters; Allocating a resource token to the task request based on a token queue, and forwarding the task request to an executor corresponding to the resource token; The token queue is determined based on resource tokens corresponding to multiple executors, and the resource token represents the resources required by a single executor to execute a single task request; The token queue is updated based on the following steps: If a timer event is monitored, the resource tokens corresponding to each executor in the token queue are adjusted; The adjusting of the resource tokens corresponding to the respective executors in the token queue includes: Adjust the number of resource tokens of any executor in the next adjustment period based on the number of resource tokens of any executor and the sum of the number of successful executions of all resource tokens in the current adjustment period, and the number of resource tokens of any executor and the sum of the number of successful executions of all resource tokens in the previous adjustment period; The adjusting the number of resource tokens of any executor in the next adjustment period includes: If the number of resource tokens of any executor in the current adjustment period is greater than the number of resource tokens of any executor in the previous adjustment period, and the sum of the successful execution times of all resource tokens of any executor in the current adjustment period is greater than the sum of the successful execution times of all resource tokens of any executor in the previous adjustment period, the resource tokens of any executor shall be increased.

2. The resource allocation method according to claim 1, characterized in that: The token queue is updated based on the following steps: If the executor list change event is monitored, the new version of the executor information list is obtained, and the old version of the executor information list is obtained based on the token queue; Determine available executors and resource tokens of the available executors based on the new version executor information list and the old version executor information list; The token queue is updated based on the resource tokens of the available performers.

3. The resource allocation method according to claim 1, wherein: The adjusting of the number of resource tokens of any executor in the next adjustment period based on the number of resource tokens of any executor and the sum of the number of successful executions of all resource tokens in the current adjustment period, and the number of resource tokens of any executor and the sum of the number of successful executions of all resource tokens in the previous adjustment period, includes: Determining the execution status of any executor based on the number of resource tokens of any executor in the current adjustment period and the previous adjustment period respectively; Determining a task execution amount change status of any executor based on the sum of the number of successful executions of all resource tokens of any executor in the current adjustment period and the previous adjustment period; Based on the execution status of any one of the executors and the task execution amount change status, the number of resource tokens of any one of the executors in the next adjustment period is adjusted.

4. The resource allocation method according to claim 1, wherein: The allocating a resource token to the task request based on a token queue includes: If the task request cannot be allocated a resource token, the task request is set to a waiting state.

5. The resource allocation method according to any one of claims 1 to 4, characterized in that: The information in the resource token includes at least one of connection information, total usage times, current execution times, current failure times, available information and allocation information.

6. A resource allocation device, characterized in that: include: A receiving unit, configured to receive a task request sent by a requester; an allocating unit, configured to allocate a resource token to the task request based on a token queue, and forward the task request to an executor corresponding to the resource token; The token queue is determined based on resource tokens corresponding to multiple executors, and the resource token represents the resources required by a single executor to execute a single task request; The device comprises: The second updating unit is used to: If a timer event is monitored, the resource tokens corresponding to each executor in the token queue are adjusted; The second updating unit is specifically configured to: Adjust the number of resource tokens of any executor in the next adjustment period based on the number of resource tokens of any executor and the sum of the number of successful executions of all resource tokens in the current adjustment period, and the number of resource tokens of any executor and the sum of the number of successful executions of all resource tokens in the previous adjustment period; The adjusting the number of resource tokens of any executor in the next adjustment period includes: If the number of resource tokens of any executor in the current adjustment period is greater than the number of resource tokens of any executor in the previous adjustment period, and the sum of the successful execution times of all resource tokens of any executor in the current adjustment period is greater than the sum of the successful execution times of all resource tokens of any executor in the previous adjustment period, the resource tokens of any executor shall be increased.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the steps of the resource allocation method according to any one of claims 1 to 5 are implemented.

8. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the resource allocation method according to any one of claims 1 to 5 are implemented.

Images