Task execution control method and device, and electronic device

Abstract

This application relates to the field of computer technology, specifically to a task execution control method, apparatus, and electronic device. The method determines the expected request frequency of the target node in the next cycle by acquiring the first request frequency and rate limiting status of the target node; determines the expected request frequency of the target node in the next cycle of the target cycle based on the rate limiting status and the first request frequency; determines the remaining request frequency based on the total request frequency and the request frequencies already allocated to other nodes; takes the minimum value between the remaining request frequency and the expected request frequency as the second request frequency; and allocates the second request frequency to the target node. Since the expected request frequency of the target node changes according to the rate limiting status and the first request frequency, dynamic adjustment of the request frequency of the target node is achieved, ensuring the processing efficiency of the target task.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically to a method, apparatus, and electronic device for controlling the execution of a task. Background Technology

[0002] In distributed scenarios, the same task is typically shared among multiple nodes. This usually involves breaking down a task into multiple subtasks, with each node responsible for executing one or more subtasks. During the execution of these subtasks by multiple nodes, external services need to be called to assist in their execution. However, due to the limited computing power of external services, some nodes may preemptively call external services for extended periods, resulting in fewer calls to external services for other nodes. This leads to significant differences in the completion progress of the subtasks by different nodes, ultimately resulting in a longer overall task completion time. Summary of the Invention

[0003] In view of this, embodiments of this application propose an execution control method, apparatus, and electronic device that can balance the progress of each node in executing corresponding sub-tasks and ensure the processing efficiency of the target task.

[0004] The embodiments of this application are implemented using the following technical solutions:

[0005] In a first aspect, embodiments of this application provide a task execution control method, the method comprising: obtaining a first request frequency allocated to a target node in a target period and a rate-limiting state of the target node in the target period; wherein, the target node requests to invoke an external service to execute a first subtask according to the first request frequency in the target period; the first subtask is one of a plurality of subtasks of a target task; determining an expected request frequency of the target node in the next period of the target period based on the rate-limiting state and the first request frequency; determining a remaining request frequency based on the total request frequency used by a plurality of nodes executing the target task and the request frequencies already allocated to other nodes among the plurality of nodes excluding the target node; taking the minimum value between the remaining request frequency and the expected request frequency as a second request frequency; and allocating the second request frequency to the target node so that the target node requests to invoke the external service according to the second request frequency in the next period.

[0006] Secondly, embodiments of this application provide a task execution control device, comprising: an acquisition module, configured to acquire a first request frequency allocated to a target node in a target period and a rate-limiting state of the target node in the target period; wherein the target node requests to invoke an external service according to the first request frequency in the target period to execute a first subtask; the first subtask is one of a plurality of subtasks of the target task; a first confirmation module, configured to determine the expected request frequency of the target node in the next period of the target period based on the rate-limiting state and the first request frequency; a second confirmation module, configured to determine the remaining request frequency based on the total request frequency used by a plurality of nodes executing the target task and the request frequencies already allocated to other nodes among the plurality of nodes excluding the target node; a selection module, configured to use the minimum value between the remaining request frequency and the expected request frequency as a second request frequency; and an execution module, configured to allocate the second request frequency to the target node so that the target node requests to invoke the external service according to the second request frequency in the next period.

[0007] In some implementations, the first confirmation module is specifically used to obtain the average request frequency of the plurality of nodes in the target period; if the rate limiting status indicates that the target node is rate-limited, and the first request frequency is less than the average request frequency, the average request frequency is used as the expected request frequency of the target node in the next period of the target period; if the rate limiting status indicates that the target node is rate-limited, and the first request frequency is not less than the average request frequency, the product of a first coefficient and the first request frequency is used as the expected request frequency of the target node in the next period of the target period; the first coefficient is greater than 1; if the rate limiting status indicates that the target node is not rate-limited, the product of a second coefficient and the first request frequency is used as the expected request frequency of the target node in the next period of the target period; the second coefficient ∈ (0, 1).

[0008] In some implementations, the first confirmation module is further configured to, if based on the first request frequency and the request frequency allocated to the target node in other periods prior to the target period, determine that the number of requests allocated to the target node in K consecutive periods including the target period is greater than the average request frequency of the corresponding period, use the average request frequency of multiple nodes in the target period as the expected request frequency of the target node in the next period of the target period.

[0009] In some implementations, the method is executed by the target node, and the number of requests allocated to each of the plurality of nodes in each period during the execution of the target task is recorded in the storage node; the execution module includes a request unit for sending an update request to the storage node based on the second request frequency; a receiving unit for receiving a write success message returned by the storage node, the write success message being generated after the storage node updates the request frequency stored for the target node to the second request frequency; and a response unit for updating the request frequency stored by the target node to the second request frequency in response to the write success message.

[0010] In some embodiments, the storage node further stores the latest update time of the request frequencies stored for each of the plurality of nodes; the second confirmation module includes a reading unit, configured to read from the storage node the request frequencies stored for other nodes among the plurality of nodes excluding the target node and the latest update time corresponding to each of the other nodes; a filtering unit, configured to determine invalid nodes among the other nodes among the plurality of nodes excluding the target node based on the latest update time corresponding to each of the other nodes; wherein the interval between the latest update time corresponding to the invalid node and the current time reaches a duration threshold, and the duration threshold exceeds the duration of the target period; a calculation unit, configured to add the request frequencies stored by the storage node for non-invalid nodes excluding the target node to obtain a total allocated request frequency; and to subtract the total request frequency from the total allocated request frequency to obtain the remaining request frequency.

[0011] In some implementations, the request unit is further configured to send an update request to the storage node based on the second request frequency and the node identifier of the invalid node, so that the storage node updates the request frequency stored for the target node to the second request frequency and removes the invalid node according to the update request.

[0012] In some implementations, the storage node stores a frequency allocation record for the target task. The frequency allocation record includes the request frequency allocated to each of the plurality of nodes in each period during the execution of the target task and the latest update time of the request frequency stored for the plurality of nodes. When the storage node determines that a first version number and a second version number are the same, it updates the request frequency stored for the target node in the frequency allocation record to the second request frequency and updates the version number of the frequency allocation record. The first version number is the version number of the frequency allocation record read by the storage node after receiving the update request. The second version number is the version number of the frequency allocation record when the target node last read data from the storage node.

[0013] In some implementations, the receiving unit is further configured to receive write error message returned by the storage node; wherein the storage node returns the write error message when it determines that the first version number and the second version number are different; the response unit is further configured to respond to the write error message and return to the step of reading the request frequency and the latest update time corresponding to each of the plurality of nodes other than the target node from the storage node.

[0014] In some implementations, the acquisition module is specifically used to acquire the first request frequency allocated to the target node in the target period and the rate limiting status of the target node in the target period if the first subtask has not been completed in the target period.

[0015] Thirdly, embodiments of this application provide an electronic device, including: a processor; and a memory storing computer instructions, which, when executed by the processor, implement the above-described method.

[0016] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the above-described method.

[0017] Fifthly, embodiments of this application provide a computer program product, including computer instructions that, when executed by a processor, implement the above-described method.

