Multi-instance task processing method and device based on dynamic scheduling, equipment, storage medium and product

Abstract

The invention discloses a multi-instance task processing method and device based on dynamic scheduling, equipment, a storage medium and a product, and relates to the technical field of computers.The method comprises the steps that in response to a received scheduling request, tasks are dynamically distributed to corresponding task queues according to a scene configuration table, and based on an instance starting instruction of a consumer, the tasks are dynamically distributed to the corresponding task queues; according to the scene configuration and the active condition, calculating a consumption queue which determines that the current consumer should start the actual consumption; and consuming the tasks according to the priorities by utilizing the priorities in the scene configuration table and the dynamic queues recording idle states of the consumption queues. According to the method, independent processing tasks of all scenes do not influence each other through unified codes, the abnormal or blocking influence range is narrowed, the system reliability and stability are improved, and the cost is saved; the scene queues are distinguished through logic distribution, the number of scene instances can be dynamically scaled under the condition that application codes do not need to be modified and deployment does not need to be changed, service idling is avoided through dynamic task consumption, and the resource utilization rate is increased.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device, storage medium and product for processing multiple instance tasks based on dynamic scheduling. Background Technology

[0002] In recent years, with the advancement of technology and the development of computers, many business processes have gradually moved online, and various data or task processing has been handed over to computers. However, due to limited computer resources, high-concurrency, high-input-volume task processing often causes system services to crash.

[0003] Currently, besides the conventional approach of increasing single-machine hardware resources, a common solution is to use a producer-consumer architecture for asynchronous decoupling. The traditional producer-consumer architecture mainly consists of three modules: 1. Producer: Used to receive upstream calls and process them into tasks, placing them in the task queue; 2. Task queue: Used to store task messages for consumers to read and process; 3. Consumer: Used to read and process tasks in a specified queue.

[0004] However, when the same public service provides services to different scenarios (tenants), each scenario usually needs to be independent and unaffected by others, and a unified public service cannot meet the requirements of scenario independence and high availability. To solve this problem, different consumer services are typically deployed separately for each scenario. Each consumer is configured with its own task queue corresponding to the scenario, and tasks from different queues are consumed to achieve isolation and traffic distribution.

[0005] However, the existing technical solutions have the following drawbacks: 1. With the increasing number of integration scenarios and numerous independently deployed services, each service needs to be operated and managed separately, resulting in high operation and maintenance costs; 2. Deploying services independently requires modifying the application configuration before deploying the new system application to production. The deployment work is cumbersome and requires relevant personnel to have certain development and maintenance skills, resulting in high manpower and time costs. 3. The workload of each independently deployed service varies greatly. In some scenarios, there are no idle tasks, while in other scenarios, there are requests piling up and tasks waiting to be processed. The uneven workload of each service results in low resource utilization and high software and hardware costs. Summary of the Invention

[0006] The main purpose of this application is to provide a method, apparatus, device, storage medium and product for processing multiple instances of tasks based on dynamic scheduling, which aims to solve the problems of high cost and waste of manpower and resources caused by deploying independent application services in existing technical solutions.

[0007] To achieve the above objectives, this application proposes a multi-instance task processing method based on dynamic scheduling, the method comprising: In response to receiving the instance start command from a consumer, the system reads the pre-designed scenario configuration table and active queue, and calculates and determines the actual consumption queue that the current consumer should start consuming based on the scenario configuration and activity status. Using the priorities in the scenario configuration table and the dynamic queue that records the idle status of the consumption queue, tasks are consumed according to priority.

[0008] In one embodiment, prior to the step of reading the pre-designed scenario configuration table and active queue in response to receiving an instance launch command from a consumer, the method further includes: In response to receiving a scheduling request, tasks are dynamically distributed to the corresponding task queues according to a pre-designed scenario configuration table for consumption by consumers. The task queues include scenario queues and public queues.

[0009] In one embodiment, the step of dynamically distributing tasks to the corresponding task queues according to a pre-designed scenario configuration table in response to receiving a scheduling request further includes: Design a scenario configuration table, which records at least one of the following: basic information of each scenario, priority, and number of scenario consumption instances.

[0010] In one embodiment, the step of dynamically distributing tasks to corresponding task queues according to a pre-designed scenario configuration table in response to receiving a scheduling request includes: Upon receiving a scheduling request, a judgment is made based on a pre-designed scenario configuration table; If the number of consumption instances in the scenario is greater than 0, then the task corresponding to the scheduling request will be distributed to the corresponding scenario queue. If the number of consumption instances in the scenario is 0, then the task corresponding to the scheduling request will be distributed to a public queue.

[0011] In one embodiment, the step of responding to receiving a consumer instance launch command, reading a pre-designed scenario configuration table and an active queue, and calculating and determining the actual consumption queue that the current consumer should launch based on the scenario configuration and activity status includes: In response to receiving the instance start command from the consumer, the system reads the pre-designed scenario configuration table to obtain each scenario and the corresponding number of scenario consumer instances. Read the pre-designed active queue and count the number of active instances in each scenario; Based on the number of active instances in each scenario and the number of scenario consumption instances corresponding to each scenario, the actual consumption queue that the current consumer should initiate is determined.

[0012] In one embodiment, the active queue is recorded using a Redis ZSet set, which includes several elements. The value of each element is used to identify the scenario that the current instance is consuming, and the score of each element is used to identify the active status of the current instance.

