A coroutine scheduling method, device, system, equipment, storage medium and product
By dynamically dividing scheduling domains and multi-priority queue groups in coroutine scheduling and monitoring the running status and load status, the problems of high-priority task response delay and low resource utilization are solved, and efficient coroutine task scheduling and resource optimization are achieved.
Patent Information
- Application Number
- CN202510866091.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-26
- Publication Date
- 2025-09-12
- Estimated Expiration
- 2045-06-26
AI Technical Summary
Traditional coroutine schedulers lack priority awareness, resulting in delayed responses to high-priority tasks and low resource utilization, making it difficult to cope with mixed load scenarios.
By dynamically dividing the scheduling domain, adopting multi-priority queue groups and storage modules, monitoring the operating status and load status, and migrating tasks, we ensure that high-priority tasks get priority execution resources and optimize resource utilization.
It achieves low-latency response for high-priority tasks and improves resource utilization, thereby improving the robustness and overall throughput of the system.
Smart Images

Figure CN120386608B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of task scheduling technology, and in particular to a coroutine scheduling method, apparatus, system, device, storage medium and product. Background Art
[0002] A coroutine is a lightweight concurrent execution unit in user mode, whose scheduling is managed directly by the application rather than the operating system kernel. Compared to threads and processes, coroutine context switching does not require falling into kernel mode, resulting in lower resource consumption, typically occupying only kilobytes of memory, and faster switching speeds, reaching nanoseconds to microseconds.
[0003] Despite the advantages of lightweight and high concurrency, coroutines still face some challenges in their scheduling mechanisms. Traditional coroutine schedulers lack priority awareness and struggle to cope with mixed workloads, such as the coexistence of real-time and batch tasks, leading to response delays for high-priority tasks. When multiple coroutines share the same queue, low-priority or resource-intensive coroutines may preempt the execution resources of high-priority tasks, causing priority inversion or a surge in tail latency. Furthermore, current scheduling strategies are based on static resource allocation, making it difficult to dynamically adjust queue strategies based on system load, impacting resource utilization.
[0004] It can be seen that how to improve resource utilization while ensuring timely processing of high-priority tasks is a problem that technical personnel in this field need to solve. Summary of the Invention
[0005] The present application provides a coroutine scheduling method, apparatus, system, device, storage medium and product to at least solve the problems in related technologies of untimely processing of high-priority tasks and low resource utilization.
[0006] This application provides a coroutine scheduling method, including:
[0007] Accessing a storage module corresponding to a target scheduling domain; wherein the target scheduling domain is provided with a multi-priority queue group; the multi-priority queue group is used to store a first coroutine task to be executed in the target scheduling domain; the storage module is used to store a second coroutine task to be executed periodically in the scheduling domain; the execution period of the first coroutine task is less than the execution period of the second coroutine task;
[0008] If there is an expired second coroutine task in the storage module, the expired second coroutine task is mounted to the multi-priority queue group;
[0009] Get and execute coroutine tasks from the multi-priority queue group in priority order;
[0010] During the phase of acquiring and executing coroutine tasks, the running status and load status of each scheduling domain are monitored; wherein the target scheduling domain is any scheduling domain among the scheduling domains;
[0011] Task migration of each scheduling domain is performed based on the operating status and load status of each scheduling domain.
[0012] The present application also provides a coroutine scheduling device, including an access unit, a mounting unit, an execution unit, a monitoring unit and a migration unit;
[0013] An access unit is configured to access a storage module corresponding to a target scheduling domain; wherein the target scheduling domain is configured to have a multi-priority queue group; the multi-priority queue group is configured to store a first coroutine task to be executed in the target scheduling domain; the storage module is configured to store a second coroutine task to be executed periodically in the target scheduling domain; and the execution period of the first coroutine task is shorter than the execution period of the second coroutine task.
[0014] The mounting unit is used to mount the expired second coroutine task to the multi-priority queue group when there is an expired second coroutine task in the storage module;
[0015] The execution unit is used to obtain and execute coroutine tasks from multiple priority queue groups in order of priority;
[0016] A monitoring unit is used to monitor the running status and load status of each scheduling domain during the acquisition and execution of the coroutine task; wherein the target scheduling domain is any scheduling domain among the scheduling domains;
[0017] The migration unit is used to migrate tasks of each scheduling domain according to the running status and load status of each scheduling domain.
[0018] The present application also provides a coroutine scheduling system, comprising at least one scheduling domain, each scheduling domain having at least one executor, each executor being bound to at least one processor core; a target scheduling domain being any scheduling domain in each scheduling domain; and a multi-priority queue group being corresponding to the target scheduling domain;
[0019] A multi-priority queue group, used to store the first coroutine task to be executed in the target scheduling domain;
[0020] A storage module is used to store a second coroutine task that is executed regularly in the target scheduling domain; the execution period of the first coroutine task is shorter than the execution period of the second coroutine task;
[0021] The scheduler is used to access the storage module; if there is an expired second coroutine task in the storage module, the expired second coroutine task is mounted to the multi-priority queue group; the coroutine task is obtained and executed from the multi-priority queue group in order of priority; during the acquisition and execution of the coroutine task, the operating status and load status of each scheduling domain are monitored; and the task migration of each scheduling domain is performed according to the operating status and load status of each scheduling domain.
[0022] An embodiment of the present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned coroutine scheduling methods when executing the computer program.
[0023] The present application also provides a computer-readable storage medium, in which a computer program is stored, wherein when the computer program is executed by a processor, the steps of any of the above-mentioned coroutine scheduling methods are implemented.
[0024] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned coroutine scheduling methods when executed by a processor.
[0025] Access the storage module corresponding to the target scheduling domain through this application; wherein the target scheduling domain is any scheduling domain among the scheduling domains; the target scheduling domain is provided with a multi-priority queue group; the multi-priority queue group is used to store the first coroutine task to be executed in the target scheduling domain; the storage module is used to store the second coroutine task that is executed periodically in the target scheduling domain; the execution period of the first coroutine task is less than the execution period of the second coroutine task. If there is an expired second coroutine task in the storage module, the expired second coroutine task is mounted to the multi-priority queue group. By dividing the multi-priority queue group and the storage module, the first coroutine task and the second coroutine task can be effectively distinguished. Only when the second coroutine task expires will it be placed in the multi-priority queue group, effectively avoiding the situation where batch tasks have not reached the execution time, resulting in other low-priority tasks being unable to be executed. By designing a multi-priority queue group, it can be ensured that high-priority tasks obtain execution resources first, reducing tail delay. During the acquisition and execution of coroutine tasks, the operating status and load status of each scheduling domain can be monitored; based on the operating status and load status of each scheduling domain, tasks of each scheduling domain are migrated, improving the robustness of the business and optimizing resource utilization. BRIEF DESCRIPTION OF THE DRAWINGS
[0026] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.
[0027] Figure 1 A flowchart of a coroutine scheduling method provided in an embodiment of the present application;
[0028] Figure 2 A schematic diagram of a scheduler performing status monitoring according to an embodiment of the present application;
[0029] Figure 3 A schematic diagram of a link relationship between multiple schedulers and a multi-priority queue group provided in an embodiment of the present application;
[0030] Figure 4 A schematic diagram of the structure of a coroutine scheduling device provided in an embodiment of the present application;
[0031] Figure 5 A schematic diagram of the structure of a coroutine scheduling system provided in an embodiment of the present application. DETAILED DESCRIPTION
[0032] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.
[0033] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.
[0034] Modern programming languages and frameworks all offer coroutine support. These include statically strongly typed, compiled languages (Golang, Go), computer programming languages (Python), and modern static programming languages (Kotlin). Frameworks include open-source protocol libraries (libco) and C++ libraries (Boost.Coroutine).
[0035] The scheduling algorithm for lightweight user-mode coroutines (Goroutine, G) implemented in the Go language is based on an M:N model. This algorithm dynamically binds multiple lightweight user-mode coroutines to a small number of operating system threads (OSThread) using logical processors (P). An OS thread can be considered a single executor (Machine, M). Work stealing and local run queues are used to achieve load balancing. A combination of cooperative scheduling (inserting preemption points into function calls) and signal-based preemptive scheduling (SIGURG forced interrupts) ensures responsiveness for high-priority tasks. Furthermore, an integrated network poller (Netpoller) desynchronizes blocking input / output (I / O) operations, avoiding thread blocking. Ultimately, this achieves high concurrency and low-latency scheduling of lightweight coroutines in user-mode.
[0036] However, the current coroutine scheduling method lacks fine-grained priority support: all Gs are treated equally by default, making it impossible to distinguish between real-time and batch tasks. High-priority tasks may experience response delays due to work stealing or global queue contention. The fixed number of Ps prevents dynamic partitioning of computing resources. For example, in mixed CPU-intensive and I / O-intensive workloads, it is difficult to isolate high- and low-priority tasks. Signal preemption relies on SIGURG and a 10ms threshold, making nanosecond-level real-time preemption impossible. Furthermore, cooperative preemption relies on code-inserted checkpoints, which poses a risk of bypass, such as in dense loops without function calls.
[0037] Therefore, the embodiments of the present application provide a coroutine scheduling method, apparatus, system, device, storage medium, and product that achieve resource isolation and load balancing by dynamically dividing scheduling domains. Multiple priority queue groups and storage modules are nested within each scheduling domain to support task preemption and priority inheritance, ensuring low-latency response for high-priority tasks. By monitoring the operating status and load status of each scheduling domain and dynamically optimizing resource allocation through task migration, the robustness of the business is improved, resource utilization is optimized, and overall throughput in a multi-core environment is improved.
[0038] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.
[0039] The embodiment of the present application provides a method for co-routine scheduling. Figure 1 A flowchart of a coroutine scheduling method provided in an embodiment of the present application includes:
[0040] S101: Access the storage module corresponding to the target scheduling domain; the multi-priority queue group is used to store the first coroutine task to be executed in the target scheduling domain; the storage module is used to store the second coroutine task to be executed regularly in the target scheduling domain.
[0041] In practical applications, different scheduling domains can be dynamically divided based on physical resources and task characteristics to achieve resource isolation and load balancing. Physical resources can include processor cores and cache levels, while task characteristics can include priority and resource requirements.
[0042] In the embodiment of the present application, according to the functions required to be implemented in each scheduling domain, there may be at least one executor in each scheduling domain.
[0043] Executors can migrate between different scheduling domains. The domain in which an executor executes its business depends on business requirements and configuration. Each executor is bound to at least one processor core. By binding executors to processor cores, cross-domain cache misses can be reduced, enabling task-to-hardware affinity scheduling, and improving instruction-level parallelism and cache hit rates.
[0044] A scheduling domain can contain multiple executors, each of which performs similar functions. In this application's embodiments, the operation of a single executor is used as an example. The scheduling domain in which this executor resides is called the target scheduling domain. The target scheduling domain is any of the scheduling domains. Multiple priority queue groups are configured for the target scheduling domain.
[0045] Considering that the second coroutine task often has a specific execution time and a long execution time. If it is directly placed in a multi-priority queue group according to its priority, when the second coroutine task has not reached its execution time, the coroutine tasks with lower priority than it will not be processed for a long time. Therefore, in an embodiment of the present application, in order to better handle different types of tasks, a multi-priority queue group and a storage module can be set for each scheduling domain.
[0046] Taking the target scheduling domain as an example, the multi-priority queue group is used to store the first coroutine tasks to be executed in the target scheduling domain. The storage module is used to store the second coroutine tasks that are executed regularly in the target scheduling domain.
[0047] The execution period of the first coroutine task is shorter than the execution period of the second coroutine task. In practical applications, the first coroutine task can be a real-time coroutine task, and the second coroutine task can be a batch coroutine task.
[0048] S102: When there is an expired second coroutine task in the storage module, the expired second coroutine task is mounted to the multi-priority queue group.
[0049] S103: Obtain and execute the coroutine task from the multi-priority queue group in order of priority.
[0050] In actual applications, the executors contained in the target scheduling domain can be used to obtain and execute coroutine tasks from the multi-priority queue group in priority order.
[0051] S104: During the phase of acquiring and executing the coroutine task, the running status and load status of each scheduling domain are monitored.
[0052] S105: Perform task migration of each scheduling domain according to the operation status and load status of each scheduling domain.
[0053] The executor in this application is equivalent to a thread, which processes coroutine tasks by calling program code. The called program code may include coroutine code for executing coroutine tasks, as well as code for obtaining tasks from multiple priority queue groups and monitoring the running status and load status of each scheduling domain.
[0054] For ease of description, the coroutine code can be referred to as a coroutine, and the code that retrieves tasks from the multi-priority queue group and monitors the running status and load status of each scheduling domain can be referred to as the scheduler. From the user's perspective, the executor implements coroutine scheduling, so the scheduler can be considered a module included in the executor.
[0055] There are multiple executors in the scheduling domain. When executing tasks, each executor uses the scheduler to determine whether there are expired coroutine tasks in the storage module. If there are expired coroutine tasks, they are placed in the multi-priority queue group. The scheduler in the executor is responsible for obtaining coroutine tasks from the multi-priority queue group.
[0056] Taking the target scheduling domain as an example, in actual applications, the scheduler can access the storage module corresponding to the target scheduling domain; if there is an expired second coroutine task in the storage module, the expired second coroutine task is mounted to the multi-priority queue group; and the coroutine task is obtained from the multi-priority queue group in order of priority.
[0057] By executing coroutine tasks in order of priority, it can be ensured that high-priority coroutine tasks are executed first, effectively avoiding the situation where low-priority coroutine tasks preempt resources.
[0058] During the phase of acquiring and executing coroutine tasks, the scheduler can monitor the running status and load status of each scheduling domain; and perform task migration for each scheduling domain based on the running status and load status of each scheduling domain.
[0059] Coroutines and schedulers belong to different stacks. The scheduler can obtain coroutine tasks from a multi-priority queue group. When the coroutine returns to the scheduler, the stack is switched, and the scheduler can automatically perform status monitoring.
[0060] The scheduler can monitor the operating status and load status of the scheduling domain. The operating status can include normal status and abnormal status. The load status can include high load status, normal load status, and low load status. In actual applications, the value ranges corresponding to the high load status, normal load status, and low load status can be pre-set. By comparing the load value of the scheduling domain with the pre-set value range, the load status can be determined. The load value of the scheduling domain can be the number of all coroutine tasks contained in the scheduling domain.
[0061] Typically, different scheduling domains execute different coroutine tasks. However, due to the special nature of coroutine tasks, the executor in one scheduling domain can also execute coroutine tasks in other scheduling domains. Coroutine tasks in abnormal scheduling domains can be transferred to normal and less-loaded scheduling domains.
[0062] The number of scheduling domains and the number of executors within a scheduling domain can be configured based on business requirements. The maximum number is determined by the number of CPU cores recognized by the operating system. A scheduling domain must contain at least one executor. An executor is bound to at least one CPU core.
[0063] To ensure high performance, one CPU core is bound to one executor. Therefore, if the maximum number of CPU cores is expressed as max_cpus, then the number of scheduling domains is in the range [1, max_cpus], and the number of executors in a scheduling domain is in the range [1, max_cpus]. The total number of executors in all scheduling domains must be less than max_cpus.
[0064] In the scheduling domain, each executor completes the execution of tasks by obtaining the coroutines in the scheduling domain. Coroutines are sorted according to different priorities in the scheduling domain.
[0065] In the specific implementation, the executor obtains the coroutine task from the multi-priority queue group through the built-in scheduler and then executes the coroutine task.
[0066] As can be seen from the above technical solution, the storage module corresponding to the target scheduling domain is accessed; wherein the target scheduling domain is provided with a multi-priority queue group; the multi-priority queue group is used to store the first coroutine task to be executed in the corresponding scheduling domain; the storage module is used to store the second coroutine task that is periodically executed in the corresponding scheduling domain; the execution period of the first coroutine task is shorter than the execution period of the second coroutine task. If an expired second coroutine task exists in the storage module, the expired second coroutine task is mounted to the multi-priority queue group. By dividing the multi-priority queue group and the storage module, the first coroutine task and the second coroutine task can be effectively distinguished. Only when the second coroutine task expires is it placed in the multi-priority queue group, effectively avoiding the situation where batch tasks have not yet reached their execution time, resulting in other lower-priority tasks being unable to be executed. By designing a multi-priority queue group, it is possible to ensure that high-priority tasks obtain execution resources first, reducing tail latency. During the acquisition and execution of coroutine tasks, the operating status and load status of the scheduling domains can be monitored; based on the operating status and load status of each scheduling domain, tasks in each scheduling domain are migrated, improving business robustness and optimizing resource utilization.
[0067] The processing method of coroutine tasks in each scheduling domain is similar. In the embodiments of this application, one scheduling domain is used as an example to explain. Scheduling domains often contain multiple schedulers, and each scheduler performs similar operations. Next, we will use one scheduler as an example to explain. For ease of distinction, the scheduling domain to which the current scheduler belongs can be called the target scheduling domain.
[0068] During the phase of acquiring and executing coroutine tasks, the scheduler can monitor the status of the target scheduling domain, the executors contained in the target scheduling domain, and the coroutine tasks executed by them.
[0069] If the target scheduling domain is in an abnormal state, to ensure the smooth execution of coroutine tasks in the target scheduling domain, the coroutine tasks stored in the multi-priority queue group and storage module corresponding to the target scheduling domain can be migrated to a scheduling domain that is in a normal state and meets the load requirements. The scheduling domain that meets the load requirements can be the scheduling domain with the smallest load.
[0070] If there is an abnormal target executor, an executor warning message may be generated. If there is an abnormal target coroutine task, a coroutine warning message may be generated.
[0071] Figure 2 A schematic diagram of a scheduler performing status monitoring according to an embodiment of the present application is provided. Figure 2The example above uses two scheduling domains, each containing two executors, and each executor containing a scheduler. For ease of distinction, the two scheduling domains are referred to as scheduling domain a and scheduling domain b. A scheduler can monitor the status of its own scheduling domain, the status of all executors within its own scheduling domain, and the status of the coroutine tasks being executed. When the operating status of scheduling domain a is abnormal, while scheduling domain b is operating normally and under low load, the scheduler currently executing the coroutine task in scheduling domain a can migrate the coroutine tasks in the multi-priority queue group and storage module within scheduling domain a to scheduling domain b.
[0072] In actual applications, the scheduler identifies the operating status of a scheduling domain based on whether the coroutine tasks in the multi-priority queue groups and storage modules within the scheduling domain are being executed. For example, if the coroutine tasks in the multi-priority queue groups and storage modules are being executed normally, the scheduling domain is operating normally and can be determined to be in a normal state. If the coroutine tasks in the multi-priority queue groups and storage modules are not executed for an extended period of time, it indicates that the scheduling domain is operating abnormally and can be determined to be in an abnormal state.
[0073] The scheduler can evaluate the load status of the scheduling domain based on the number of coroutine tasks contained in the scheduling domain. The scheduler can obtain the number of coroutine tasks stored in the multi-priority queue group and the storage module. For example, when the number of coroutine tasks is greater than the set load upper limit, it indicates that the load of the scheduling domain is high and the scheduling domain can be determined to be in a high load state. When the number of coroutine tasks is less than the set load lower limit, it indicates that the load of the scheduling domain is small and the scheduling domain can be determined to be in a low load state. When the number of coroutine tasks is between the load lower limit and the load upper limit, it indicates that the load of the scheduling domain is normal and the scheduling domain can be determined to be in a normal load state.
[0074] For the evaluation of the executor status, the scheduler can detect whether the executor has not executed tasks for a long time. If the executor has not executed tasks for a long time, it can be determined that the executor status is abnormal.
[0075] In the case of abnormal executor status, in addition to generating alarm information, the scheduler can also migrate executors with normal status from other scheduling domains that meet the load requirements when there is an abnormal target executor to ensure the smooth execution of the coroutine task in the current scheduling domain.
[0076] The scheduler can evaluate the status of the coroutine task based on the execution time of the coroutine task. For example, when the execution time of the coroutine task exceeds the set time threshold, the scheduler can determine that the coroutine task status is abnormal.
[0077] In real-world applications, a scheduling domain often contains a large number of schedulers, each of which can execute different coroutine tasks. After the current scheduler completes a coroutine task, the next scheduler will retrieve another coroutine task from the multi-priority queue group. However, the time interval between the previous scheduler's completion of status monitoring and the completion of status monitoring is short, making further status monitoring ineffective.
[0078] Therefore, before each scheduler monitors the status of the target scheduling domain, the executors contained in the target scheduling domain, and the coroutine tasks executed by them, it can determine whether the difference between the current time and the last monitoring time is greater than or equal to the set time threshold.
[0079] If the difference between the current time and the last monitored time is greater than or equal to the set time threshold, status monitoring can be performed for the target scheduling domain, its contained executors, and the coroutine tasks it executes. If the difference between the current time and the last monitored time is less than the set time threshold, status monitoring is not performed and coroutine tasks are directly retrieved and executed from the multi-priority queue group in order of priority.
[0080] By detecting the time interval, it is possible to effectively avoid multiple status monitoring of the scheduling domain and the executors and coroutine tasks within the scheduling domain in a short period of time, thereby reducing the workload of the scheduler.
[0081] The scheduler executes coroutine tasks stored in multiple priority queue groups in descending order of priority. Based on demand, these queue groups can be divided into high-priority, medium-priority, and low-priority groups. The number of queues in each queue group is dynamically adjustable.
[0082] The total number of low-priority queues in a low-priority queue group is greater than or equal to the total number of executors in its scheduling domain. Each executor is linked to a low-priority queue by default. Each high-priority queue in a high-priority queue group has its own high priority. Each medium-priority queue in a medium-priority queue group has its own weight; the weight of each medium-priority queue is set based on the medium-priority weight and queue weight.
[0083] The number of priority queues contained in different priority queue groups can be pre-set according to resource requirements, and in actual operation, the number of priority queues can also be dynamically adjusted according to changes in requirements.
[0084] Each high-priority queue in a high-priority queue group can have its own priority set. Each medium-priority queue in a medium-priority queue group can also have its own priority set. Each low-priority queue in a low-priority queue group has a low priority and does not need to be further subdivided.
[0085] In practical applications, priorities can be represented by numbers, with larger numbers indicating lower priorities. For example, a high-priority queue group contains three high-priority queues with priorities of 1, 2, and 3, respectively; a medium-priority queue group contains three medium-priority queues with priorities of 4, 5, and 6, respectively.
[0086] When the scheduler obtains a coroutine task from a multi-priority queue group, it can determine whether there is a high-priority coroutine task in the multi-priority queue group.
[0087] When there are high-priority coroutine tasks, the coroutine tasks stored in each high-priority queue can be executed first.
[0088] For high-priority queues, the coroutine tasks stored in each high-priority queue can be executed in sequence according to the first-in-first-out method.
[0089] In the absence of high-priority coroutine tasks, the coroutine tasks in the medium-priority queue group can be executed.
[0090] For each medium-priority queue, the priority of each medium-priority queue is different. In order to avoid executing only the coroutine tasks in one of the medium-priority queues for a long time, causing the coroutine tasks in other medium-priority queues to be in a waiting state for a long time, the number of tasks in each medium-priority queue can be set according to the weight.
[0091] In actual applications, the number of tasks in each medium priority queue can be determined based on the total number of tasks in the medium priority queue group and the weights of each medium priority queue. The corresponding number of coroutine tasks in each medium priority queue is executed in sequence according to the number of tasks in each medium priority queue.
[0092] The number of tasks in each medium-priority queue can be regarded as the number of coroutine tasks executed from each medium-priority queue in one round of traversal.
[0093] Use W to represent priority, W(middle) represents the priority of the medium priority queue group, W(low) represents the priority of the low priority queue group, and the priority of the medium priority queue group plus the priority of the low priority queue group equals 1, that is, W(middle)+W(low)=1. Assume that w(i) represents the weight of the i-th priority queue, and the 4th to 6th priority queues in the multi-priority queue group are medium priority queues. The sum of the weights of all medium priority queues in the medium priority queue group equals 1, then In a multi-priority queue group, the 7th to nth priority queues are low priority queues. The sum of the weights of all low priority queues in the low priority queue group is equal to 1. .
[0094] In a scheduling domain with n schedulers, the weights of the respective priority queues are:
[0095] Q(i)=w(i)*W(middle).
[0096] C(sum) represents the total number of tasks in the current medium priority queue group. Therefore, the number of tasks C(i) in each medium priority queue in the medium priority queue group in each round is equal to the total number of tasks multiplied by the weight of each medium priority queue, that is, C(i) = C(sum) * Q(i).
[0097] In an embodiment of the present application, the higher the priority of the queue, the higher the corresponding weight can be set, so as to ensure that as many high-priority coroutine tasks as possible are processed. The number of tasks in each medium-priority queue is set according to the weight and the total number of tasks. After each coroutine task with the corresponding number of tasks in the current medium-priority queue is executed, the coroutine task in the next medium-priority queue can be executed. Even if there are a large number of coroutine tasks in a certain medium-priority queue, through the limitation of the number of tasks, in each round of the cycle, only the coroutine tasks with the corresponding number of tasks need to be executed before the coroutine tasks in the next medium-priority queue can be processed. This effectively avoids the situation where the coroutine tasks of the low-priority medium-priority queue are not processed for a long time, and ensures the timeliness of the processing of the coroutine tasks in each medium-priority queue.
[0098] The high-priority queue does not participate in weight calculations; if there are coroutine tasks in the high-priority queue, they will be scheduled for execution immediately. Coroutine tasks in each medium-priority queue are executed according to their weights. Coroutine tasks in each low-priority queue can also be ranked according to their weights. Based on this, the scheduler prioritizes coroutine tasks in its own mapped low-priority queues.
[0099] The number of tasks in each medium-priority queue is affected by its weight. The larger the weight, the more tasks it corresponds to. However, in actual applications, there may be cases where the actual number of coroutine tasks stored in the medium-priority queue is less than the number of tasks it corresponds to. In this case, if the number of tasks in the target medium-priority queue has not been consumed and the coroutine tasks in the target medium-priority queue are empty, the scheduler will execute the coroutine task in the next medium-priority queue adjacent to the target medium-priority queue. The target medium-priority queue can be any medium-priority queue among all medium-priority queues.
[0100] For example, suppose there are 8 coroutine tasks in the medium-priority queue, and the number of tasks in the medium-priority queue is 10. After the scheduler executes 8 coroutine tasks, the coroutine tasks in the medium-priority queue are empty, but there are still 2 tasks that have not been consumed. At this time, the scheduler can execute the coroutine tasks in the next medium-priority queue adjacent to it. When all coroutine tasks in the medium-priority queue are executed, the coroutine tasks in the low-priority queue group can be executed.
[0101] After each round of coroutine tasks in a medium-priority queue group is completed, the total number of coroutine tasks in the medium-priority queue group will change. To ensure the rationality of the number of tasks set for each medium-priority queue, the number of tasks in each medium-priority queue group can be adjusted after each round of coroutine tasks in the medium-priority queue group is completed.
[0102] After each round of coroutine tasks in the medium-priority queue group is completed, the scheduler can count the total number of all remaining coroutine tasks in the medium-priority queue group; determine the latest number of tasks in each medium-priority queue based on the total number of all remaining coroutine tasks and the corresponding weights of each medium-priority queue; execute the corresponding number of coroutine tasks in each medium-priority queue in turn according to the latest number of tasks in each medium-priority queue; until all coroutine tasks in the medium-priority queue group are completed.
[0103] In an embodiment of the present application, based on the change in the total number of coroutine tasks in the medium priority queue group, the number of tasks in each medium priority queue is adjusted so that the distribution of the number of tasks can fit the total number of coroutine tasks in the medium priority queue group, thereby ensuring the rationality of the task number setting.
[0104] To reduce conflicts when multiple schedulers access medium-priority queues, you can configure the concurrency limit for each medium-priority queue while setting weighted scheduling. You can pre-set the concurrency limit for each medium-priority queue and dynamically adjust it in practice.
[0105] Concurrency refers to the number of schedulers accessing the medium priority queue at the same time.
[0106] In an embodiment of the present application, when the number of schedulers accessing the target middle priority queue reaches the corresponding concurrency number of the target middle priority queue, the scheduler can select the coroutine task of the next priority queue to execute; if the number of schedulers of all middle priority queues reaches their respective corresponding concurrency numbers, the coroutine task in the low priority queue group can be executed.
[0107] For example, a medium-priority queue group contains three medium-priority queues, namely medium-priority queue (4), medium-priority queue (5), and medium-priority queue (6). Assuming that the concurrency of medium-priority queue (4) is 3, it means that 3 schedulers are allowed to access medium-priority queue (4) at the same time. If there are already 3 schedulers accessing medium-priority queue (4), when the 4th scheduler accesses medium-priority queue (4), since the number of schedulers accessing medium-priority queue (4) is 3, which has reached the concurrency corresponding to medium-priority queue (4), the 4th scheduler can access medium-priority queue (5) and execute the coroutine task in medium-priority queue (5).
[0108] Assume that the concurrency of the medium priority queue (4) is 3, the concurrency of the medium priority queue (5) is 2, and the concurrency of the medium priority queue (6) is 1. If there are already 3 schedulers accessing the medium priority queue (4), 2 schedulers accessing the medium priority queue (5), and 1 scheduler accessing the medium priority queue (6), when the 7th scheduler accesses the medium priority queue, since the number of schedulers accessing each medium priority queue has reached the corresponding concurrency of each medium priority queue, the 7th scheduler can access the low priority queue.
[0109] The number of concurrent connections for each medium-priority queue can be configured and dynamically adjusted based on actual business conditions. Dynamic adjustment can be performed based on business load, weight, and performance.
[0110] In actual applications, the concurrency number of each medium-priority queue is first set according to the weight ratio of the medium-priority queue, and then the value can be increased or decreased in proportion according to the load, weight and performance during the actual task execution phase.
[0111] In an embodiment of the present application, the weight and concurrency are used to jointly determine which coroutine task on the medium priority queue to execute. When the scheduler selects the coroutine task of the medium priority queue, if the number of schedulers accessing the medium priority queue reaches the concurrency limit, the coroutine task of the next medium priority queue is selected for execution. If all medium priority queues have reached the concurrency limit, the coroutine task of the low priority queue is executed. This can not only ensure that high-priority coroutine tasks are executed first, but also avoid coroutine tasks on other priority queues from being unprocessed for a long time, and improve resource utilization.
[0112] To ensure efficient operation of medium priority, a monitoring module can be set up. The background tasks included in the monitoring module can be controlled through configuration development. Interval sampling is used to monitor the conflicts among priority queues when multiple schedulers obtain coroutine tasks. During the interval sampling period, the average time taken by each scheduler to obtain the coroutine tasks on each priority queue is collected and statistics are compiled based on the priority queue. Based on the number of tasks processed during the sampling period and the time taken to obtain the coroutine tasks in each priority queue, it is determined whether the concurrency of each medium priority queue needs to be adjusted. If the ratio of the number of tasks processed by each medium priority queue to the average time taken is low, the monitoring module can reduce the concurrency to achieve the goal of improving performance and helping developers debug the program.
[0113] Each scheduler has a low-priority queue that is linked by default. Therefore, when the scheduler obtains the execution permission of the coroutine task in the low-priority queue group, it can give priority to executing the coroutine task in the low-priority queue of its default link.
[0114] Figure 3 A schematic diagram of a link relationship between multiple schedulers and multi-priority queue groups provided in an embodiment of the present application, Figure 3 In the example, three schedulers are used. The default queue of each scheduler is a low priority queue in the multi-priority queue group. The multi-priority queue group is divided into high priority queue group, medium priority queue group and low priority queue group. Figure 3 Each priority queue group in the example contains 3 priority queues, for a total of 9 priority queues, numbered (1) to (9). For the high priority queue group and the medium priority queue group, the smaller the value of the corresponding number, the higher the priority level, while the priority level of each low priority queue in the low priority queue group is the same.
[0115] Figure 3 The first scheduler defaults to the low-priority queue (7), the second scheduler defaults to the low-priority queue (8), and the third scheduler defaults to the low-priority queue (9). When the first scheduler obtains the execution permission for the coroutine task in the low-priority queue group, it will prioritize the execution of the coroutine task stored in the low-priority queue (7). When the second scheduler obtains the execution permission for the coroutine task in the low-priority queue group, it will prioritize the execution of the coroutine task stored in the low-priority queue (8). When the third scheduler obtains the execution permission for the coroutine task in the low-priority queue group, it will prioritize the execution of the coroutine task stored in the low-priority queue (9).
[0116] In a low-priority queue group, each low-priority queue has the same priority level. By setting the default queue of each scheduler to a different low-priority queue, the balanced execution of coroutine tasks on each low-priority queue in the low-priority queue group is ensured, avoiding the situation where all schedulers concentrate on executing coroutine tasks on a certain low-priority queue, resulting in coroutine tasks in other low-priority queues not being processed for a long time.
[0117] A high-priority queue group often contains multiple high-priority queues. To reduce conflicts caused by multiple schedulers accessing a high-priority queue simultaneously, you can set a concurrency limit for the high-priority queue. The concurrency limit refers to the upper limit on the number of schedulers that can simultaneously access a high-priority queue.
[0118] In an embodiment of the present application, the scheduler can select the coroutine task of the next priority queue to execute when the number of schedulers accessing the target high priority queue reaches the concurrency upper limit corresponding to the target high priority queue.
[0119] For example, assuming that the concurrency limit of the high-priority queue is 3, and there are currently 3 schedulers accessing the high-priority queue, if the fourth scheduler also accesses the high-priority queue, since the number of schedulers accessing the high-priority queue has reached its corresponding concurrency limit, the fourth scheduler can access the next priority queue adjacent to the high-priority queue.
[0120] When multiple schedulers access the same high-priority queue simultaneously, they often need to retrieve coroutine tasks from the high-priority queue in sequence. This causes multiple schedulers to wait in line, while coroutine tasks in other priority queues cannot be processed in a timely manner. By setting a concurrency limit for the high-priority queue, you can effectively avoid conflicts caused by multiple schedulers accessing the same high-priority queue at the same time, which causes waste of resources.
[0121] After setting the upper limit of the number of concurrent calls for the high-priority queue, you can also dynamically adjust the upper limit of the number of concurrent calls for the high-priority queue according to changes in actual conditions.
[0122] In an embodiment of the present application, if the number of schedulers accessing the target high-priority queue is greater than the number of queues containing tasks, the current scheduler may calculate the difference between the number of schedulers accessing the target high-priority queue and the number of queues containing tasks. If the difference is less than or equal to a predefined value, the difference is used as the upper limit of the concurrency limit; if the difference is greater than the predefined value, the predefined value is used as the upper limit of the concurrency limit.
[0123] The upper limit of the number of concurrent connections for each high-priority queue is in the range [1, the number of executors in the scheduling domain].
[0124] In a specific implementation, if the total number of schedulers accessing the high-priority queue is 1 and the upper limit of concurrency for each high-priority queue is 1, the scheduler sequentially obtains the coroutine tasks in each high-priority queue according to the priority. Only when the high-priority queue is empty can it obtain the coroutine tasks in the queue of the next lower level.
[0125] If the number of schedulers accessing the high-priority queue is less than or equal to the number of queues with tasks, and the upper limit of concurrency for each high-priority queue is 1, the scheduler selects the coroutine tasks in the high-priority queue that has not reached the upper limit of concurrency according to the priority for execution.
[0126] The number of queues with tasks refers to the number of high-priority queues containing coroutine tasks among all high-priority queues. For example, if the high-priority queue group contains 5 high-priority queues and 3 of them contain coroutine tasks, then the number of queues with tasks is 3.
[0127] If the number of schedulers C(p) accessing the high-priority queue is greater than the number of queues with tasks C(q), the difference is denoted as C(n), and C(n)=C(p)-C(q). The upper limit of concurrency for each high-priority queue can be dynamically calculated. When 1 < C(n) <= the predefined value, the upper limit of concurrency takes the value of C(n); when C(n) > the predefined value, the upper limit of concurrency is the predefined value.
[0128] The value of the predefined value can be obtained through testing according to the actual business situation. The predefined value is a configurable value. For example, in the initial state, the predefined value can be set to 3.
[0129] In the embodiments of the present application, by comparing the number of schedulers accessing the high-priority queue and the number of queues with tasks, the adjustment of the upper limit of concurrency for the high-priority queue is realized, so that the upper limit of concurrency for each high-priority queue is set more reasonably, effectively reducing the situation of conflicts caused by multiple schedulers accessing the same high-priority queue simultaneously.
[0130] When the average value of the number of schedulers accessing all high-priority queues currently is greater than the predefined value, it means that each high-priority queue has its corresponding upper limit of concurrency number of schedulers for execution. For the extra current schedulers, they can execute the coroutine tasks of the medium-priority queue group.
[0131] When a new coroutine task is received, the new coroutine task can be added to the matching position in the multi-priority queue group according to the priority of the new coroutine task.
[0132] When the new coroutine task is a high-priority coroutine task, the new coroutine task can be added to the high-priority queue in the high-priority queue group with the same priority as the new coroutine task.
[0133] In the case where the new coroutine task is a medium-priority coroutine task, the new coroutine task may be added to a medium-priority queue in the medium-priority queue group having the same priority as the new coroutine task.
[0134] In the case that the new coroutine task is a low-priority coroutine task, the new coroutine task can be added to the low-priority queue of the low-priority queue group according to the preset low-priority task allocation strategy.
[0135] For low-priority coroutine tasks, in order to ensure the balance of coroutine tasks in the low-priority queue, the preset low-priority task allocation strategy can use polling or load methods to add new coroutine tasks to the corresponding low-priority queue.
[0136] In a specific implementation, if the new coroutine task is a low-priority coroutine task, it can be added to the currently polled low-priority queue in a round-robin manner. Alternatively, the load of each low-priority queue can be counted and the new coroutine task can be added to the low-priority queue with the smallest load.
[0137] The polling method is to add the coroutine task to all low-priority queues in turn. The load method is to select a low-load priority queue from all low-priority queues and add the coroutine task to it.
[0138] In actual applications, there may be a situation where the new coroutine task does not have a priority. In that case, the new coroutine task can be set to the default priority, so that the new coroutine task can be added to the appropriate position of the multi-priority queue group.
[0139] To ensure the correctness of coroutine task execution, status query and statistics functions can be added to the scheduling domain, executor, and scheduler.
[0140] The status query and statistics functions added to the scheduling domain allow you to query the scheduling domain configuration, the number of executors in the current scheduling domain, the number of queues in the multi-priority queue group in the scheduling domain, the number of coroutine tasks in the multi-priority queue group, the number of coroutine tasks in the storage module, and the current scheduler status. The current scheduler status can include whether there are any abnormal executors and whether there have been any coroutine tasks migrated from other scheduling domains.
[0141] The status query and statistics functions added to the executor can query the executor status, the number of coroutines executed by the current scheduler, whether the executor has switched to a different scheduling domain, the executor creation time, etc.
[0142] The status query and statistics functions added to the scheduler can query the status, creation time, execution count, etc. of the coroutine tasks in each priority queue; the number of coroutine tasks and task status in the storage module can be queried.
[0143] Figure 4 A schematic diagram of the structure of a coroutine scheduling device provided in an embodiment of the present application, applicable to a scheduler, includes an access unit 41, a mounting unit 42, an execution unit 43, a monitoring unit 44, and a migration unit 45;
[0144] An access unit 41 is configured to access a storage module corresponding to a target scheduling domain; wherein the target scheduling domain is provided with a multi-priority queue group; the multi-priority queue group is configured to store a first coroutine task to be executed in the target scheduling domain; the storage module is configured to store a second coroutine task to be executed periodically in the corresponding scheduling domain; the execution period of the first coroutine task is shorter than the execution period of the second coroutine task;
[0145] The mounting unit 42 is configured to mount the expired second coroutine task to the multi-priority queue group when there is an expired second coroutine task in the storage module; wherein the multi-priority queue group is used to store the first coroutine task to be executed in its corresponding scheduling domain;
[0146] An execution unit 43 is used to obtain and execute coroutine tasks from the multi-priority queue group in order of priority;
[0147] The monitoring unit 44 is used to monitor the running status and load status of each scheduling domain during the acquisition and execution of the coroutine task;
[0148] The migration unit 45 is configured to migrate tasks of each scheduling domain according to the operation status and load status of each scheduling domain.
[0149] The omitted virtual device claims should be described in detail in the specification, corresponding one-to-one with the method claims.
[0150] For the description of the features in the embodiment corresponding to the coroutine scheduling device, please refer to the relevant description of the embodiment corresponding to the coroutine scheduling method, and will not be repeated here.
[0151] As can be seen from the above technical solution, the scheduler accesses the storage module corresponding to the target scheduling domain; the target scheduling domain is equipped with a multi-priority queue group; the multi-priority queue group is used to store the first coroutine task to be executed in the target scheduling domain; the storage module is used to store the second coroutine task that is executed periodically in the target scheduling domain; the execution period of the first coroutine task is shorter than the execution period of the second coroutine task. Each scheduling domain has at least one executor, and each executor is bound to at least one processor core. By binding the required processor cores, each scheduling domain achieves the purpose of dividing processor core resources, effectively improving processor resource utilization and enhancing business efficiency. Each executor has a built-in scheduler. If there is an expired second coroutine task in the storage module, the scheduler mounts the expired second coroutine task to the multi-priority queue group. The multi-priority queue group is used to store the first coroutine task to be executed in its corresponding scheduling domain. By dividing the multi-priority queue group and the storage module, the first coroutine task and the second coroutine task can be effectively distinguished. The second coroutine task is only placed in the multi-priority queue group when it expires, effectively avoiding the situation where batch tasks have not yet reached their execution time, resulting in other lower-priority tasks being unable to be executed. By designing multiple priority queue groups, we ensure that high-priority tasks receive priority execution resources, reducing tail latency. When acquiring and executing coroutine tasks, the scheduler monitors the operating status and load of each scheduling domain. Based on this information, it migrates tasks between these domains, improving service robustness and optimizing resource utilization.
[0152] Figure 5 A structural diagram of a coroutine scheduling system provided for an embodiment of the present application includes at least one scheduling domain 1, each scheduling domain 1 has at least one executor 2, and the executor 2 can migrate between different scheduling domains 1.
[0153] Considering that the second coroutine task often has a specific execution time and a long execution time. If it is directly placed in the multi-priority queue group 3 according to the priority, when the second coroutine task does not reach its execution time, the coroutine tasks with lower priority than it will not be processed for a long time. Therefore, in the embodiment of the present application, in order to better handle different types of tasks, a multi-priority queue group 3 and a storage module 4 can be set for each scheduling domain 1. Figure 5 Take two scheduling domains as an example.
[0154] Taking any scheduling domain in each scheduling domain, namely the target scheduling domain, as an example, the multi-priority queue group 3 is used to store the first coroutine task to be executed in the target scheduling domain; the storage module 4 is used to store the second coroutine task that is executed periodically in the target scheduling domain; the execution period of the first coroutine task is less than the execution period of the second coroutine task.
[0155] Executor 2 is used to access storage module 4; if there is an expired second coroutine task in storage module 4, the expired second coroutine task is mounted to multi-priority queue group 3; coroutine tasks are obtained and executed from multi-priority queue group 3 in order of priority; during the stage of obtaining and executing coroutine tasks, the operating status and load status of each scheduling domain 1 are monitored; and tasks of each scheduling domain 1 are migrated according to the operating status and load status of each scheduling domain 1.
[0156] Each executor 2 has a built-in scheduler 21. There are multiple executors 2 in the scheduling domain 1. When executing a task, each executor 2 uses the scheduler 21 to determine whether there are any expired coroutine tasks in the storage module 4. If there are any expired coroutine tasks, the coroutine tasks are placed in the multi-priority queue group 3. The scheduler 21 in the executor 2 is responsible for obtaining coroutine tasks from the multi-priority queue group and executing them.
[0157] In actual applications, the scheduler 21 can access the storage module 4 corresponding to the target scheduling domain; when there is an expired second coroutine task in the storage module 4, the expired second coroutine task is mounted to the multi-priority queue group 3; and the coroutine task is obtained and executed from the multi-priority queue group 3 in order of priority.
[0158] By executing coroutine tasks in order of priority, it can be ensured that high-priority coroutine tasks are executed first, effectively avoiding the situation where low-priority coroutine tasks preempt resources.
[0159] During the phase of acquiring and executing coroutine tasks, the scheduler 21 may monitor the running status and load status of each scheduling domain 1 ; and perform task migration of each scheduling domain 1 according to the running status and load status of each scheduling domain 1 .
[0160] The coroutine and the scheduler 21 belong to different stacks. The scheduler 21 can obtain the coroutine task from the multi-priority queue group. When the coroutine returns to the scheduler 21, the stack will be switched. At this time, the scheduler 21 can automatically perform status monitoring.
[0161] The scheduler 21 can monitor the operating status and load status of the scheduling domain 1. The operating status can include a normal state and an abnormal state. The load status can include a high load state, a normal load state, and a low load state. In actual applications, the value ranges corresponding to the high load state, the normal load state, and the low load state can be pre-set. By comparing the load value of the scheduling domain 1 with the pre-set value range, the load status can be determined. Among them, the load value of the scheduling domain 1 can be the number of all coroutine tasks contained in the scheduling domain 1.
[0162] Typically, different scheduling domains 1 execute different coroutine tasks. However, due to the special nature of coroutine tasks, an executor 2 in a scheduling domain 1 can also execute coroutine tasks in other scheduling domains 1. Coroutine tasks in abnormal scheduling domains can be transferred to normal and low-load scheduling domains.
[0163] As can be seen from the above technical solution, the coroutine scheduling system is divided into different scheduling domains. Each scheduling domain contains at least one executor, and each executor is bound to at least one processor core. A multi-priority queue group is configured for each target scheduling domain. The multi-priority queue group is used to store the first coroutine task to be executed in the corresponding scheduling domain. The storage module is used to store the second coroutine task that is periodically executed in the corresponding scheduling domain. By dividing the multiple scheduling domains, coroutine tasks are divided into different scheduling domains for execution, thereby allocating processor core resources, effectively improving processor resource utilization and enhancing business efficiency. By dividing the multi-priority queue group and the storage module, the first and second coroutine tasks can be effectively distinguished. Second coroutine tasks are only placed in the multi-priority queue group when they expire, effectively avoiding the situation where batch tasks have not yet reached their execution time, preventing other lower-priority tasks from being executed. Each executor has a built-in scheduler that accesses the storage module corresponding to the target scheduling domain. If an expired second coroutine task exists in the storage module, the expired second coroutine task is mounted to the multi-priority queue group. Coroutine tasks are retrieved from the multi-priority queue group and executed in order of priority. By designing multiple priority queue groups, we ensure that high-priority tasks receive execution resources first, reducing tail latency. During the acquisition and execution of coroutine tasks, the scheduler monitors the operating status and load of each scheduling domain. Based on the operating status and load of each scheduling domain, it migrates tasks between them, improving business robustness and optimizing resource utilization.
[0164] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned coroutine scheduling method embodiments.
[0165] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above-mentioned coroutine scheduling method embodiments when running.
[0166] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.
[0167] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned coroutine scheduling method embodiments are implemented.
[0168] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the steps in any of the above-mentioned coroutine scheduling method embodiments.
[0169] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0170] The above is a detailed introduction to a coroutine scheduling method, apparatus, system, equipment, storage medium and product provided by the present application. This article uses specific examples to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.
Claims
1. A coroutine scheduling method, characterized in that: include: Accessing a storage module corresponding to a target scheduling domain; wherein the target scheduling domain is provided with a multi-priority queue group; the multi-priority queue group is used to store a first coroutine task to be executed in the target scheduling domain; the storage module is used to store a second coroutine task that is periodically executed in the target scheduling domain; the execution period of the first coroutine task is less than the execution period of the second coroutine task; In a case where there is an expired second coroutine task in the storage module, mounting the expired second coroutine task to the multi-priority queue group; Obtain and execute coroutine tasks from the multi-priority queue group in order of priority; During the phase of acquiring and executing the coroutine task, the running status and load status of each scheduling domain are monitored; wherein the target scheduling domain is any one of the scheduling domains; Performing task migration of each scheduling domain according to the operation status and load status of each scheduling domain; The multiple priority queue groups include a high priority queue group, a medium priority queue group and a low priority queue group; The method of obtaining and executing coroutine tasks from the multi-priority queue group in order of priority includes: determining whether there is a high-priority coroutine task in the high-priority queue group; if there is a high-priority coroutine task, giving priority to executing the coroutine tasks stored in each high-priority queue; if there is no high-priority coroutine task, determining the number of tasks in each medium-priority queue according to the total number of tasks contained in the medium-priority queue group and the weight corresponding to each medium-priority queue; executing a corresponding number of coroutine tasks in each medium-priority queue according to the number of tasks in each medium-priority queue; and if the execution authority of the coroutine task in the low-priority queue group is obtained, giving priority to executing the coroutine tasks in the low-priority queue to which it is linked by default.
2. The coroutine scheduling method according to claim 1, wherein: The obtaining and executing the coroutine task from the multi-priority queue group in order of priority includes: Utilizing the executors included in the target scheduling domain, coroutine tasks are obtained and executed from the multi-priority queue group in order of priority.
3. The coroutine scheduling method according to claim 2, wherein: The monitoring of the operating status and load status of each scheduling domain; Performing task migration of each scheduling domain according to the operation status and load status of each scheduling domain includes: Performing status monitoring on the target scheduling domain, the executors contained in the target scheduling domain, and the coroutine tasks executed by the executors, and recording the monitoring time; If the target scheduling domain is in an abnormal state, the coroutine tasks stored in the multi-priority queue group and storage module corresponding to the target scheduling domain are migrated to a scheduling domain that is in a normal state and meets the load requirements; When there is an abnormal target executor, call an executor with normal status from other scheduling domains that meet the load requirements; If there is a target coroutine task with an abnormal status, a coroutine warning message is generated.
4. The coroutine scheduling method according to claim 3, wherein: Before status monitoring of the target scheduling domain, the executors contained in the target scheduling domain, and the coroutine tasks executed by the executors, the method further includes: Determine whether the difference between the current time and the last monitoring time is greater than or equal to the set time threshold; When the difference between the current time and the last monitoring time is greater than or equal to the set time threshold, the operation steps of status monitoring the target scheduling domain, the executor contained in the target scheduling domain and the coroutine task executed by the executor are performed.
5. The coroutine scheduling method according to claim 1, wherein: Executing a corresponding number of coroutine tasks in each medium priority queue according to the number of tasks in each medium priority queue includes: When the number of tasks in the target medium priority queue has not been consumed and the coroutine tasks in the target medium priority queue are empty, the coroutine tasks in the next medium priority queue adjacent to the target medium priority queue are executed; wherein the target medium priority queue is any one of the medium priority queues.
6. The coroutine scheduling method according to claim 5, characterized in that: Also includes: After each round of coroutine tasks in the medium priority queue group is completed, the total number of all remaining coroutine tasks in the medium priority queue group is counted; According to the total number of all remaining coroutine tasks and the corresponding weights of each medium priority queue, the latest number of tasks in each medium priority queue is determined; Execute the corresponding number of coroutine tasks in each medium priority queue according to the latest number of tasks in each medium priority queue until all coroutine tasks in the medium priority queue group are completed.
7. The coroutine scheduling method according to claim 6, characterized in that: Before executing the corresponding number of coroutine tasks in each medium priority queue in sequence according to the latest number of tasks in each medium priority queue, it also includes: When the number of schedulers of the access target medium priority queue reaches the corresponding concurrency number of the target medium priority queue, the coroutine task of the next medium priority queue is selected for execution; if the number of schedulers of all medium priority queues reaches their respective corresponding concurrency numbers, the coroutine task in the low priority queue group is executed; wherein, the scheduler is a module included in the executor in the target scheduling domain, which is used to obtain coroutine tasks from the multi-priority queue group.
8. The coroutine scheduling method according to claim 1, wherein: Also includes: When the number of schedulers accessing the target high-priority queue reaches the concurrency upper limit corresponding to the target high-priority queue, the coroutine task of the next high-priority queue is selected for execution; wherein, the target high-priority queue is any of the high-priority queues; the scheduler is a module included in the executor in the target scheduling domain, which is used to obtain coroutine tasks from the multi-priority queue group.
9. The coroutine scheduling method according to claim 8, characterized in that: Regarding determining the upper limit of the number of concurrent requests, the method further includes: When the number of schedulers accessing the target high priority queue is greater than the number of queues containing tasks, calculating the difference between the number of schedulers accessing the target high priority queue and the number of queues containing tasks; If the difference is less than or equal to the predefined value, the difference is used as the upper limit of the number of concurrent connections. If the difference is greater than the predefined value, the predefined value is used as the upper limit of the number of concurrent requests.
10. The coroutine scheduling method according to claim 9, characterized in that: Also includes: When the average number of schedulers currently accessing all high-priority queues is greater than a predefined value, the coroutine task of the medium-priority queue group is executed.
11. The coroutine scheduling method according to claim 1, wherein: Also includes: When a new coroutine task is received, the new coroutine task is added to a matching position in the multi-priority queue group according to the priority of the new coroutine task.
12. The coroutine scheduling method according to claim 11, characterized in that: The multiple priority queue groups include a high priority queue group, a medium priority queue group and a low priority queue group; The step of adding the new coroutine task to a matching position in the multi-priority queue group according to the priority of the new coroutine task includes: If the new coroutine task is a high-priority coroutine task, add the new coroutine task to a high-priority queue in the high-priority queue group that has the same priority as the new coroutine task; If the new coroutine task is a medium-priority coroutine task, add the new coroutine task to a medium-priority queue in the medium-priority queue group having the same priority as the new coroutine task; In the case that the new coroutine task is a low-priority coroutine task, the new coroutine task is added to the low-priority queue of the low-priority queue group according to a preset low-priority task allocation strategy.
13. The coroutine scheduling method according to claim 12, characterized in that: The step of adding the new coroutine task to the low-priority queue of the low-priority queue group according to a preset low-priority task allocation strategy includes: The new coroutine task is added to the low-priority queue polled this time in a round-robin manner.
14. The coroutine scheduling method according to claim 12, wherein: The step of adding the new coroutine task to the low-priority queue of the low-priority queue group according to a preset low-priority task allocation strategy includes: Statistics on the load of each low-priority queue; Add the new coroutine task to the low-priority queue with the least load.
15. A coroutine scheduling device, characterized in that: Includes access unit, mounting unit, execution unit, monitoring unit and migration unit; The access unit is configured to access a storage module corresponding to a target scheduling domain; wherein the target scheduling domain is configured to have a multi-priority queue group; the multi-priority queue group is configured to store a first coroutine task to be executed in the target scheduling domain; the storage module is configured to store a second coroutine task that is periodically executed in the target scheduling domain; and the execution period of the first coroutine task is shorter than the execution period of the second coroutine task. The mounting unit is configured to mount the expired second coroutine task to the multi-priority queue group when there is an expired second coroutine task in the storage module; The execution unit is used to obtain and execute coroutine tasks from the multi-priority queue group in order of priority; the multi-priority queue group is divided into a high-priority queue group, a medium-priority queue group and a low-priority queue group; it is judged whether there is a high-priority coroutine task in the multi-priority queue group; in the case of a high-priority coroutine task, the coroutine tasks stored in each high-priority queue are executed first; in the case of no high-priority coroutine task, the number of tasks of each medium-priority queue is determined according to the total number of tasks included in the medium-priority queue group and the weight corresponding to each medium-priority queue; the coroutine tasks of the corresponding number of each medium-priority queue are executed in sequence according to the number of tasks in each medium-priority queue; in the case of obtaining the execution authority of the coroutine task in the low-priority queue group, the coroutine tasks in the low-priority queue to which it is linked by default are executed first; The monitoring unit is configured to monitor the running status and load status of each scheduling domain during the phase of acquiring and executing the coroutine task; wherein the target scheduling domain is any one of the scheduling domains; The migration unit is configured to perform task migration for each scheduling domain according to the operation status and load status of each scheduling domain.
16. A coroutine scheduling system, characterized in that: It includes at least one scheduling domain, each scheduling domain has at least one executor, and each executor is bound to at least one processor core; The target scheduling domain is any scheduling domain among the scheduling domains; The target scheduling domain is correspondingly provided with a multi-priority queue group; The multi-priority queue group is used to store the first coroutine task to be executed in the target scheduling domain; A storage module, configured to store a second coroutine task that is periodically executed in the target scheduling domain; wherein the execution period of the first coroutine task is shorter than the execution period of the second coroutine task; The executor is configured to access the storage module; if there is an expired second coroutine task in the storage module, the expired second coroutine task is mounted to the multi-priority queue group; Acquire and execute coroutine tasks from the multi-priority queue group in order of priority; in the stage of acquiring and executing the coroutine tasks, monitor the operating status and load status of each scheduling domain; perform task migration of each scheduling domain according to the operating status and load status of each scheduling domain; divide the multi-priority queue group into a high-priority queue group, a medium-priority queue group and a low-priority queue group; determine whether there is a high-priority coroutine task in the multi-priority queue group; in the case of the existence of a high-priority coroutine task, give priority to executing the coroutine tasks stored in each high-priority queue; in the case of the absence of a high-priority coroutine task, determine the number of tasks of each medium-priority queue according to the total number of tasks contained in the medium-priority queue group and the corresponding weights of each medium-priority queue; execute the corresponding number of coroutine tasks of each medium-priority queue in turn according to the number of tasks of each medium-priority queue; in the case of obtaining the execution permission of the coroutine task in the low-priority queue group, give priority to executing the coroutine tasks in the low-priority queue to which it is linked by default.
17. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the coroutine scheduling method according to any one of claims 1 to 14 when executing the computer program.
18. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the steps of the coroutine scheduling method according to any one of claims 1 to 14 are implemented.
19. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the coroutine scheduling method according to any one of claims 1 to 14 are implemented.
Citation Information
Patent Citations
High-availability task processing control model in parallel computing environment
CN107621978A
Timed task scheduling method and device, equipment and storage medium
CN116820697A
Priority task queue implementation method based on argobots
CN117591262A