[0018] This application provides a task execution control method, apparatus, and electronic device. The method obtains the first request frequency allocated to a target node in a target period and the rate-limiting status of the target node in the target period. When the rate-limiting status indicates that the target node is rate-limited, it means that the first request frequency is insufficient to meet the data processing needs of the target node; when the target node is not rate-limited, it means that the first request frequency can meet or even exceed the data processing needs of the target node. Then, based on the total request frequency used by multiple nodes executing the target task and the request frequency already allocated to other nodes (excluding the target node), the remaining request frequency is determined. The minimum value between the remaining request frequency and the expected request frequency is taken as the second request frequency. Using the method provided in this application, when facing multiple sub-tasks of the target task, the expected request frequency of the target node in the next period of the target period is dynamically adjusted according to the rate-limiting status and the first request frequency, thereby achieving dynamic adjustment of the second request frequency of the target node in the next period, thus balancing the processing efficiency of multiple sub-tasks as much as possible, and ensuring the processing efficiency of the target task.

[0019] These or other aspects of this application will become more apparent in the following description of the embodiments. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A schematic diagram of an application scenario involving an embodiment of this application is shown.

[0022] Figure 2 A flowchart illustrating a task execution control method provided in an embodiment of this application is shown.

[0023] Figure 3 An embodiment of this application is shown. Figure 2 A flowchart of step S120.

[0024] Figure 4 An embodiment of this application is shown. Figure 2 A flowchart of step S130.

[0025] Figure 5 An embodiment of this application is shown. Figure 2 A flowchart of step S150.

[0026] Figure 6 A flowchart illustrating a task execution control method provided in another embodiment of this application is shown.

[0027] Figure 7 A system framework diagram relating to an embodiment of this application is shown.

[0028] Figure 8 A schematic diagram of a task execution control device provided in an embodiment of this application is shown.

[0029] Figure 9 A schematic diagram of an electronic device provided in one embodiment of this application is shown. Detailed Implementation

[0030] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0031] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without creative effort are within the scope of protection of the present application.

[0032] In the following description, the terms "first" and "second" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first" and "second" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0033] In this document, "multiple" refers to two or more. "And / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following associated objects are in an "or" relationship. In the following description, references to "some embodiments or some embodiment methods" describe a subset of all possible embodiments. However, it is understood that "some embodiments" can be the same subset or different subsets of all possible embodiments and can be combined with each other without conflict.

[0034] To facilitate understanding of this application, some terms will be explained below.

[0035] Data warehouse: A distributed database used to store data; in a data warehouse, data can be stored in shards.

[0036] Data outbound: The process of retrieving data from a data warehouse.

[0037] Computing Engine: Contains multiple computing nodes, which simultaneously read data from different shards of the data warehouse and rely on the computing power provided by external services to perform data processing or data analysis.

[0038] External services refer to services that provide unified computing capabilities (such as model services or feature services); external services provide limited computing capabilities.

[0039] Requests per Second (QPS): In this application, it can refer to the number of requests to call external services per second.

[0040] Rate limiting: If a compute node actually requests external services more times per second than the number of requests allocated to it, the number of times the compute node can call external services will be limited. This situation is called rate limiting of the compute node.

[0041] Data skew: refers to an uneven distribution of data volume, such as a large difference in the amount of data stored in different data shards in a data warehouse.

[0042] In distributed scenarios, the same task is typically shared among multiple nodes. This usually involves breaking down a task into multiple subtasks, with each node responsible for executing one or more subtasks. During the execution of these subtasks by multiple nodes, external services need to be called to assist in their execution. However, due to the limited computing power of external services, some nodes may preemptively call external services for extended periods, resulting in fewer calls to external services for other nodes. This leads to significant differences in the completion progress of the subtasks by different nodes, ultimately resulting in a longer overall task completion time.

[0043] To address the aforementioned problems, this application provides a method, apparatus, and electronic device for controlling the execution of a task.

[0044] Please see Figure 1 , Figure 1 A schematic diagram of an application scenario according to an embodiment of this application is provided, including a computing engine 10, a data warehouse 20, and an external service 30. Data transmission is performed between the computing engine 10 and the data warehouse 20 via wired or wireless means, and communication between the computing engine 10 and the external service 30 is achieved through a wired or wireless network.

[0045] The data warehouse 20 contains multiple data shards, and the computing engine 10 contains multiple computing nodes. These computing nodes can be used to execute data processing tasks. The data to be processed in the target task is located in P data shards within the data warehouse 20, where P is a positive integer greater than 1. For example, if the target task is executed by the P computing nodes in the computing engine 10, it can be divided into P subtasks. Each of the P computing nodes is responsible for one subtask, and the data to be processed in each subtask is located on a data shard within the data warehouse 20. Furthermore, each computing node needs to call an external service 30 to assist in executing its corresponding subtask.

[0046] It is worth mentioning that external service 30 is relative to computing engine 10. External service 30 refers to services provided by other devices outside of computing engine 10. External service 30 includes, for example, facial recognition service, palm print recognition service, data classification service, speech recognition service, etc., without specific limitations. There can be one or more external services 30.

[0047] Each compute node is used to read data from a data shard and call external service 30 to process the data.

[0048] To avoid excessive calls to external service 30 by the K computing nodes during the execution of the target task, which could lead to excessive computational pressure on external service 30, a total request frequency for calling external service 30 can be set for the target task in each cycle. Within each cycle, the K nodes are allocated a specific request frequency for calling external service 30 in their respective cycles. In some embodiments, the initial request frequency allocated to each of the K computing nodes in the first cycle of executing the corresponding subtask is the average request frequency.

[0049] During the execution of the target task, any one of the K computing nodes is designated as the target node. While the target node is executing the first subtask, the computing engine 10 can obtain the first request frequency allocated to the target node in the target period and the rate-limiting status of the target node in the target period. Specifically, the target node requests external service 30 to execute the first subtask according to the first request frequency in the target period. The first subtask is one of multiple subtasks of the target task. Based on the rate-limiting status and the first request frequency, the expected request frequency of the target node in the next period of the target period is determined. When the rate-limiting status indicates that the target node is rate-limited, the expected request frequency is greater than the first request frequency. When the rate-limiting status indicates that the target node is not rate-limited, the expected request frequency is less than the first request frequency. Based on the total request frequency used by the multiple nodes executing the target task and the request frequencies already allocated to the other nodes (excluding the target node), the remaining request frequency is determined. The minimum value between the remaining request frequency and the expected request frequency is taken as the second request frequency. The second request frequency is allocated to the target node so that the target node requests external service 30 according to the second request frequency in the next period.

[0050] After each computing node in computing engine 10 has completed its corresponding subtask, the target task is determined to be completed, and computing engine 10 outputs the computing results.

[0051] The embodiments provided in this application will now be described in detail with reference to the accompanying drawings.

[0052] Please see Figure 2 , Figure 2 A flowchart illustrating a task execution control method according to an embodiment of this application is provided. This task execution control method can be executed by a target node or by a storage node that manages multiple nodes. The storage node can be one of the multiple nodes used to execute the target task, or it can refer to other nodes besides those executing the target task. Figure 2 As shown, the method includes steps S110-S150:

[0053] S110. Obtain the first request frequency allocated to the target node in the target period and the rate limiting status of the target node in the target period; wherein, the target node requests to call an external service in accordance with the first request frequency in the target period to execute the first subtask; the first subtask is one of the multiple subtasks of the target task.

[0054] Here, "target node" refers to any one of multiple nodes used to jointly execute a target task. The target task can be any data processing task that requires calling external services. External services refer to services provided by other devices outside the multiple nodes. As described above, external services can be face recognition services, palmprint recognition services, data classification services, speech recognition services, speech noise reduction services, feature calculation services, etc., and the type of external service is not limited.

[0055] Furthermore, the external service to be called to achieve the target task can be one or more. If there are multiple external services required to achieve the target task, the request frequency for guiding the call to the external service can be allocated to each node in each cycle of the target task execution in accordance with the method of this application.

[0056] In this application, the target task is divided into multiple subtasks, and a computing node is responsible for executing one or more subtasks. In some embodiments, the target task can be divided according to the data type of the data that the target task needs to process, resulting in multiple subtasks. Each subtask corresponds to processing a data type, and different subtasks need to process different data types. In other embodiments, if the data that the target task needs to process is stored in shards, the target task can also be divided according to the data shards where the data that the target task needs to process is located, resulting in multiple subtasks. The data that different subtasks need to process is located in different data shards.

[0057] In some embodiments, the data to be processed by the target task can be evenly distributed to each node according to the total amount of data to be processed by the target task and the total number of nodes allocated to the target task. The task of processing the allocated data by a node corresponds to a subtask.

[0058] In some implementations, the data that the target task needs to process can be stored in multiple data shards of the data warehouse; the data that different subtasks need to process are located in different data shards; obviously, the target task can only be determined to have been completed when all subtasks have been executed.

[0059] The target period refers to the period that has just ended. The request frequency allocated to a node within a period can be the total number of requests allowed for that node within that period, or the number of requests allowed for that node per unit of time within that period, such as the number of requests allowed per second. In this application, each node needs to call external services to execute its corresponding subtasks, and the request frequency allocated to a node within a period is used to limit the frequency at which that node calls external services within a period.

[0060] In some implementations, if the target period is the first period for executing the target task, the first request frequency allocated to the target node in the target period can be the average request frequency; wherein, the average request frequency is obtained by distributing the total request frequency set for the target task evenly to each node.

[0061] The total request frequency set for the target task should not exceed the maximum request frequency that the external service can provide. For example, it can be determined by both the amount of data the target task needs to process and the maximum request frequency that the external service can provide. For instance, multiple data volume ranges can be pre-set, each corresponding to a scaling factor. The scaling factor is a number greater than 0 and not greater than 1. The data volume range corresponding to the target task is determined based on the amount of data the target task needs to process, and the product of the scaling factor corresponding to the data volume range and the maximum request frequency that the external service can provide is used as the total request frequency set for the target task.

[0062] Rate limiting status indicates whether a node is being rate-limited. Specifically, when a node's actual frequency of requesting external services in a given period exceeds the request frequency allocated to the node within that period, the node's external service calls will be restricted. Since nodes rely on external services to execute corresponding subtasks, when a node's external service calls are restricted, its computation is also restricted; that is, the node is rate-limited. For example, for a target node, if the request frequency for calling external services allocated to the target node in the target period is the second request frequency, theoretically, the target node's request frequency for calling external services in the target period is limited to not exceeding the second request frequency. However, if the target node's request frequency for calling external services in the target period exceeds the second request frequency, the target node will be rate-limited in the target period to reduce the frequency of the target node continuing to call external services in the target period.

[0063] Therefore, as can be seen from the above, the request frequency allocated to a node for calling external services in a cycle is used to limit the request frequency of the node for calling external services in the corresponding cycle, or in other words, it is used as a reference for whether to rate limit the node.

[0064] Since multiple nodes need to call external services during the execution of subtasks, and the computing power of external services is limited, some nodes may preemptively call external services for a long time, resulting in fewer calls to external services for other nodes. This leads to significant differences in the completion progress of the corresponding subtasks by different nodes, thus making the overall task take longer to complete. Therefore, it is necessary to allocate request frequencies to each node to avoid unreasonable preemption of external services by each node.

[0065] In some implementations, step S110 may specifically include:

[0066] If the first subtask is not completed within the target period, obtain the first request frequency allocated to the target node in the target period and the rate limiting status of the target node in the target period.

[0067] It is understandable that if the first subtask is not completed in the target period, it means that the target node will continue to execute the first subtask in the next period of the target period. Therefore, the second request frequency of the target node in the next period can be calculated by obtaining the first request frequency allocated to the target node in the target period and the rate limiting status of the target node in the target period, as well as subsequent steps.

[0068] If the first subtask is completed within the target period, it means that the target node's computation task has been completed. In the next period of the target period, the target node will exit the target task. Therefore, it is not necessary to calculate the second request frequency of the target node in the next period.

[0069] S120. Based on the rate limiting status and the first request frequency, determine the expected request frequency of the target node in the next cycle of the target cycle.

[0070] Specifically, when the rate limiting status indicates that the target node is rate-limited, the expected request frequency is greater than the first request frequency; when the rate limiting status indicates that the target node is not rate-limited, the expected request frequency is less than the first request frequency.

[0071] The expected request frequency of the target node in the next cycle of the target cycle refers to the frequency of requests that the target node expects to be allocated in order to execute the first subtask in the next cycle of the target cycle.

[0072] It is understandable that when the rate limiting status indicates that the target node is being rate-limited, it means that the first request frequency of the target node cannot meet the data processing needs of the target node. Therefore, the request frequency of the target node in the next period of the target period can be appropriately increased. For example, it can be appropriately increased based on the first request frequency, and the increased request frequency can be used as the expected request frequency of the target node in the next period of the target period.

[0073] In some embodiments, a single increment can be preset, and the first request frequency can be added to the single increment to obtain the expected request frequency of the target node in the next cycle of the target cycle.

[0074] In some embodiments, the correspondence between request frequency intervals and request frequency increments can be preset. Then, the request frequency interval in which the first request frequency is located can be determined, and the request frequency increment corresponding to the request frequency interval in which the first request frequency is located can be added to the first request frequency to obtain the expected request frequency of the target node in the next cycle of the target cycle.

[0075] In some implementations, the increase in the expected request frequency relative to the first request frequency can be determined based on the difference between the first request frequency and the average request frequency corresponding to the target period. For example, if the difference between the first request frequency and the average request frequency is negative, the increase in the expected request frequency relative to the first request frequency can be proportional to the absolute value of the difference, that is, the larger the absolute value of the difference, the greater the increase in the expected request frequency relative to the first request frequency; if the difference between the first request frequency and the average request frequency is positive, the increase in the expected request frequency relative to the first request frequency can be inversely proportional to the difference, that is, the larger the difference, the smaller the increase in the expected request frequency relative to the first request frequency.