[0013] In one embodiment, the step of reading a pre-designed active queue and counting the number of active instances in each scenario includes: Read the pre-designed active queue, traverse the ZSet collection sequentially, and read the value and score of each element; Get the corresponding scene and the number of scene consumption instances for each scene based on the value of each element; Determine whether the scores corresponding to each instance in the acquired scenario meet the set threshold; If the conditions are met, it means that the currently started instance is active and consuming the scenario; if the conditions are not met, it means that the instance is inactive and will be removed from the active queue. The total number of active instances in the obtained scenario.

[0014] In one embodiment, the step of determining the actual consumption queue that the current consumer should initiate based on the statistically analyzed number of active instances in each scenario and the corresponding number of scenario consumption instances includes: Compare the number of active instances in the current scenario with the number of scenario consumption instances corresponding to the current scenario; If the number of active instances in the current scenario is less than the number of scenario consumption instances corresponding to the current scenario, then the currently started instance is determined to consume the current scenario queue, and the instance is added to the scenario corresponding to the active queue. The score corresponding to the instance is continuously updated within a preset time to complete the instance startup. If the number of active instances in each scenario in the active queue is greater than the number of scenario consumption instances corresponding to the current scenario, then the consumption public queue is started to complete the instance startup.

[0015] In one embodiment, the method further includes: If a consumer starts multiple instances simultaneously, a distributed lock is added during the multi-instance deployment process.

[0016] In one embodiment, the step of consuming tasks according to priority using the priority in the scenario configuration table and a dynamic queue that records the idle status of the consumption queue includes: When consuming in the current instance, the task queue is used to determine whether the consumption queue set for the current instance is idle; If the consumption queue set for the current instance is not idle, then continue consuming from the current consumption queue; If the current instance sets the consumption queue to be idle, then update the idle status of the current consumption queue to 1 to indicate that the current consumption queue is an idle queue. Read the list of idle queues, which includes a dynamic queue that records the idle status of the consumption queues; Read the non-idle queues in the dynamic queue in sequence; Using the priorities in the scenario configuration table, determine the target non-idle queue with the highest priority; Consume at least one task from the target non-idle queue and update the idle status of the target non-idle queue to 0 to identify the target non-idle queue as a non-idle queue.

[0017] Furthermore, to achieve the above objectives, this application also proposes a multi-instance task processing device based on dynamic scheduling, the device comprising: The startup module is used to respond to the received instance startup command of the consumer, read the pre-designed scenario configuration table and active queue, and calculate and determine the actual consumption queue that the current consumer should start consuming based on the scenario configuration and activity status. The consumption module is used to consume tasks according to priority by utilizing the priority in the scenario configuration table and the dynamic queue that records the idle status of the consumption queue.

[0018] In addition, to achieve the above objectives, this application also proposes a multi-instance task processing device based on dynamic scheduling, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the multi-instance task processing method based on dynamic scheduling as described above.

[0019] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the multi-instance task processing method based on dynamic scheduling as described above.

[0020] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the dynamic scheduling-based multi-instance task processing method described above.

[0021] One or more technical solutions proposed in this application have at least the following technical effects: in response to receiving an instance start command from a consumer, a pre-designed scenario configuration table and an active queue are read, and the actual consumption queue to be started by the current consumer is calculated and determined according to the scenario configuration and activity status; using the priority in the scenario configuration table and a dynamic queue that records the idle status of the consumption queue, tasks are consumed according to priority. Compared to existing technologies that require continuous independent deployment of new applications, the technical solution of this application, through pre-designed scenario configuration tables, enables dynamic task distribution without the need for additional application configuration modifications to deploy new applications. Task consumption is achieved simply by adding instances of the same type. This means that the application can use unified code to ensure independent task processing in each scenario, minimizing the impact of anomalies or blockages and improving system reliability and stability. The designed active queue allows consumers to flexibly launch instances, and consumers can use unified code without additional application code modifications, enabling automatic and dynamic consumption of different scenario queues. This eliminates development and deployment processes, saving time required for scenario expansion. Dynamic task consumption avoids service idleness, further improving resource utilization and processing efficiency. Utilizing dynamic consumption instead of creating new applications to consume fixed scenarios ensures scenario independence, eliminating the need for separate deployment for each scenario and further reducing subsequent maintenance time. It avoids the tedious development work caused by independent application deployment, requiring no related development technologies or understanding of implementation details, thus saving labor costs. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart illustrating the first embodiment of the multi-instance task processing method based on dynamic scheduling in this application; Figure 2 This is a schematic diagram illustrating the scenario of task distribution in an embodiment of the multi-instance task processing method based on dynamic scheduling in this application; Figure 3 This is a schematic diagram illustrating a scenario for flexible consumer startup in an embodiment of the multi-instance task processing method based on dynamic scheduling in this application; Figure 4 A schematic diagram illustrating a scenario for implementing task priority consumption in an embodiment of the multi-instance task processing method based on dynamic scheduling provided in this application. Figure 5 This is a flowchart illustrating the second embodiment of the multi-instance task processing method based on dynamic scheduling in this application; Figure 6 This is a schematic diagram of the module structure of a multi-instance task processing device based on dynamic scheduling according to an embodiment of this application; Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the multi-instance task processing method based on dynamic scheduling in the embodiments of this application.