[0076] Similarly, if the rate limiting status indicates that the target node is not rate-limited, it means that the target node's first request frequency can meet or even exceed its data processing needs. Therefore, the target node's request frequency in the next cycle of the target cycle can be appropriately reduced. This reduction can be based on the first request frequency, and the reduced request frequency can be used as the target node's expected request frequency in the next cycle of the target cycle. This is equivalent to releasing some request frequency for other nodes executing the target task.

[0077] In some embodiments, a single reduction amount can be preset, and the first request frequency can be subtracted from the single reduction amount to obtain the expected request frequency of the target node in the next cycle of the target cycle.

[0078] In some embodiments, a correspondence between request frequency intervals and request frequency reduction amounts can be preset. Then, the request frequency interval in which the first request frequency is located can be determined, and the request frequency reduction amount corresponding to the request frequency interval in which the first request frequency is located can be subtracted from the first request frequency to obtain the expected request frequency of the target node in the next cycle of the target cycle.

[0079] In some implementations, the expected reduction in the request frequency relative to the first request frequency can be determined based on the difference between the first request frequency and the average request frequency corresponding to the target period. For example, if the difference between the first request frequency and the average request frequency is negative, the increase in the expected request frequency relative to the first request frequency can be inversely proportional to the absolute value of the difference, that is, the larger the absolute value of the difference, the smaller the decrease in the expected request frequency relative to the first request frequency. If the difference between the first request frequency and the average request frequency is positive, the decrease in the expected request frequency relative to the first request frequency can be directly proportional to the difference, that is, the larger the difference, the larger the decrease in the expected request frequency relative to the first request frequency.

[0080] It is worth mentioning that since the total number of requests that multiple nodes executing the target task can make to call external services is fixed, when all the total request frequency is distributed among the nodes, if a node wants to increase the request frequency, it must rely on other nodes to release the request frequency.

[0081] In some implementations, please refer to Figure 3 , Figure 3 The embodiments provided in this application are given Figure 2 A flowchart of step S120 is provided. Step S120 includes steps S121-S124:

[0082] S121. Obtain the average request frequency of multiple nodes in the target period.

[0083] The average request frequency can be obtained by dividing the total number of requests made by multiple nodes to call external services when executing the target task by the number of nodes.

[0084] Considering that when the target task is executed to the target period, some nodes may have completed the corresponding sub-tasks, or some nodes may exit the execution of the target task due to failure, the nodes that have completed the corresponding sub-tasks or the nodes that have exited the execution of the target task due to failure are called invalid nodes, and the other nodes that continue to execute the corresponding sub-tasks are called valid nodes. The average request frequency in step S121 is obtained by dividing the total request frequency by the number of valid nodes in the target period.

[0085] S122. If the rate limiting status indicates that the target node is rate-limited, and the first request frequency is less than the average request frequency, the average request frequency shall be taken as the expected request frequency of the target node in the next period of the target period.

[0086] Obviously, if the first request frequency of the target node is less than the average request frequency, using the average request frequency as the expected request frequency of the target node in the next period of the target period can ensure that the expected request frequency of the target node is greater than the first request frequency, without occupying too much request frequency and affecting the request frequency of other nodes.

[0087] S123. If the rate limiting status indicates that the target node is rate-limited, and the first request frequency is not less than the average request frequency, the product of the first coefficient and the first request frequency shall be used as the expected request frequency of the target node in the next period of the target period; the first coefficient is greater than 1.

[0088] When the frequency of the first request is not less than the frequency of the average request, the expected frequency of the request is determined by multiplying the first coefficient by the frequency of the first request. This ensures that the expected frequency of the request is greater than the frequency of the first request and also keeps the rate of change of the expected frequency of the request relative to the frequency of the first request stable. This achieves a gradual increase in the expected frequency of the request and avoids drastic fluctuations in the data traffic of each computing node caused by drastic fluctuations in the frequency of the request.

[0089] S124. If the rate limiting status indicates that the target node is not rate-limited, the product of the second coefficient and the first request frequency is taken as the expected request frequency of the target node in the next period of the target period; the second coefficient ∈ (0, 1).

[0090] When the target node is not subject to rate limiting, the expected request frequency is determined by multiplying the second coefficient by the first request frequency. This ensures that the expected request frequency is less than the first request frequency and keeps the rate of change of the expected request frequency relative to the first request frequency stable. This achieves a gradual reduction in the expected request frequency and avoids drastic fluctuations in data traffic of each computing node caused by drastic fluctuations in request frequency.

[0091] In the above embodiment, the average request frequency of the target period is used as a reference. The expected request frequency of the target node in the next period is determined by combining the first request frequency allocated to the target node in the target period and the rate limiting status of the target node in the target period. This ensures that the determined expected request frequency fluctuates around the average request frequency of the target period and the difference between it and the average request frequency of the target period is not too large. In this way, the actual processing needs of the target node are taken into account, and excessive request frequency is avoided.

[0092] S130. Determine the remaining request frequency based on the total request frequency used by multiple nodes for executing the target task and the request frequency already allocated to other nodes among the multiple nodes besides the target node.

[0093] Specifically, the remaining request frequency can be obtained by subtracting the request frequency already allocated to other nodes from the total request frequency.

[0094] In some implementations, invalid nodes among the other nodes, that is, nodes that have gone offline or have exited the execution of the target task, can be identified first. Then, the total request frequency is subtracted from the request frequency already allocated to the non-invalid nodes among the other nodes to obtain the remaining request frequency. Obviously, for invalid nodes, since they have gone offline or have exited the execution of the target task, the request frequency they were allocated can be used to allocate to other nodes so that other nodes can be allocated a larger request frequency.

[0095] S140. The minimum value between the remaining request frequency and the expected request frequency shall be used as the second request frequency.

[0096] Since the remaining request frequency is the maximum request frequency that can be allocated to the target node in the next period of the target period, even if the expected request frequency is greater than the remaining request frequency, the remaining request frequency can only be used as the second request frequency; while if the expected request frequency is not greater than the remaining request frequency, the expected request frequency can be used as the second request frequency.

[0097] In some implementations, prior to step S140, the task execution control method further includes:

[0098] If, based on the first request frequency and the request frequency allocated to the target node in other periods before the target period, it is determined that the number of requests allocated to the target node in K consecutive periods including the target period is greater than the average request frequency of the corresponding period, the average request frequency of multiple nodes in the target period is taken as the expected request frequency of the target node in the next period of the target period.

[0099] It is understandable that if the number of requests allocated to the target node in K consecutive periods is greater than the average request frequency of the corresponding period, it means that the target node has been allocated a large number of requests for a long time, while other nodes can only be allocated a small number of requests. This can easily lead to a large difference in computing speed between the target node and other nodes, resulting in an imbalance in processing efficiency among multiple subtasks and a reduction in the overall processing efficiency of the target task.

[0100] S150. Assign a second request frequency to the target node so that the target node will request to call external services according to the second request frequency in the next cycle.

[0101] In some embodiments, if the method of this application is executed by the target node, the target node can update its own stored request frequency to the second request frequency and send a request frequency update notification to the storage node, so that the storage node knows that the target node has updated its own request frequency. The target node updating its own stored request frequency to the second request frequency is considered a successful allocation of the second request frequency.

[0102] In some embodiments, if the method of this application is executed by a storage node, the target node can send an update request to the storage node based on the second request frequency. In response to the update request, the storage node updates the request frequency stored for the target node to the second request frequency and returns a write success message to the target node. The storage node returning a write success message to the target node is considered as having allocated the second request frequency to the target node.

[0103] The method provided in this application obtains the first request frequency allocated to the target node in the target period and the rate-limiting status of the target node in the target period. Since the higher the request frequency of the target node, the more times the target node is allowed to call external services in a period, and the more data the target node can process in a period, when the rate-limiting status indicates that the target node is rate-limited, it means that the first request frequency is insufficient to meet the data processing needs of the target node. Therefore, it is desirable to obtain a higher expected request frequency to improve the processing efficiency of the target node. When the target node is not rate-limited, it means that the first request frequency can meet or even exceed the data processing needs of the target node. Therefore, a lower expected request frequency can be obtained to release more request frequency to other nodes. Next, based on the total request frequency used by multiple nodes executing the target task and the request frequency already allocated to other nodes besides the target node, the remaining request frequency is determined. The minimum of the remaining request frequency and the expected request frequency is taken as the second request frequency. Obviously, the remaining request frequency is also the maximum request frequency that can be allocated to the target node at present. Therefore, even if the expected request frequency is greater than the remaining request frequency, the remaining request frequency can only be used as the second request frequency. Finally, the second request frequency is allocated to the target node so that the target node can request external services according to the second request frequency in the next cycle. When executing multiple subtasks of the target task, the target node that is not rate-limited will request a smaller request frequency to release the request frequency, while the target node that is rate-limited will request a larger request frequency to improve processing efficiency. This realizes the dynamic adjustment of the request frequency of the target node, thereby balancing the processing efficiency of multiple subtasks as much as possible, and thus ensuring the processing efficiency of the target task.

[0104] In some implementations, the number of requests allocated to each of the multiple nodes in each cycle during the execution of the target task is recorded in the storage node, which also stores the latest update time of the request frequency stored for each of the multiple nodes; see [link to relevant documentation]. Figure 4 , Figure 4 The embodiments provided in this application Figure 2 A flowchart of step S130 is provided, which includes steps S210-S240:

[0105] S210. Read from the storage node the request frequency and the latest update time of each of the other nodes (excluding the target node) stored on the other nodes.

[0106] In some implementations, the request frequency and latest update time of each node in the storage node can be stored in a key-value pair manner, where the key represents the node and the value includes the request frequency and the latest update time.

[0107] In some embodiments, the storage node stores a frequency allocation record for the target task. The frequency allocation record includes the request frequency allocated to each of the multiple nodes in each period during the execution of the target task and the latest update time of the request frequency stored for the multiple nodes. Therefore, the target node can request the storage node to store the request frequency and the latest update time corresponding to each of the other nodes in the frequency allocation record of the target task.

[0108] S220. Based on the latest update time of each other node, determine the invalid node among the other nodes besides the target node; wherein, the interval between the latest update time of the invalid node and the current time reaches the duration threshold, and the duration threshold exceeds the duration of the target period.

[0109] As can be seen from the relevant descriptions in the foregoing embodiments, regardless of whether a node is rate-limited, it will request to update the request frequency for the next cycle after the end of one cycle. If a node does not request to update the request frequency within one cycle, it can be considered that the node has exited the execution of the target task or has gone offline.

[0110] Obviously, since the duration threshold exceeds the target period, if the interval between the latest update time of a node and the current time reaches the duration threshold, it can be considered that the node has exited the execution of the target task or has gone offline, and the node is identified as an invalid node.

[0111] S230. Add up the request frequencies for storage nodes that are non-invalid nodes other than the target node to get the total allocated request frequencies.

[0112] Non-invalid nodes refer to the nodes other than invalid nodes among multiple nodes.

[0113] Understandably, the storage nodes also record the request frequency allocated during the last update of the invalid node. Obviously, this request frequency can be used to allocate to other nodes. Therefore, the total allocated request frequency is actually the sum of the request frequencies stored on non-invalid nodes excluding the target node.

[0114] S240. Subtract the total request frequency from the total allocated request frequency to obtain the remaining request frequency.

[0115] The method provided in this application determines whether a node is valid by using the latest update time of the request frequency recorded in the storage node. When calculating the total allocated request frequency, the request frequency allocated to invalid nodes is removed, and the request frequency previously allocated to invalid nodes can be released for use by other nodes that need to continue executing the target task, thereby avoiding the waste of request frequency and improving the overall utilization rate of request frequency.

[0116] In some implementations, the task execution control method can be specifically executed by the target node; please refer to [link / reference]. Figure 5 , Figure 5 The embodiments provided in this application are given Figure 2 A flowchart of step S150 is provided, which includes steps S310-S330:

[0117] S310. Based on the second request frequency, send an update request to the storage node.

[0118] In response to an update request, the storage node updates the request frequency of the target node to the second request frequency; in addition, the storage node also updates the latest update time of the target node.

[0119] It should be noted that in this case, the target node is considered to have been allocated the corresponding request frequency only after the storage node updates the request frequency stored in the target node to the second request frequency according to the update request.

[0120] In some implementations, step S310 may specifically include:

[0121] Based on the second request frequency and the node identifier of the invalid node, an update request is sent to the storage node so that the storage node updates the request frequency stored for the target node to the second request frequency and removes the invalid node.

[0122] Through the above implementation method, invalid nodes can be removed from the storage nodes in a timely manner, avoiding repeated reading of invalid nodes for redundant calculations when the frequency of requests for storage of each node is reduced. This saves storage space of the storage nodes and improves the processing efficiency of the entire process.

[0123] S320. Receive a write success message returned by the storage node. The write success message is generated after the storage node updates the request frequency for storing data for the target node to the second request frequency.

[0124] In some implementations, if the storage node fails to update the request frequency stored for the target node to the second request frequency according to the update request, it returns a write failure message; obviously, in the case of a write failure, the request frequency of the target node will not be updated.

[0125] S330. In response to the successful write message, update the request frequency stored on the target node to the second request frequency.

[0126] Through the above implementation method, after the storage node updates the request frequency stored for the target node to the second request frequency, the storage node generates a write success prompt message and returns it. The storage node manages the request frequency management of multiple nodes executing the target task. Moreover, the storage node stores a request frequency for each node, which means that the request frequency of a node read from the storage node each time is the latest request frequency allocated to that node, ensuring the accuracy of the determined remaining request frequency, and thus ensuring the accuracy of the second request frequency determined for the node. Furthermore, through the storage node, it is possible to ensure the orderly update of the request frequency allocated to multiple nodes in the case of multiple nodes.

[0127] In some implementations, please refer to Figure 6 , Figure 6 A flowchart of a task execution control method provided in another embodiment of this application is given. The storage node stores a frequency allocation record for the target task. The frequency allocation record includes the request frequency allocated to each of the multiple nodes in each period during the execution of the target task and the latest update time of the request frequency stored for the multiple nodes. After step S310, the task execution control method further includes step S410.

[0128] S410. Receive write error message returned by the storage node; wherein, the storage node returns write error message when it determines that the first version number and the second version number are different.