[0025] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0026] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0027] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0028] The main solution of this application embodiment is: in response to receiving the instance start command of the consumer, read the pre-designed scene configuration table and active queue, calculate and determine the actual consumption queue that the current consumer should start consuming based on the scene configuration and activity status; and consume tasks according to priority using the priority in the scene configuration table and the dynamic queue that records the idle status of the consumption queue. This technical solution, through a pre-designed scenario configuration table, enables dynamic task distribution. Unified code ensures independent task processing in each scenario, minimizing the impact of anomalies or blockages and improving system reliability and stability. Logical distribution differentiates scenario queues, allowing dynamic scaling of instance numbers for each scenario without application code modifications or deployment changes, thus improving resource utilization. The designed active queues enable consumers to flexibly launch instances, using unified code to automatically and dynamically consume different scenario queues without additional application code modifications, eliminating development and deployment processes and saving time required for scenario expansion. Dynamic task distribution and consumption prevent service idleness, further improving resource utilization and processing efficiency. Dynamic consumption, rather than creating additional applications to consume fixed scenarios, ensures scenario independence, eliminating the need for separate deployment for each scenario and further reducing subsequent maintenance time. It avoids the tedious development work associated with independent application deployment, requiring no related development technologies or understanding of implementation details, saving labor costs.

[0029] This application embodiment takes into account that when the same public service provides services to different scenarios (tenants), each scenario mostly needs to be independent and not affect each other. However, a unified public service cannot meet the requirements of scenario independence and high availability. In the existing technology, different consumer services are generally deployed separately for each scenario. Each consumer is configured with its own task queue for the corresponding scenario, and consumes tasks from different queues to achieve isolation and traffic distribution. However, the existing technical solutions have the following drawbacks: As the number of connected scenarios increases, there are many independently deployed services. Each service needs to be operated and managed separately, resulting in high operation and maintenance costs. Deploying services independently requires corresponding configuration modifications to the application before deploying the new system application. The deployment work is cumbersome, and relevant personnel need to have certain development and operation and maintenance skills, resulting in high human and time costs. The business volume of each independently deployed service varies greatly. There are situations where some scenarios are idle with no tasks, while other scenarios have a backlog of requests and tasks waiting to be processed. The services are unevenly busy, resulting in low resource utilization and high software and hardware costs.

[0030] Therefore, this application provides a solution that enables independent processing of tasks in each scenario without interference through unified code, reducing the scope of impact from anomalies or blockages and improving system reliability and stability; it distinguishes queues for each scenario through logical distribution, and can dynamically scale the number of instances in each scenario without modifying application code or changing deployment, thereby improving resource utilization; and it avoids service idleness by implementing dynamic distribution and consumption of tasks, further improving resource utilization and processing efficiency, thus solving the problems of high cost and waste of manpower and resources caused by deploying independent application services in existing technical solutions.

[0031] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device, a multi-instance task processing device, system, or device capable of implementing the above functions. The following description uses a multi-instance task processing system based on dynamic scheduling as an example to illustrate the various embodiments.

[0032] Based on this, embodiments of this application provide a multi-instance task processing method based on dynamic scheduling, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the multi-instance task processing method based on dynamic scheduling in this application.

[0033] In this embodiment, the multi-instance task processing method based on dynamic scheduling includes steps S11 to S12. The following provides a detailed explanation of each step.

[0034] like Figure 1 As shown, the first embodiment of this application proposes a multi-instance task processing method based on dynamic scheduling, the method comprising: Step S11: In response to receiving the instance start command from the consumer, read the pre-designed scenario configuration table and active queue, and calculate and determine the actual consumption queue that the current consumer should start based on the scenario configuration and activity status. The technical solution of this embodiment can solve the problems of high cost and waste of manpower and resources caused by deploying independent application services in existing technical solutions.

[0035] The system architecture involved in this embodiment includes three major modules: task distribution, consumer initiation, and task consumption. Their functions can be collectively referred to as the planner. The planner achieves multi-instance collaborative and balanced task processing under a unified code logic through a series of designs and dynamic scheduling of each instance (pod).

[0036] This embodiment mainly focuses on the consumer initiation and task consumption. The technical solution for task distribution will be described in detail in the second embodiment below.

[0037] Specifically, in this embodiment, a scenario configuration table is pre-designed, which records basic information of each scenario, priority, and number of scenario consumption instances (pod-num), etc.

[0038] The number of consumption instances for a scene (pod-num) indicates how many instances (pods) consume the scene when the consumer instance starts. When pod-num=0, it means that the scene is not consumed independently.

[0039] In one feasible implementation, such as Figure 2 As shown, when generating data, producers can determine the appropriate tasks based on preset rules according to the scenario configuration table, and dynamically distribute these tasks to the corresponding task queues for consumer consumption. The task queues include scenario queues and public queues.

[0040] like Figure 2 As shown, producers can dynamically distribute tasks to corresponding task queues, such as the scenario 1 queue, scenario 2 queue, scenario 3 queue, and common queue, based on different scenarios (such as scenario 1, scenario 2, scenario 3, scenario 4, etc.) and the scenario configuration table.

[0041] In one feasible implementation, the planner can also pre-design an active queue.

[0042] like Figure 3 As shown, the active queue is used to record active instances corresponding to different scenarios.

[0043] Specifically, when a consumer needs to process a task, it will launch the corresponding instance and consume the scenario task. When the system receives the consumer's instance launch command, it reads the pre-designed scenario configuration table and active queue. Based on the scenario configuration and activity status, it calculates and determines which actual consumption queue the current consumer should launch, so as to start the consumption queue and consume the task.