[0129] In response to a write exception message, return to the steps of reading the request frequency and the latest update time of each of the other nodes (excluding the target node) from the storage node.

[0130] The first version number is the version number of the frequency allocation record read by the storage node after receiving the update request; the second version number is the version number of the frequency allocation record when the target node last read data from the storage node.

[0131] The method provided by the above implementation ensures that the second request frequency for updating the target node is determined based on the latest request frequencies allocated to other nodes besides the target node, thereby ensuring the accuracy of the second request frequency for updating the target node.

[0132] It's worth noting that since the target node is any one of multiple nodes executing the target task, meaning that all nodes executing the target task will send update requests to the storage node through the above steps to update their assigned request frequencies; for the target node, if the version number of the frequency allocation record is inconsistent with the version number of the frequency allocation record read by the storage node when it reads the request frequencies stored by other nodes and the latest update time corresponding to each other node from the storage node, it indicates that the target node's reading of the request frequencies stored by other nodes and the latest update time corresponding to each other node from the storage node is inconsistent. If, between the latest update time and the time the storage node receives the update request from the target node, other nodes have already requested the storage node to update the request frequency and completed the update, then for the target node, the remaining request frequency required to determine the second request frequency has changed, and the second request frequency in the update request needs to change accordingly. Therefore, to ensure the accuracy of the data stored in the storage node, if the version number of the frequency allocation record read after receiving the update request is different from the version number of the frequency allocation record when the target node last read data from the storage node, the storage node will not write the data.

[0133] For example, suppose there are three target nodes that send three update requests in sequence: Request 1 from target node 1, Request 2 from target node 2, and Request 3 from target node 3. If the storage node responds to the first request 1 and updates the request frequency of target node 1 from 5 to 10, then obviously, after the storage node updates the request frequency of target node 1, the actual remaining request frequency required for target nodes 2 and 3 during their calculations will change. The second request frequency in Request 2 and Request 3 is related to the remaining request frequency, meaning that the second request frequency in Request 2 and Request 3 may not match the actual frequency. If writing continues based on Request 2 and Request 3, the sum of the request frequencies allocated to the three target nodes may exceed the total request frequency, which is obviously unreasonable. Therefore, the storage node will not continue to respond to Request 2 and Request 3 for writing.

[0134] In some implementations, in order to implement the above-described update request response process, the storage node stores a frequency allocation record for the target task. The frequency allocation record includes the request frequency allocated to each of the multiple nodes in each period during the execution of the target task and the latest update time of the request frequency stored for the multiple nodes.

[0135] When a storage node determines that the first version number and the second version number are the same, it updates the request frequency stored for the target node in the frequency allocation record to the second request frequency and updates the version number of the frequency allocation record.

[0136] Among them, the number of times the target node recently read from the storage node is the frequency of requests made by the target node to read from the storage node for storage on other nodes among multiple nodes other than the target node, and the latest update time of each of the other nodes.

[0137] Clearly, after receiving the update request, the version number of the frequency allocation record (i.e., the first version number) read is the same as the version number of the frequency allocation record when the target node last read data from the storage node (i.e., the second version number). This means that during the time period from the target node's last reading data from the storage node to the storage node receiving the update request, the frequency allocation record stored in the storage node for the target task was not updated. At this time, the second request frequency requested by the update request is accurate. Therefore, the request frequency stored in the frequency allocation record for the target node can be updated to the second request frequency, and the version number of the frequency allocation record can be updated.

[0138] If the version number of the frequency allocation record read after receiving the update request is different from the version number of the frequency allocation record when the target node last read data from the storage node, it means that the frequency allocation record stored in the storage node for the target task has been updated within the time period from the last time the target node read data from the storage node to the time the storage node receives the update request. At this time, the second request frequency requested by the update request is inaccurate. In this case, a write exception prompt message can be generated.

[0139] In other implementations, storage nodes can use CAS (Compare and Swap) for data writing. For example, key-value pairs in a storage node can be constructed as follows: the key includes a version number and a node, and the value includes the request frequency and the latest update time. When data on any node in the storage node is updated, the version numbers in all keys are updated synchronously. When a target node reads the request frequency of other nodes, it can synchronously read the version number (i.e., the second version number) in the corresponding key. Then, when sending an update request to the storage node, the update request can include the second request frequency and the read first version number. Upon receiving the update request, the storage node reads the version number (i.e., the first version number) from the stored key and compares it with the second version number in the update request. If the second version number is the same as the first version number, the request frequency stored for the target node is updated to the second request frequency, and a write success message is generated. If the second version number is different from the first version number, a write failure message is generated.

[0140] For easier understanding, please refer to Figure 7 , Figure 7 A system framework diagram of the task execution control method provided in the embodiments of this application is given, including a data warehouse, a computing engine, external services, and storage nodes.

[0141] Multiple computing nodes in the computing engine read the data required for the target task from the data warehouse shards for processing and request external services (including model services and feature services) to assist in data processing. After all the computing nodes have completed their corresponding sub-tasks, the computing results are output. The request frequency allocated to each computing node is stored in the storage node. When a computing node wants to update the request frequency, it needs to send an update request to the storage node first, so that the storage node can write the new request frequency according to the update request.

[0142] Taking a computing engine consisting of four computing nodes (Computing Node 1 to Computing Node 4) as an example, the four computing nodes read data from four shards of the data warehouse. Assuming that the external service provides a total of 4,000 requests per second for the target task, the average request frequency per second for each computing node is 1,000. Assuming that each computing node calls an external request to process one piece of data, if the target task has 100,000 pieces of data to be computed, in the most ideal case, the 100,000 pieces of data are evenly distributed in the four shards, that is, each shard contains 25,000 pieces of data, then it will take 25 seconds to complete the target task. However, if the 100,000 data entries are unevenly distributed across the four shards, i.e., there is data skew, for example, shard 1 has 10,000 entries, shard 2 has 10,000 entries, shard 3 has 10,000 entries, and shard 4 has 70,000 entries, and if the request frequency of each computing node is set to the average request frequency as in related technologies, it will take 70 seconds (i.e., the time it takes for computing node 4 to complete the corresponding subtask of shard 4, while the other three shards take much less time to complete the target task due to the smaller amount of data) to complete the target task.

[0143] Using the method provided in this application, assuming the first coefficient is 2 and the second coefficient is 0.9, the first request frequency of each computing node in the first computing cycle is the average request frequency (i.e., 1000). If computing nodes 1, 2, and 3 are not rate-limited in the first computing cycle, and computing node 4 is rate-limited, then the expected request frequency of computing nodes 1, 2, and 3 is 900 (1000*0.9), which is less than the first request frequency, and the expected request frequency of computing node 4 is 2000 (1000*2), which is greater than the first request frequency.