[0044] In one feasible implementation, the step of responding to receiving a consumer instance launch command, reading a pre-designed scenario configuration table and active queue, and calculating and determining the actual consumption queue that the current consumer should launch based on the scenario configuration and activity status may include A1-A3: A1, in response to receiving the instance start command from the consumer, reads the pre-designed scenario configuration table to obtain each scenario and the number of corresponding scenario consumer instances; A2 reads the pre-designed active queue and counts the number of active instances in each scenario; A3. Based on the number of active instances in each scenario and the number of scenario consumption instances corresponding to each scenario, determine the actual consumption queue that the current consumer should initiate.

[0045] The active queue is recorded using a Redis ZSet set. The ZSet set includes several elements, each element's value is used to identify the scenario that the current instance is consuming, and each element's score is used to identify the active status of the current instance.

[0046] When the system receives the instance start command from the consumer, it reads the pre-designed scenario configuration table to obtain the number of each scenario and the corresponding number of scenario consumer instances. At the same time, it reads the pre-designed active queue to count the number of active instances in each scenario.

[0047] Specifically, when reading the pre-designed active queue, the ZSet collection is traversed sequentially to read the value and score of each element; the corresponding scene and the number of scene consumption instances for the corresponding scene are obtained based on the value of each element.

[0048] Then, it is determined whether the scores of each instance in the obtained scenario meet the set threshold. If they do, it means that the currently started instance is active and consumes the scenario. If they do not meet the threshold, it means that the instance is inactive and is removed from the active queue. Thus, the total number of active instances in the obtained scenario is counted.

[0049] Then, based on the number of active instances in each scenario and the number of scenario consumption instances corresponding to each scenario, the actual consumption queue that the current consumer should start consuming is determined.

[0050] Specifically, the number of active instances in the current scenario is compared with the number of scenario consumption instances corresponding to the current scenario. If the number of active instances in the current scenario is less than the number of scenario consumption instances corresponding to the current scenario, the instance to be started is determined to consume the current scenario queue, and the instance is added to the scenario corresponding to the active queue. The score corresponding to the instance is continuously updated within a preset time to complete the instance startup. If the number of active instances in each scenario in the active queue is greater than the number of scenario consumption instances corresponding to the current scenario, the consumption public queue is started to complete the instance startup.

[0051] If a consumer starts multiple instances simultaneously, a distributed lock is added during the multi-instance deployment process.

[0052] The following combination Figure 3 This section provides a detailed explanation of the consumer-initiated flexible approach in this step.

[0053] Specifically, planners can design an active queue that dynamically reads the scene configuration table and the active queue when a consumer starts up. Based on the read configuration and activity status, they can calculate and determine the actual scene queue and / or public queue that the current consumer should start consuming, i.e., the consumption queue.

[0054] The core of this design is maintaining the active queue, which is achieved by using Redis's ZSet structure to record the active queue. A ZSet structure is a list of unique values, representing a ZSet collection. Each element contains two data points: a value and a corresponding score. The value identifies the scenario the instance is currently consuming, and the score indicates whether the current instance is active.

[0055] When a consumer instance (pod) starts, the following judgment process is executed. This judgment process is performed simultaneously when each instance (pod) starts. In the multi-instance deployment process, a distributed lock needs to be added to avoid data consistency issues during concurrent startup. The judgment process includes the following steps: Step 1: Read the scenario configuration table and obtain each scenario and its corresponding pod-num (number of scenario consumer instances). Step 2: Read the active queue, iterate through this ZSet collection, read the value and score of each element, and obtain the scene and the corresponding number of pods based on the value. Repeat Step 3-Step 5 for each scene. Step 3: Determine whether the score of each pod in the obtained scenario meets the set threshold (current timestamp ≤ the score). If it meets the threshold, it means that the current pod is active and consuming the scenario. If it does not meet the threshold, it means that the pod is inactive and is removed from the active queue. Step 4: Count the total number of active pods in the obtained scenario (i.e., ...) Figure 3 The active-num shown is compared with the target value pod-num in the scene configuration table. If it is less than the target value pod-num, then Step 4-1 and Step 4-2 are executed (e.g., ...). Figure 3 If the number of active pods in both Scenario 1 and Scenario 3 is less than the target value pod-num, then the corresponding Scenario 1 queue and Scenario 3 queue will be started, and the pod will be added to the corresponding scenario in the active queue. If the number of pods in each scenario in the active queue is greater than or equal to the scenario configuration value, then it means that there are already active instances of the configured number consuming the corresponding scenario queue, and Step 5 will be executed. Step 4-1: The pod consumes the queue for this scenario, and the pod is added to the corresponding scenario in the active queue, and the score is updated; Step 4-2: Enable heartbeat updates. The score is continuously updated within a certain period of time to indicate that the current pod is active. The score is set to a timestamp of the current time plus the effective time when the startup is completed and when the heartbeat is updated. If the instance restarts or stops due to an abnormality, the active queue can dynamically detect the inactivity and automatically recover, and the pod will start up. Step 5: Start the consumer public queue. The pod has now started.

[0056] Step S12: Using the priority in the scenario configuration table and the dynamic queue that records the idle status of the consumption queue, consume tasks according to priority.

[0057] Specifically, during task consumption, this embodiment configures a dynamic queue that records the idle status of the consumption queue, such as... Figure 4 As shown, the dynamic queue can be represented by an idle queue list, which includes different scenarios, as well as the idle status and priority corresponding to each scenario.

[0058] The idle state value corresponding to the scenario is used to identify whether the current consumption queue is an idle queue or a non-idle queue. For example, an idle state value of 1 indicates that the current consumption queue is an idle queue, and an idle state value of 0 indicates that the current consumption queue is a non-idle queue.

[0059] Specifically, after calculating and determining which consumption queue (including the scene queue and / or the public queue) the current consumer should start consuming, the instance starts up and can consume the corresponding task in the task queue.

[0060] In one feasible implementation, when the current instance is consuming, it is determined whether the consumption queue set for the current instance to consume is idle, based on the task queue generated by the producer; if the consumption queue set for the current instance to consume is not idle, then the current consumption queue is consumed.

[0061] If the current instance's consumption queue is set to idle (i.e., there are no tasks in the queue), the idle status of the current consumption queue is updated to 1 to indicate that the current consumption queue is an idle queue. The system reads the list of idle queues (queries dynamic queues), which includes dynamic queues that record the idle status of consumption queues. The system then reads the non-idle queues in the dynamic queues in turn and uses the priority in the scenario configuration table to determine the target non-idle queue with the highest priority.

[0062] After determining the target non-idle queue with the highest priority, at least one task in the target non-idle queue can be consumed, and the idle status of the target non-idle queue can be updated to 0 to identify the target non-idle queue as a non-idle queue.

[0063] The following combination Figure 4 The task priority consumption scheme in this step will be explained in detail.

[0064] More specifically, such as Figure 4 As shown, the priority in the scenario configuration table and the dynamic queue that records the idle status of the consumption queue are used to realize the consumption of tasks in the idle queue according to priority.

[0065] In this case, the priority of the public queue is 0.

[0066] The dynamic queue records the idle status of the consumption queue, which is reflected in the idle queue list, including idle queues and non-idle queues.

[0067] In practice, if each pod finds its designated consumption queue to be empty (i.e., it reads that there are no tasks in its own queue), it can perform the following steps: Step 1: Update the idle status of the current scene queue to 1, marking the current scene queue as an idle queue; Step 2: The pod reads the list of idle queues, and then reads all the non-idle queues in the dynamic queue in turn; Step 3: Determine if the priority of the target non-idle scene queue is greater. If the priority of the target non-idle scene queue is smaller than that of the current scene, skip and determine the next non-idle scene queue. If the priority of the target non-idle scene queue is greater, proceed to Step 4. Step 4: Update the idle status of the target non-idle scene queue to 0, and consume 1 task from the higher priority scene queue.

[0068] In this embodiment, the above-described scheme specifically involves responding to a consumer's instance launch command by reading a pre-designed scenario configuration table and an active queue. Based on the scenario configuration and activity status, it calculates and determines the actual consumption queue that the current consumer should launch. Using the priorities in the scenario configuration table and a dynamic queue that records the idle status of the consumption queue, tasks are consumed according to priority. Compared to existing technologies that require continuous independent deployment of new applications, the technical solution in this application, through pre-designed scenario configuration tables, enables dynamic task distribution without the need for additional application configuration modifications to deploy new applications. Task consumption is achieved simply by adding instances of the same type. This allows for independent task processing in each scenario through unified code, minimizing the impact of anomalies or blockages and improving system reliability and stability. The designed active queues enable consumers to flexibly launch instances, and consumers can use unified code without additional application code modifications, achieving automatic and dynamic consumption of different scenario queues. This eliminates development and deployment processes, saving time required for scenario expansion. Dynamic task consumption avoids service idleness, further improving resource utilization and processing efficiency. Utilizing dynamic consumption instead of creating new applications to consume fixed scenarios ensures scenario independence, eliminating the need for separate deployment for each scenario and further reducing subsequent maintenance time. It avoids the tedious development work caused by independent application deployment, requiring no related development technologies or understanding of implementation details, thus saving labor costs.

[0069] like Figure 5 As shown, the second embodiment of this application proposes a multi-instance task processing method based on dynamic scheduling. In step S11, before reading the pre-designed scenario configuration table and active queue in response to receiving the consumer's instance start instruction, the method further includes: Step S10: In response to receiving a scheduling request, tasks are dynamically distributed to the corresponding task queues according to a pre-designed scenario configuration table for consumption by consumers. The task queues include scenario queues and public queues.

[0070] Compared to the first embodiment described above, this embodiment also includes a technical solution for dynamic task distribution.

[0071] Furthermore, before step S10, which involves dynamically distributing tasks to the corresponding task queues according to a pre-designed scenario configuration table in response to receiving a scheduling request, the following steps are also included: Step S100: Design a scenario configuration table, which records at least one of the following: basic information of each scenario, priority, and number of scenario consumption instances.

[0072] In one feasible implementation, the step of dynamically distributing tasks to corresponding task queues according to a pre-designed scenario configuration table in response to receiving a scheduling request includes: Upon receiving a scheduling request, a judgment is made based on a pre-designed scenario configuration table; If the number of consumption instances in the scenario is greater than 0, then the task corresponding to the scheduling request will be distributed to the corresponding scenario queue. If the number of consumption instances in the scenario is 0, then the task corresponding to the scheduling request will be distributed to a public queue.

[0073] In one feasible implementation, such as Figure 2 As shown, planners can design a scenario configuration table, which records basic information about each scenario, its priority, and the number of pod-nums that consume each scenario.

[0074] The number of consumption instances for a scene (pod-num) indicates how many instances (pods) consume the scene when the consumer instance starts. When pod-num=0, it means that the scene is not consumed independently.

[0075] When generating data, producers can determine the appropriate tasks based on preset rules according to the scenario configuration table, and dynamically distribute these tasks to the corresponding task queues for consumer consumption. The task queues include scenario queues and public queues.