[0144] Assume the storage node first updates the request frequency of compute node 1 for the next cycle based on the update request. At this time, the remaining request frequency for compute node 1 is 1000 (4000-3000), and the expected request frequency is 900. Therefore, the second request frequency for compute node 1 in the next cycle is 900. Then, compute node 2 is updated, and its remaining request frequency is 1100 (4000-2900), with an expected request frequency of 900. Therefore, the second request frequency for compute node 1 in the next cycle is 900. The second request frequency is also 900; similarly, update compute node 3, the remaining request frequency of compute node 3 is 1200 (4000-2800), the expected request frequency is 900, so the second request frequency of compute node 3 in the next cycle is also 900; finally, for compute node 4, the remaining request frequency of compute node 4 at this time is 1300 (4000-2700), the expected request frequency is 2000, so the second request frequency of compute node 4 in the next cycle is 1300.

[0145] Obviously, for the rate-limited computing node 4, its second request frequency increases in the next cycle, and the processing efficiency of the corresponding subtask improves. For the unrate-limited computing nodes 1, 2 and 3, their second request frequency decreases in the next cycle, and the processing efficiency of the corresponding subtask decreases. This keeps the processing efficiency of multiple subtasks as balanced as possible. Obviously, with the method provided in this application, the final time consumed by the target task will be much less than the time spent executing the target task in the prior art by distributing the request frequency equally.

[0146] Furthermore, since the first coefficient is 2 and the second coefficient is 0.9, when the expected request frequency needs to be greater than the first request frequency, the expected request frequency is twice the first request frequency, which achieves a rapid increase in the expected request frequency and effectively copes with the traffic increase caused by rate limiting. When the expected request frequency needs to be less than the first request frequency, the expected request frequency is only adjusted downward by 10% relative to the first request frequency each time, which is a slow downward adjustment. This effectively prevents the second request frequency allocated to the target node from being insufficient in the next cycle of the target cycle, which would cause the traffic to rise rapidly in the next cycle, resulting in a sawtooth jitter in the traffic and causing violent traffic fluctuations.

[0147] In some implementations, please refer to Figure 8 , Figure 8 A schematic diagram of a task execution control device provided in an embodiment of this application is given. The task execution control device 600 includes:

[0148] The acquisition module 610 is used to acquire the first request frequency allocated to the target node in the target period and the rate limiting status of the target node in the target period; wherein, the target node requests to call an external service in the target period according to the first request frequency to execute the first subtask; the first subtask is one of the multiple subtasks of the target task.

[0149] The first confirmation module 620 is used to determine the expected request frequency of the target node in the next cycle of the target cycle based on the rate limiting status and the first request frequency.

[0150] The second confirmation module 630 is used to determine the remaining request frequency based on the total request frequency used by the multiple nodes for executing the target task and the request frequency already allocated to the other nodes among the multiple nodes excluding the target node.

[0151] Module 640 is selected to use the minimum of the remaining request frequency and the expected request frequency as the second request frequency.

[0152] The execution module 650 is used to allocate a second request frequency to the target node so that the target node will request to call external services according to the second request frequency in the next cycle.

[0153] In some implementations, the first confirmation module 620 is specifically used to obtain the average request frequency of multiple nodes in the target period; if the rate limiting status indicates that the target node is rate-limited, and the first request frequency is less than the average request frequency, the average request frequency is used as the expected request frequency of the target node in the next period of the target period; if the rate limiting status indicates that the target node is rate-limited, and the first request frequency is not less than the average request frequency, the product of the first coefficient and the first request frequency is used as the expected request frequency of the target node in the next period of the target period; the first coefficient is greater than 1; if the rate limiting status indicates that the target node is not rate-limited, the product of the second coefficient and the first request frequency is used as the expected request frequency of the target node in the next period of the target period; the second coefficient ∈ (0, 1).

[0154] In some implementations, the first confirmation module 620 is further configured to, if based on the first request frequency and the request frequency allocated to the target node in other periods before the target period, determine that the number of requests allocated to the target node in K consecutive periods including the target period is greater than the average request frequency of the corresponding period, use the average request frequency of multiple nodes in the target period as the expected request frequency of the target node in the next period of the target period.

[0155] In some implementations, the task execution control method is executed by the target node, and the number of requests allocated to each of the multiple nodes in each cycle during the execution of the target task is recorded in the storage node; the execution module 650 includes a request unit for sending an update request to the storage node based on a second request frequency; a receiving unit for receiving a write success message returned by the storage node, which is generated after the storage node updates the request frequency stored for the target node to the second request frequency; and a response unit for updating the request frequency stored in the target node to the second request frequency in response to the write success message.

[0156] In some implementations, the storage node also stores the latest update time of the request frequency stored for each of the multiple nodes; the second confirmation module 630 includes a reading unit for reading from the storage node the request frequency stored for other nodes besides the target node and the latest update time corresponding to each other node; a filtering unit for determining invalid nodes among the other nodes besides the target node based on the latest update time corresponding to each other node; wherein the interval between the latest update time corresponding to the invalid node and the current time reaches a duration threshold, and the duration threshold exceeds the duration of the target period; a calculation unit for adding the request frequencies stored by the storage node for non-invalid nodes besides the target node to obtain the total allocated request frequency; and subtracting the total request frequency from the total allocated request frequency to obtain the remaining request frequency.

[0157] In some implementations, the request unit is further configured to send an update request to the storage node based on the second request frequency and the node identifier of the invalid node, so that the storage node updates the request frequency stored for the target node to the second request frequency and removes the invalid node according to the update request.

[0158] In some implementations, the storage node stores a frequency allocation record for the target task. The frequency allocation record includes the request frequency allocated to each of the multiple nodes in each period during the execution of the target task and the latest update time of the request frequency stored for the multiple nodes. When the storage node determines that the version number of the frequency allocation record read after receiving an update request is the same as the version number of the frequency allocation record when the target node last read data from the storage node, it updates the request frequency stored for the target node in the frequency allocation record to the second request frequency and updates the version number of the frequency allocation record.

[0159] In some implementations, the receiving unit is further configured to receive write error message returned by the storage node; wherein, when the storage node determines that the version number of the frequency allocation record read after receiving the update request is different from the version number of the frequency allocation record when the target node last read data from the storage node, it returns the write error message; the response unit is further configured to respond to the write error message and return to the step of reading the request frequency stored for the other nodes among the multiple nodes excluding the target node and the latest update time corresponding to each of the other nodes from the storage node.

[0160] In some implementations, the acquisition module 610 is specifically used to acquire the first request frequency allocated to the target node in the target period and the rate limiting status of the target node in the target period if the first subtask has not been completed in the target period.

[0161] Figure 9 A schematic diagram of a computer system suitable for implementing an electronic device according to embodiments of this application is shown. This electronic device can be the terminal described above, used to implement the text generation control method provided in this application. It should be noted that... Figure 9 The computer system 1300 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0162] like Figure 9As shown, the computer system 1300 includes a Central Processing Unit (CPU) 1301, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on programs stored in Read-Only Memory (ROM) 1302 or programs loaded from storage portion 1308 into Random Access Memory (RAM) 1303. The RAM 1303 also stores various programs and data required for system operation. The CPU 1301, ROM 1302, and RAM 1303 are interconnected via a bus 1304. An Input / Output (I / O) interface 1305 is also connected to the bus 1304.