[0076] like Figure 2 As shown, producers can generate tasks based on different scenarios (such as scenario 1, scenario 2, scenario 3, scenario 4, etc.), combined with the scenario configuration table, according to preset rules, and dynamically distribute the tasks to the corresponding task queues, such as scenario 1 queue, scenario 2 queue, scenario 3 queue, and common queue.

[0077] The preset rules can be as follows: If the pod-num of a scenario is greater than 0, it means that the scenario needs an independent queue, and the tasks will be distributed to the queue of the corresponding scenario. If pod-num ≤ 0 for a scenario, it means that the scenario does not require a separate queue and the tasks are distributed to a public queue.

[0078] In this embodiment, the above-described scheme specifically involves responding to a scheduling request by dynamically distributing tasks to corresponding task queues according to a pre-designed scenario configuration table for consumer consumption; responding to a consumer instance start command by reading the pre-designed scenario configuration table and active queues; and calculating and determining the actual consumption queue that the current consumer should start consuming based on the scenario configuration and activity status. The scheme also utilizes the priorities in the scenario configuration table and a dynamic queue recording the idle status of consumption queues to consume tasks according to priority. This technical solution, through pre-designed scenario configuration tables, enables dynamic task distribution and allows each scenario to process tasks independently without interference, minimizing the impact of anomalies or blockages and improving system reliability and stability. Logical distribution differentiates queues for each scenario, allowing dynamic scaling of instance numbers for each scenario without application code modifications or deployment changes, thus improving resource utilization. Dynamic task distribution and consumption prevent service idleness, further enhancing resource utilization and processing efficiency. Consumers use unified code, eliminating the need for additional application code modifications and enabling automatic dynamic consumption of different scenario queues, saving development and deployment time and reducing the time required for scenario expansion. It avoids the tedious development work caused by independent application deployment, requiring no related development skills or understanding of implementation details, saving manpower costs. Dynamic consumption, rather than creating additional applications to consume fixed scenarios, ensures scenario independence, eliminating the need for separate deployment for each scenario and further reducing subsequent maintenance time. This solves the problem of high maintenance costs caused by the continuous independent deployment of new applications for scenario expansion. It also addresses the issue of queue consumption relying on independently deployed services requiring development and maintenance personnel, resulting in tedious deployment work and wasted time and manpower. Finally, it resolves the problem of uneven workload and resource waste among application services after independent deployment.

[0079] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the multi-instance task processing method based on dynamic scheduling in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0080] In addition, such as Figure 6 As shown, this application also proposes a multi-instance task processing device based on dynamic scheduling, the device comprising: The startup module 20 is used to respond to the received instance startup command of the consumer, read the pre-designed scenario configuration table and active queue, and calculate and determine the actual consumption queue that the current consumer should start based on the scenario configuration and activity status. The consumption module 30 is used to consume tasks according to priority by utilizing the priority in the scenario configuration table and the dynamic queue that records the idle status of the consumption queue.

[0081] Furthermore, the device may also include: The distribution module 10 is used to respond to a received scheduling request and dynamically distribute tasks to the corresponding task queues according to a pre-designed scenario configuration table for consumers to consume. The task queues include scenario queues and public queues.

[0082] Furthermore, the device may also include: The configuration module is used to design the scenario configuration table, which records at least one of the following: basic information of each scenario, priority, and number of scenario consumption instances.

[0083] The multi-instance task processing device based on dynamic scheduling provided in this application adopts the multi-instance task processing method based on dynamic scheduling in the above embodiments. It can achieve independent task processing in each scenario without mutual interference through unified code, reducing the scope of impact from anomalies or blockages and improving system reliability and stability. By logically distributing and differentiating queues for each scenario, the number of instances in each scenario can be dynamically scaled up or down without modifying application code or changing deployment, improving resource utilization. By implementing dynamic task distribution and consumption, service idleness is avoided, further improving resource utilization and processing efficiency. Consumers use unified code, eliminating the need for additional application code modifications, and automatically and dynamically consuming queues from different scenarios, saving development and deployment processes and time required for scenario expansion. It avoids the cumbersome development work caused by independent application deployment, requiring no related development technology or understanding of implementation details, saving manpower costs. It utilizes dynamic consumption instead of creating additional application consumption. Compared with the prior art, the beneficial effects of the multi-instance task processing device based on dynamic scheduling provided in this application are the same as those of the multi-instance task processing method based on dynamic scheduling provided in the above embodiments, and other technical features in the multi-instance task processing device based on dynamic scheduling are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0084] In addition, to achieve the above objectives, this application also proposes a multi-instance task processing device based on dynamic scheduling, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the multi-instance task processing method based on dynamic scheduling as described above.