[0163] The following components are connected to I / O interface 1305: an input section 1306 including a keyboard, mouse, microphone, etc.; an output section 1307 including a cathode ray tube (CRT), liquid crystal display (LCD), and speakers, etc.; a storage section 1308 including a hard disk, etc.; and a communication section 1309 including a network interface card such as a LAN (Local Area Network) card and a modem, etc. The communication section 1309 performs communication processing via a network such as the Internet. A drive 1310 is also connected to I / O interface 1305 as needed. Removable media 1311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1310 as needed so that computer instructions read from them can be loaded into storage section 1308 as needed.

[0164] In particular, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising computer instructions. When these computer instructions are executed by the central processing unit (CPU) 1301, various functions defined in the system of this application are performed.

[0165] This application also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the methods described in any of the above method embodiments.

[0166] It should be noted that the computer-readable storage medium shown in the embodiments of this application can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable storage medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable storage medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0167] In the embodiments of this application, the terms "module" or "unit" refer to computer instructions or a portion of computer instructions that have a predetermined function and work together with other related parts to achieve a predetermined goal. These instructions can be implemented, wholly or partially, using software, hardware (e.g., processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that functions as a whole.

[0168] The above are merely preferred embodiments of this application and are not intended to limit this application in any way. Although this application has disclosed preferred embodiments as above, it is not intended to limit this application. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the technical solution of this application. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of this application without departing from the scope of the technical solution of this application shall still fall within the scope of the technical solution of this application.

Claims

1. A method for controlling the execution of a task, characterized in that, include: The first request frequency allocated to the target node in the target period and the rate limiting status of the target node in the target period are obtained; wherein, the target node requests to call an external service in the target period according to the first request frequency to execute a first subtask; the first subtask is one of a plurality of subtasks of the target task; Based on the rate limiting status and the first request frequency, determine the expected request frequency of the target node in the next cycle of the target cycle; The remaining request frequency is determined based on the total request frequency used by the multiple nodes for executing the target task and the request frequency already allocated to the other nodes among the multiple nodes excluding the target node; The minimum value between the remaining request frequency and the expected request frequency is taken as the second request frequency; The target node is assigned the second request frequency so that the target node requests and invokes the external service according to the second request frequency in the next cycle.

2. The method according to claim 1, characterized in that, The step of determining the expected request frequency of the target node in the next period of the target period based on the rate limiting status and the first request frequency includes: Obtain the average request frequency of the multiple nodes during the target period; If the rate limiting status indicates that the target node is rate-limited, and the first request frequency is less than the average request frequency, the average request frequency is taken as the expected request frequency of the target node in the next period of the target period. If the rate limiting status indicates that the target node is rate-limited, and the first request frequency is not less than the average request frequency, the product of the first coefficient and the first request frequency is taken as the expected request frequency of the target node in the next period of the target period; the first coefficient is greater than 1. If the rate limiting status indicates that the target node is not rate-limited, the product of the second coefficient and the first request frequency is taken as the expected request frequency of the target node in the next period of the target period; the second coefficient ∈ (0, 1).

3. The method according to claim 2, characterized in that, Before using the minimum of the remaining request frequency and the expected request frequency as the second request frequency, the method further includes: If, based on the first request frequency and the request frequency allocated to the target node in other periods prior to the target period, it is determined that the number of requests allocated to the target node in K consecutive periods including the target period is greater than the average request frequency of the corresponding period, then the average request frequency of multiple nodes in the target period is taken as the expected request frequency of the target node in the next period of the target period.

4. The method according to claim 1, characterized in that, The method is executed by the target node, and the number of requests allocated to each of the plurality of nodes in each period during the execution of the target task is recorded in the storage node; Assigning the second request frequency to the target node includes: Based on the second request frequency, an update request is sent to the storage node; Receive a write success message returned by the storage node, which is generated after the storage node updates the request frequency for storing the target node to the second request frequency; In response to the successful write message, the request frequency stored in the target node is updated to the second request frequency.

5. The method according to claim 4, characterized in that, The storage node also stores the latest update time of the request frequency stored for each of the plurality of nodes; The step of determining the remaining request frequency based on the total request frequency used by the multiple nodes executing the target task and the request frequency already allocated to the other nodes among the multiple nodes excluding the target node includes: The request frequency and the latest update time of each of the other nodes are read from the storage node for the other nodes besides the target node. Based on the latest update time of each of the other nodes, invalid nodes are determined among the nodes other than the target node; wherein, the interval between the latest update time of the invalid node and the current time reaches a duration threshold, and the duration threshold exceeds the duration of the target period; The total number of allocated request frequencies is obtained by summing the request frequencies of the storage nodes for non-invalid nodes other than the target node. The remaining request frequency is obtained by subtracting the total request frequency from the total allocated request frequency.

6. The method according to claim 5, characterized in that, Sending an update request to the storage node based on the second request frequency includes: Based on the second request frequency and the node identifier of the invalid node, an update request is sent to the storage node, so that the storage node updates the request frequency stored for the target node to the second request frequency and removes the invalid node according to the update request.

7. The method according to claim 5, characterized in that, The storage node stores a frequency allocation record for the target task. The frequency allocation record includes the request frequency allocated to each of the plurality of nodes in each period during the execution of the target task and the latest update time of the request frequency stored for the plurality of nodes. When the storage node determines that the first version number and the second version number are the same, it updates the request frequency stored for the target node in the frequency allocation record to the second request frequency, and updates the version number of the frequency allocation record. Wherein, the first version number is the version number of the frequency allocation record read by the storage node after receiving the update request; the second version number is the version number of the frequency allocation record when the target node last read data from the storage node.

8. The method according to claim 7, characterized in that, After sending an update request to the storage node based on the second request frequency, the method further includes: Receive write error message returned by the storage node; wherein, the storage node returns the write error message when it determines that the first version number and the second version number are different; In response to the write error message, return to the step of reading the request frequency and the latest update time of each of the other nodes from the storage node.

9. The method according to claim 1, characterized in that, The acquisition of the first request frequency allocated to the target node in the target period and the rate limiting status of the target node in the target period includes: If the first subtask is not completed in the target period, obtain the first request frequency allocated to the target node in the target period and the rate limiting status of the target node in the target period.

10. A task execution control device, characterized in that, include: The acquisition module is used to acquire the first request frequency allocated to the target node in the target period and the rate limiting status of the target node in the target period; wherein, the target node requests to call an external service in the target period according to the first request frequency to execute a first subtask; the first subtask is one of a plurality of subtasks of the target task; The first confirmation module is used to determine the expected request frequency of the target node in the next cycle of the target cycle based on the rate limiting status and the first request frequency. The second confirmation module is used to determine the remaining request frequency based on the total request frequency used by the multiple nodes for executing the target task and the request frequency already allocated to the other nodes among the multiple nodes excluding the target node. The selection module is used to select the minimum value between the remaining request frequency and the expected request frequency as the second request frequency; An execution module is configured to allocate the second request frequency to the target node, so that the target node requests and invokes the external service according to the second request frequency in the next cycle.

11. An electronic device, characterized in that, include: processor; A memory storing computer instructions that, when executed by the processor, implement the method as described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the method as described in any one of claims 1-9.

13. A computer program product comprising computer instructions, characterized in that, When executed by a processor, the computer instructions implement the method described in any one of claims 1-9.

Images