[0085] The following is for reference. Figure 7This document illustrates a structural diagram of a dynamically scheduled multi-instance task processing device suitable for implementing embodiments of this application. The dynamically scheduled multi-instance task processing device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The illustrated multi-instance task processing device based on dynamic scheduling is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0086] like Figure 7 As shown, a dynamically scheduled multi-instance task processing device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the dynamically scheduled multi-instance task processing device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the dynamically scheduled multi-instance task processing device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows a dynamically scheduled multi-instance task processing device with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0087] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0088] The multi-instance task processing device based on dynamic scheduling provided in this application adopts the multi-instance task processing method based on dynamic scheduling in the above embodiments. It can achieve independent task processing in each scenario without mutual interference through unified code, reducing the scope of impact from anomalies or blockages and improving system reliability and stability. By logically distributing and differentiating queues for each scenario, the number of instances in each scenario can be dynamically scaled up or down without modifying application code or changing deployment, improving resource utilization. By implementing dynamic task distribution and consumption, service idleness is avoided, further improving resource utilization and processing efficiency. Consumers use unified code, eliminating the need for additional application code modifications, and automatically and dynamically consuming queues from different scenarios, saving development and deployment processes and time required for scenario expansion. It avoids the cumbersome development work caused by independent application deployment, requiring no related development technology or understanding of implementation details, saving manpower costs. It utilizes dynamic consumption instead of creating additional application consumption. Compared with the prior art, the beneficial effects of the multi-instance task processing device based on dynamic scheduling provided in this application are the same as those of the multi-instance task processing method based on dynamic scheduling provided in the above embodiments, and other technical features in this multi-instance task processing device based on dynamic scheduling are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0089] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0090] In addition, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the multi-instance task processing method based on dynamic scheduling as described above.

[0091] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems 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 or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0092] The aforementioned computer-readable storage medium may be included in a dynamically scheduled multi-instance task processing device; or it may exist independently and not be assembled into a dynamically scheduled multi-instance task processing device.

[0093] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a dynamically scheduled multi-instance task processing device, the dynamically scheduled multi-instance task processing device: upon receiving a scheduling request, dynamically distributes tasks to corresponding task queues according to a pre-designed scenario configuration table for consumer consumption; upon receiving an instance start instruction from a consumer, reads the pre-designed scenario configuration table and active queues, and calculates and determines the actual consumption queue that the current consumer should start consuming based on the scenario configuration and activity status; and consumes tasks according to priority using the priorities in the scenario configuration table and the dynamic queues that record the idle status of the consumption queues.

[0094] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0095] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0096] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0097] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described multi-instance task processing method based on dynamic scheduling. This allows for independent task processing in each scenario without interference through unified code, reducing the impact of anomalies or blockages and improving system reliability and stability. By logically distributing and differentiating queues for each scenario, the number of instances in each scenario can be dynamically scaled without modifying application code or changing deployment, improving resource utilization. Dynamic task distribution and consumption avoid service idleness, further improving resource utilization and processing efficiency. Consumers use unified code, eliminating the need for additional application code modifications, and automatically and dynamically consuming queues from different scenarios, saving development and deployment processes and time required for scenario expansion. It avoids the cumbersome development work caused by independent application deployment, requiring no related development technology or understanding of implementation details, saving manpower costs. It utilizes dynamic consumption instead of creating additional application consumption mechanisms. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the multi-instance task processing method based on dynamic scheduling provided in the above embodiments, and will not be repeated here.

[0098] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the dynamic scheduling-based multi-instance task processing method described above.

[0099] The computer program product provided in this application enables independent task processing in each scenario through unified code, minimizing the impact of anomalies or blockages and improving system reliability and stability. By logically distributing queues for each scenario, the number of instances in each scenario can be dynamically scaled up or down without modifying application code or changing deployment, improving resource utilization. Dynamic task distribution and consumption avoid service idleness, further improving resource utilization and processing efficiency. Consumers use unified code, eliminating the need for additional application code modifications, and automatically and dynamically consuming queues from different scenarios, saving development and deployment processes and time required for scenario expansion. It avoids the cumbersome development work caused by independent application deployment, requiring no related development technology or understanding of implementation details, saving labor costs. It utilizes dynamic consumption instead of creating additional application consumption mechanisms. Compared with existing technologies, the beneficial effects of the computer program product provided in this application are the same as those of the multi-instance task processing method based on dynamic scheduling provided in the above embodiments, and will not be repeated here.

[0100] The one or more technical solutions proposed in this application have at least the following technical effects: Upon receiving a scheduling request, tasks are dynamically distributed to corresponding task queues according to a pre-designed scenario configuration table for consumer consumption; upon receiving an instance start command from a consumer, the pre-designed scenario configuration table and active queues are read, and the actual consumption queue to be started by the current consumer is calculated based on the scenario configuration and activity status; tasks are consumed according to priority using the priority in the scenario configuration table and a dynamic queue recording the idle status of the consumption queues. Compared to existing technologies that require continuous independent deployment of new applications, the technical solutions of this application, through a pre-designed scenario configuration table, can achieve dynamic task distribution without requiring additional modifications to the application configuration to deploy new applications. Task consumption is achieved simply by adding instances of the same type, enabling independent task processing in each scenario through unified code, reducing the impact of anomalies or blockages, and improving system reliability and stability; by logically distributing and differentiating scenario queues, the number of instances in each scenario can be dynamically scaled without modifying the application code or changing the deployment, improving resource utilization; by implementing dynamic task distribution and consumption, service idleness is avoided, further improving resource utilization and processing efficiency; consumers use unified code, requiring no additional modifications to the application... This system uses code to automatically and dynamically consume queues from different scenarios, eliminating the need for development and deployment processes and saving time required for scenario expansion. It avoids the tedious development work caused by independently deploying applications, requiring no related development skills or understanding of implementation details, thus saving manpower costs. By using dynamic consumption instead of creating additional applications to consume fixed scenarios, each scenario can be independent, eliminating the need for separate deployment for each scenario and further reducing subsequent maintenance time. This solves the problem of high maintenance costs caused by the need to continuously deploy new applications independently for scenario expansion. It also solves the problem of queue consumption relying on independently deployed services that require development and maintenance personnel, resulting in tedious deployment work and wasted time and manpower. Finally, it solves the problem of uneven workload and resource waste among application services after independent deployment.

[0101] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A multi-instance task processing method based on dynamic scheduling, characterized in that, The method includes: In response to receiving the instance start command from a consumer, the system reads the pre-designed scenario configuration table and active queue, and calculates and determines the actual consumption queue that the current consumer should start consuming based on the scenario configuration and activity status. Using the priorities in the scenario configuration table and the dynamic queue that records the idle status of the consumption queue, tasks are consumed according to priority.

2. The method as described in claim 1, characterized in that, Before the step of reading the pre-designed scenario configuration table and active queue in response to receiving the consumer's instance launch command, the method further includes: In response to receiving a scheduling request, tasks are dynamically distributed to the corresponding task queues according to a pre-designed scenario configuration table for consumption by consumers. The task queues include scenario queues and public queues.

3. The method as described in claim 2, characterized in that, Before the step of dynamically distributing tasks to the corresponding task queues according to a pre-designed scenario configuration table in response to receiving a scheduling request, the following steps are also included: Design a scenario configuration table, which records at least one of the following: basic information of each scenario, priority, and number of scenario consumption instances.

4. The method as described in claim 3, characterized in that, The step of dynamically distributing tasks to the corresponding task queues according to a pre-designed scenario configuration table in response to a received scheduling request includes: Upon receiving a scheduling request, a judgment is made based on a pre-designed scenario configuration table; If the number of consumption instances in the scenario is greater than 0, then the task corresponding to the scheduling request will be distributed to the corresponding scenario queue. If the number of consumption instances in the scenario is 0, then the task corresponding to the scheduling request will be distributed to a public queue.

5. The method as described in claim 3, characterized in that, The steps of responding to a consumer instance launch command, reading a pre-designed scenario configuration table and active queue, and calculating and determining the actual consumption queue that the current consumer should launch based on the scenario configuration and activity status include: In response to receiving the instance start command from the consumer, the system reads the pre-designed scenario configuration table to obtain each scenario and the corresponding number of scenario consumer instances. Read the pre-designed active queue and count the number of active instances in each scenario; Based on the number of active instances in each scenario and the number of scenario consumption instances corresponding to each scenario, the actual consumption queue that the current consumer should initiate is determined.

6. The method as described in claim 5, characterized in that, The active queue is recorded through a Redis ZSet set. The ZSet set includes several elements, the value of which is used to identify the scenario that the current instance is consuming, and the score of which is used to identify the active status of the current instance.

7. The method as described in claim 6, characterized in that, The steps of reading the pre-designed active queue and counting the number of active instances in each scenario include: Read the pre-designed active queue, traverse the ZSet collection sequentially, and read the value and score of each element; Get the corresponding scene and the number of scene consumption instances for each scene based on the value of each element; Determine whether the scores corresponding to each instance in the acquired scenario meet the set threshold; If the conditions are met, it means that the currently started instance is active and consuming the scenario; if the conditions are not met, it means that the instance is inactive and will be removed from the active queue. The total number of active instances in the obtained scenario.

8. The method as described in claim 7, characterized in that, The step of determining the actual consumption queue that the current consumer should initiate based on the number of active instances in each scenario and the number of consumption instances corresponding to each scenario includes: Compare the number of active instances in the current scenario with the number of scenario consumption instances corresponding to the current scenario; If the number of active instances in the current scenario is less than the number of scenario consumption instances corresponding to the current scenario, then the currently started instance is determined to consume the current scenario queue, and the instance is added to the scenario corresponding to the active queue. The score corresponding to the instance is continuously updated within a preset time to complete the instance startup. If the number of active instances in each scenario in the active queue is greater than the number of scenario consumption instances corresponding to the current scenario, then the consumption public queue is started to complete the instance startup.

9. The method as described in claim 8, characterized in that, The method further includes: If a consumer starts multiple instances simultaneously, a distributed lock is added during the multi-instance deployment process.

10. The method according to any one of claims 3-9, characterized in that, The step of consuming tasks according to priority using the priority in the scenario configuration table and the dynamic queue that records the idle status of the consumption queue includes: When consuming in the current instance, the task queue is used to determine whether the consumption queue set for the current instance is idle; If the consumption queue set for the current instance is not idle, then continue consuming from the current consumption queue; If the current instance sets the consumption queue to be idle, then update the idle status of the current consumption queue to 1 to indicate that the current consumption queue is an idle queue. Read the list of idle queues, which includes a dynamic queue that records the idle status of the consumption queues; Read the non-idle queues in the dynamic queue in sequence; Using the priorities in the scenario configuration table, determine the target non-idle queue with the highest priority; Consume at least one task from the target non-idle queue and update the idle status of the target non-idle queue to 0 to identify the target non-idle queue as a non-idle queue.

11. A multi-instance task processing device based on dynamic scheduling, characterized in that, The device includes: The startup module is used to respond to the received instance startup command of the consumer, read the pre-designed scenario configuration table and active queue, and calculate and determine the actual consumption queue that the current consumer should start consuming based on the scenario configuration and activity status. The consumption module is used to consume tasks according to priority by utilizing the priority in the scenario configuration table and the dynamic queue that records the idle status of the consumption queue.

12. A multi-instance task processing device based on dynamic scheduling, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the dynamic scheduling-based multi-instance task processing method as described in any one of claims 1 to 10.

13. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the multi-instance task processing method based on dynamic scheduling as described in any one of claims 1 to 10.

14. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the dynamic scheduling-based multi-instance task processing method as described in any one of claims 1 to 10.

Images