Task resource scheduling method and device based on containerized environment and storage medium

Abstract

The invention relates to the technical field of computer-aided engineering, and provides a task resource scheduling method based on a containerized environment, and the method comprises the steps: receiving a target task and attribute information thereof, the attribute information of the target task comprising a type, a resource demand condition and a priority of the target task; according to the attribute information of the target task, calculating cost required for solving the target task is evaluated; according to the attribute information of the target task and / or the calculation cost required for solving the target task, distributing the target task to a container instance corresponding to the calculation cost required for solving the target task for processing; monitoring operation conditions of the nodes and the container instances in real time; and according to the attribute information of the to-be-solved task and the running conditions of the node and the container instance, dynamically adjusting the established allocation of the to-be-solved task in the container instance. According to the technical scheme, stable operation of the system, quick response to the to-be-solved task and reasonable and efficient utilization of resources can be guaranteed.

Description

Technical Field

[0001] The present invention relates to the field of computer-aided engineering technology, and in particular to a task resource scheduling method, device and storage medium based on a containerized environment. Background Art

[0002] Solving as a Service is an application of cloud computing and service-oriented architecture, which aims to help users solve complex optimization and computing problems by providing solvers and computing resources. In the field of solving services, existing application architectures usually implement clustered deployment based on virtual machine environments to support collaborative work between services. However, with the growth of computing needs, existing application architectures have shown many challenges in resource scheduling, including: insufficient support for large-scale parallel computing due to unreasonable resource allocation, the risk of system crash caused by resource competition, and the impact of solver failures on the entire system, etc. Summary of the invention

[0003] The present application provides a task resource scheduling method, device and storage medium based on a containerized environment, which can ensure stable operation of the system, rapid response to tasks to be solved, and reasonable and efficient use of resources.

[0004] On the one hand, the present application provides a task resource scheduling method based on a containerized environment, the method comprising:

[0005] Receiving a target task and its attribute information, wherein the attribute information of the target task includes the type, resource requirement and priority of the target task;

[0006] According to the attribute information of the target task, evaluating the computational cost required to solve the target task;

[0007] According to the attribute information of the target task and / or the computational cost required to solve the target task, the target task is assigned to a container instance corresponding to the computational cost required to solve the target task for processing;

[0008] Monitor the operating status of nodes and container instances in real time;

[0009] According to the attribute information of the task to be solved and the running status of the node and the container instance, the established allocation of the task to be solved in the container instance is dynamically adjusted, and the task to be solved includes the newly received task and the target task.

[0010] On the other hand, the present application provides a task resource scheduling device based on a containerized environment, the device comprising:

[0011] A receiving module, used for receiving a target task and its attribute information, wherein the attribute information of the target task includes the type, resource requirement and priority of the target task;

[0012] An evaluation module, used to evaluate the computational cost required to solve the target task according to the attribute information of the target task;

[0013] A first scheduling module, configured to allocate the target task to a container instance corresponding to the computing cost required to solve the target task for processing according to the attribute information of the target task and / or the computing cost required to solve the target task;

[0014] Monitoring module, used to monitor the operating status of nodes and container instances in real time;

[0015] The second scheduling module is used to dynamically adjust the established allocation of the tasks to be solved in the container instance according to the attribute information of the tasks to be solved and the operating conditions of the nodes and container instances, wherein the tasks to be solved include the newly received tasks and the target tasks.

[0016] In a third aspect, the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the steps of the technical solution of the task resource scheduling method based on a containerized environment are implemented.

[0017] In a fourth aspect, the present application provides a storage medium storing a computer program, which, when executed by a processor, implements the steps of the technical solution of the task resource scheduling method based on a containerized environment as described above.

[0018] From the technical solution provided by the present application, it can be seen that, on the one hand, after evaluating the computational cost required to solve the target task, the target task is allocated to the container instance corresponding to the computational cost required to solve the target task, which not only ensures the system's rapid response and efficient processing of the task to be solved, but also improves the utilization rate of resources; on the other hand, by real-time monitoring of the operating status of the container instance, the established allocation of the task to be solved in the container instance is dynamically adjusted according to the attribute information of the task to be solved and the operating status of the container instance, which means that when the operating status of the container instance is not good (for example, a node failure occurs, the load is too heavy, etc.), the task to be solved can be quickly transferred, thereby ensuring the load balancing and stable operation of the system. In summary, compared with the prior art, the technical solution of the present application can ensure the stable operation of the system, rapid response to the task to be solved, and reasonable and efficient use of resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. 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 paying creative work.

[0020] Figure 1 is a flowchart of a task resource scheduling method based on a containerized environment provided by an embodiment of the present application;

[0021] Figure 2 It is a structural diagram of a task resource scheduling device based on a containerized environment provided in an embodiment of the present application;

[0022] Figure 3 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0023] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0024] In this specification, adjectives such as first and second may be used only to distinguish one element or action from another element or action, without necessarily requiring or implying any actual such relationship or order. Where circumstances permit, reference to an element or component or step (etc.) should not be interpreted as being limited to only one of the elements, components, or steps, but may be one or more of the elements, components, or steps, etc.

[0025] In this specification, for the convenience of description, the sizes of various parts shown in the drawings are not drawn according to the actual proportional relationship.

[0026] Solving as a Service is an application of cloud computing and service-oriented architecture, which aims to help users solve complex optimization and computing problems by providing solvers and computing resources. In the field of solving services, existing application architectures usually implement clustered deployment based on virtual machine environments to support collaborative work between services. However, with the growth of computing needs, existing application architectures have shown many challenges in resource scheduling, including: insufficient support for large-scale parallel computing due to unreasonable resource allocation, the risk of system crash caused by resource competition, and the impact of solver failures on the entire system, etc.

[0027] In view of the above problems in the prior art, this application proposes a task resource scheduling method based on a containerized environment, and its flow chart is shown in the attached figure. Figure 1 As shown, it mainly includes steps S101 to S105, which are described in detail as follows:

[0028] Step S101: receiving a target task and its attribute information, wherein the attribute information of the target task includes the type of the target task, resource requirements and priority.

[0029] In the embodiment of the present application, the target task is a task submitted by the client and needs to be solved by the solver, such as the calculation and optimization of rigid bodies and flexible bodies. When the client submits the target task to the task manager, it will be accompanied by attribute information such as the type, resource requirements and priority of the target task, wherein the type of the target task refers to the characteristic or type of the current solving task, such as a rigid body solving task, a flexible body solving task, etc., the resource requirements refer to which computing resources (such as CPU, memory, etc.) are required to execute the target task and how many computing resources are required, etc., and the priority refers to the priority or urgency of the target task, that is, the target task with a high priority or urgency is expected to be solved first, otherwise, it can be arranged to be solved later.

[0030] Step S102: Evaluate the computational cost required to solve the target task based on the attribute information of the target task.

[0031] In the embodiment of the present application, according to the attribute information of the target task, the computational cost required to evaluate the solution of the target task is mainly to evaluate the computational cost such as the amount of resources required to solve the target task and the length of time required according to the type of the target task. As mentioned above, the target task can be a rigid body solution task, a flexible body solution task, and the like. The so-called rigid body solution task refers to the premise that the shape and volume of the object do not change, and the motion and mechanical behavior of the object under the action of external forces are calculated, including the kinematics and dynamics of mechanical parts, the evaluation of the response of buildings or bridges under loads, and the simulation of collisions between rigid objects in computer graphics and game development, etc. The flexible body solution task refers to the calculation of the deformation and response of the object under the action of external forces based on the assumption that the object has elasticity, plasticity and other material properties, including the study of the stress and deformation of materials under different conditions, the simulation of the mechanical behavior of biological tissues or organs, and the design and analysis of robots with flexible structures, etc. From the dimensions of computational complexity, degrees of freedom and mesh refinement, time step and stability, and solution algorithm, since the flexible body solution task involves the deformation, elasticity and plasticity of the material, more complex mathematical modeling and numerical calculation are required. The response of the flexible body usually depends on the solution of a nonlinear equation group, while the state of the rigid body solution can be calculated by simple kinematic and dynamic formulas; when simulating a flexible body, it is usually necessary to subdivide the mesh of the object to accurately capture the deformation and stress distribution, while the rigid body solution task usually does not require mesh refinement and the calculation process is relatively direct; in dynamic simulation, in order to ensure numerical stability, the solution of the flexible body may require a smaller time step, while the time step can usually be selected to be larger when solving the rigid body, thereby speeding up the calculation; and the solution algorithms commonly used in the flexible body solution task (for example, the finite element method) are particularly time-consuming when dealing with large deformations or complex contacts, while the rigid body solution usually only requires simple collision detection and analytical solution methods with high computational efficiency. The resources required for the flexible body solution task are far more than those required for the rigid body solution task, and the time consumption is also longer. Therefore, in an embodiment of the present application, if the type of the target task is a rigid body solving task according to the attribute information carried by the target task, then the resource consumption required for evaluating the rigid body solving task is small and the time consumption is short; conversely, if the target task is a flexible body solving task according to the attribute information carried by the target task, then the resource consumption required for evaluating the flexible body solving task is large and the time consumption is long.

[0032] It should be noted that when the client submits the target task to the task manager, the accompanying attribute information may also include the resource requirements of the target task. Therefore, the computational cost required to solve the target task can also be directly evaluated based on the resource requirements of the target task. However, when evaluating, resources should not be configured completely according to the resource requirements of the target task, and it is necessary to consider adding some margins appropriately according to the situation. For example, the resource requirements of the target task indicate that solving the target task only requires computing resources of 14-core CPU and 30G memory and a duration of 2 hours. Then it can be evaluated that the computational cost required to solve the target task is computing resources of 16-core CPU and 32G memory and a duration of 3 hours. Especially when the target task is a flexible body solving task, it is even more necessary to appropriately consider increasing the margin of resources and time consumption on the basis of the resource requirements of the target task specified by the client.

[0033] Step S103: according to the attribute information of the target task and / or the computational cost required to solve the target task, the target task is assigned to a container instance corresponding to the computational cost required to solve the target task for processing.

[0034] In an embodiment of the present application, two types of container instances may be provided, namely, container instances in a container cluster environment (ContainerCluster Environment, CCE) and container instances in a container cloud instance (Container Cloud Instance, CCI). CCE is usually composed of multiple nodes (servers), and multiple containers are running on each node. CCE provides a complete set of tools and services for managing the life cycle of containers, such as scheduling, load balancing, automatic scaling, etc., while CCI is usually composed of lightweight container instances running on the cloud. Compared with CCI, CCE contains resident container instances. Since CCE contains resident container instances, it means that some of the container instances are idle. Considering that starting and destroying containers still requires a certain amount of time and resources, and when resident container instances are idle in the system, using these idle resources to process tasks with low resource consumption and short time consumption can improve resource utilization. Therefore, after evaluating the computational cost required to solve the target task, the target task is assigned to the container instance corresponding to the computational cost required to solve the target task according to the computational cost required to solve the target task. The processing can be: if the evaluation of the rigid body solution task requires less resource consumption and a shorter time, the rigid body solution task is assigned to CCE and processed by the resident container instance in CCE; if the evaluation of the flexible body solution task requires more resource consumption and a longer time, the flexible body solution task is assigned to the container cloud instance CCI and processed by the container instance in CCI.

[0035] As mentioned above, the attribute information of the target task includes the type of the target task, the resource demand and the priority of the target task, wherein the resource demand refers to which computing resources (e.g., CPU, memory, etc.) are required to execute the target task and how many computing resources are required, etc. Since, by default, CCE always has a resident container instance in an idle state, the container instance in the idle state can respond to the target task quickly. Therefore, according to the attribute information of the target task, the target task is assigned to the container instance corresponding to the computing cost required to solve the target task. The processing can be: if the resource demand for solving the target task is small, the target task with small resource demand is assigned to CCE, and is processed by the resident container instance in CCE; if the resident container instance in CCE cannot meet the solution of the target task with small resource demand, the target task with small resource demand is assigned to CCI, and is processed by the container instance in CCI; if the resource demand for solving the target task is large, the target task with large resource demand is assigned to CCI, and is processed by the container instance in CCI.

[0036] In an embodiment of the present application, priorities can be set for resident container instances of CCE or container instances in CCI according to different hardware resources, for example, high performance, medium performance, and low performance. In this way, when receiving the target task and its attribute information, target tasks of different priorities can be assigned to container instances of corresponding performance priorities according to the priority of the target task. For example, if the priority of the target task is high, the high-priority target task is assigned to a high-performance container instance in CCE or CCI for processing; if the priority of the target task is low, the low-priority target task is assigned to a low-performance container instance in CCE or CCI for processing, and so on.

[0037] It should be noted that, for the resident container instance of CCE mentioned in the above embodiment, the present application may also perform the following operations of step S1 and step S2 on it:

[0038] Step S1: pre-start a resident container instance in CCE.

[0039] As mentioned above, considering the low resource consumption and short time consumption of target tasks, the resident container instances of CCE are always preferentially assigned to execute. In order to quickly respond to such target tasks, the resident container instances in CCE can be pre-started. There are many ways to implement pre-start. One is to use container orchestration tools, such as Kubemetes or Docker Swarm, to configure the resident container instances in CCE and set these instances to pre-start, ensuring that they are automatically started and in standby state when the cluster starts. Another implementation is to use initialization scripts, that is, by writing initialization scripts, complete the necessary initialization operations when the resident container instances in CCE are started, such as pre-loading data, establishing database connections, etc., to ensure that the resident container instances are in a ready state before actually receiving the target tasks.

[0040] The above two implementation schemes of pre-starting resident container instances rely on some tools and are uncertain to some extent. In order to pre-start the resident container instance in CCE more accurately, the third implementation scheme of pre-starting the resident container instance in CCE provided by this application can be to pre-start the resident container instance in CCE based on historical data and prediction models. In this implementation scheme, historical data refers to the data accumulated by the system in the past operation process, mainly including the frequency of submission of solution tasks, resource requirements of solution tasks and system load, etc., wherein the frequency of submission of solution tasks refers to the frequency of submission of solution tasks in a certain time period in the past (for example, every day, every week, every month) (for example, in certain time periods on weekdays, the density of solution task submission may be higher, and relatively low during non-working hours), and the execution time of the solution task refers to the time required for the solution task to be started and completed, which can help estimate the processing time of future target tasks, so as to better arrange resource allocation, and the system load mainly includes CPU utilization, memory occupancy, network bandwidth usage, etc. These data reflect the load of the system in different time periods, which helps to identify peak and trough periods. By analyzing these historical data, common peak periods and typical resource demands during these periods can be identified, thus providing an important basis for formulating dynamic resource adjustment strategies. As for the prediction model, after cleaning the historical data, a prediction model can be obtained after a series of steps such as feature extraction, model training and evaluation, such as a time series prediction model, a regression model or a machine learning model, etc. After obtaining the prediction model, based on the historical data and the prediction model, the resident container instances in CCE can be pre-started specifically: before the peak period is predicted to arrive, additional resident container instances in CCE can be pre-started to cope with the upcoming large number of solution tasks; during the trough period, the number of resident container instances in CCE can be reduced according to the prediction model to release resources for other solution tasks or save costs; and according to the real-time monitoring data and the output of the prediction model, the number of resident container instances in CCE can be dynamically adjusted during the execution of the solution task to optimize resource utilization, etc.

[0041] Step S2: Preheating the pre-started resident container instance.

[0042] Specifically, preheating the resident container instance after pre-starting can be to execute some simulation tasks after the resident container instance is started. These simulation tasks are usually lightweight computing tasks or system calls, so as to activate the resources in the resident container instance in advance, such as CPU, memory, cache, etc. Preheating the resident container instance after pre-starting can also be to run a benchmark script to evaluate the performance of the resident container instance through some standardized test tasks, and use these data to optimize the configuration of the resident container instance, such as adjusting the allocation of CPU and memory, optimizing network configuration, etc. By preheating the resident container instance after pre-starting, tasks can be processed faster, cold start time can be reduced, and the response speed of the system can be improved. Performance bottlenecks in the resident container instance can also be discovered and eliminated, thereby optimizing overall performance and improving task processing efficiency.

[0043] It should be noted that, on the one hand, during the preheating process, some key data or code paths may be loaded into the cache, but over time, these caches may be overwritten by other tasks, resulting in the need to reload data or code, thereby increasing processing delays; on the other hand, considering that over time, other tasks or containers may be started in the system and occupy more resources (such as CPU, memory, etc.), resulting in a reduction in the resources required for the originally preheated container instance, and the temperature and power consumption status of the hardware (such as CPU, memory, etc.) may change over time. These changes will affect the performance of the hardware, thereby indirectly affecting the operating efficiency of the resident container instance in CCE. Based on the above factors, the performance of the resident container instance in CCE may decline over time. In order to address the problem of performance degradation of resident container instances in CCE, the embodiments of the present application can be implemented through the following methods S'1 to S'4:

[0044] S'1: Real-time monitoring of the performance of resident container instances in CCE.

[0045] These monitored performances can specifically be CPU usage, memory usage, I / O performance, and application layer indicators, etc. Among them, monitoring CPU usage mainly refers to tracking the CPU utilization of resident container instances and identifying potential bottlenecks or overloads. Monitoring memory usage mainly monitors memory consumption and checks whether there are memory leaks or excessive memory usage. Monitoring I / O performance mainly monitors the disk read and write operations and network I / O of resident container instances to evaluate their response speed and data transmission efficiency. Monitoring application layer indicators refers to monitoring application response time, throughput, error rate and other indicators based on specific applications.

[0046] S'2: Regularly perform performance benchmark tests on resident container instances in CCE.

[0047] In order to understand the changing trend of container performance, you can perform performance benchmarking regularly. Performance benchmarking is a standardized testing process used to evaluate the performance of containers under different loads. Steps include A to C:

[0048] A: Create standardized test scenarios, that is, by simulating actual workloads, exert a certain amount of pressure on resident container instances to test their response speed, resource consumption, and processing power.

[0049] B: Record benchmark test results, that is, compare the test results with previous test data to identify performance degradation trends of resident container instances.

[0050] C: Analyze performance bottlenecks. That is, identify the specific reasons for the performance degradation of the resident container instance through test results, such as CPU overload, insufficient memory, or I / O bottleneck, etc.

[0051] S'3: Regularly adjust the resources occupied by resident container instances in CCE.

[0052] Based on monitoring data and benchmark results, the resources of resident container instances in CCE are regularly adjusted to optimize performance. Adjustment measures include CPU and memory quota adjustment, reconfiguration of container parameters, and horizontal expansion or contraction, etc. Among them, CPU and memory quota adjustment means that when it is found that the CPU or memory resources of a resident container instance are insufficient, its performance is improved by increasing the quota. On the contrary, if a resident container instance has excess resources, the quota can be appropriately reduced to release resources for other resident container instances. Reconfiguring container parameters means regularly evaluating and adjusting the parameters of resident container instances at runtime to ensure that they are suitable for the current workload. Horizontal expansion or contraction means dynamically adjusting the number of replicas of resident container instances according to load changes to cope with load peaks or troughs.

[0053] S'4: Periodically restart the resident container instances in CCE.

[0054] In some cases, the performance of CCE resident container instances may degrade due to long-term operation, such as memory leaks or resource fragmentation. Restarting CCE resident container instances regularly can release occupied resources and clear status.

[0055] In principle, in the embodiments of the present application, necessary resources can be reserved for resident container instances in CCE, while for CCI, resource allocation is dynamically adjusted based on usage.

[0056] Step S104: monitor the running status of nodes and container instances in real time.

[0057] In the embodiment of the present application, real-time monitoring of the running status of nodes and container instances mainly involves real-time monitoring of the load, health, etc. of the nodes and the container instances they run. For example, through real-time monitoring, it is possible to know how many container instances are currently running on a certain node, the solving tasks being executed, whether they are healthy, etc. By real-time monitoring of the running status of nodes and container instances, it is possible to promptly discover the failures of nodes and their container instances, dynamically adjust the allocation of solving tasks, and reasonably adjust the supply of resources, etc.

[0058] By monitoring the running status of nodes and container instances in real time, you can perform one or any combination of the following operations 1) to 3):

[0059] 1) Operation 1: If a node and / or container instance fails, the solution task executed on the failed node and / or container instance will be transferred to a node and / or container instance that is running normally.

[0060] Obviously, if a node and / or container instance fails, the solution task executed on the failed node and / or container instance will be transferred to a node and / or container instance in normal operation, so as not to delay the execution of the solution task.

[0061] 2) Operation 2: If the task to be solved is a paused task, when resuming the execution of the paused task, the data retained on the node and / or container instance that executed the paused task before the pause is used to continue the execution.

[0062] In the above embodiment, the reason why the node and / or container of the suspended solution task before the suspension is used when resuming the execution of the suspended solution task is that when a solution task is suspended, the system usually saves the running status and intermediate results related to the solution task, that is, the retained data, including the task status (that is, the current execution progress of the solution task, such as how much data has been processed, which steps have been executed, etc.), cache data (that is, the intermediate results or temporary data generated by the solution task during the execution process, so that the data may continue to be used after the task is resumed), system context (that is, the environment variables and configuration parameters that the solution task depends on when executing, which information can help the task continue to run in the same environment after resumption) and memory status (including stack information, variable values, unfinished I / O operations, etc., all of which can help the solution task maintain continuity after resumption), etc., and by using these retained data, the suspended solution task does not have to start from the beginning when it is resumed, but can be directly continued from the state when it was suspended. In this way, this not only saves the time of recalculation, but also avoids repeated I / O operations, thereby improving the overall efficiency of the system.

[0063] 3) Operation three: If the task to be solved is a rescheduled solution task, the rescheduled solution task is assigned to the node and / or container instance that has executed the rescheduled solution task for execution.

[0064] Although the reason for assigning the rescheduled solution task to the node and / or container instance that has executed the same task is similar to the reason for using the node and / or container that executed the paused solution task before resuming the execution of the paused solution task, it is more based on considerations such as cache and state utilization, avoiding cold starts, data locality, and consistency of the execution environment. Among them, cache and state utilization means that when a solution task is rescheduled, if it can be assigned to a node or container instance that has previously executed the same solution task, the system can use the previous cache, state information, and already loaded dependent resources. In this way, the reinitialization time can be reduced and the execution efficiency of the solution task can be improved. Obviously, assigning the rescheduled solution task to the node or container instance that has executed the same task can effectively avoid the overhead of cold starts. As for data locality, it means that if the solution task needs to process a large amount of data, and this data has been downloaded or stored in local storage (such as the disk on the node or the local file system of the container) by the previous solution task, then rescheduling to the same node can avoid the overhead of data transmission, and directly executing the solution task using local data can also significantly improve the execution speed of the solution task. In practical applications, some solution tasks have strict requirements on the execution environment (such as specific dependency library versions, specific operating system configurations, etc.). If they are rescheduled to the same node or container instance as before, the consistency of the execution environment can be guaranteed, avoiding errors or inconsistencies caused by environmental differences. This is based on the consideration of the consistency of the execution environment.

[0065] It should be noted that although the above embodiments use qualitative descriptions such as "more", "less", "long" or "short" when referring to the resources and / or time required for solving the task, for example, "evaluating the rigid body solving task requires less resource consumption and shorter time", "evaluating the flexible body solving task requires more resource consumption and longer time", "if the resource requirements for solving the target task are less" and "if the resource requirements for solving the target task are more", etc., those skilled in the art can understand that these "more", "less", "long" or "short" are all relative. In actual application scenarios or implementation processes, some thresholds can be set to define the resource consumption or time consumption below this threshold as "less" or "short", and conversely, the resource consumption or time consumption above this threshold is defined as "more" or "long", etc.

[0066] Step S105: dynamically adjusting the predetermined allocation of the tasks to be solved in the container instance according to the attribute information of the tasks to be solved and the operating conditions of the nodes and the container instance, wherein the tasks to be solved include the newly received tasks and the target tasks.

[0067] As an embodiment of the present application, according to the attribute information of the task to be solved and the running status of the node and the container instance, dynamically adjusting the predetermined allocation of the task to be solved in the container instance can be achieved through steps S1051 to S1053, which are described in detail as follows:

[0068] Step S1051: Collect resource consumption status and load of nodes and container instances.

[0069] As mentioned above, through real-time monitoring, it is possible to know how many container instances are currently running on a certain node, the solution tasks being executed, whether they are healthy, etc. Therefore, information such as the resource consumption status and load of the nodes and container instances can be obtained by real-time monitoring of the running status of the nodes and container instances in step S104.

[0070] Step S1052: Based on the resource consumption status and load of the nodes and container instances, the nodes and container instances with the smallest resource consumption and / or the smallest number of tasks to be solved are preferentially selected as the current nodes and container instances for executing the tasks to be solved.

[0071] If a node and its container instance currently consume the least resources and / or execute the least number of solving tasks, given the initial resources, it means that the node can allocate more resources to execute solving tasks. Therefore, the node and container instance with the least resource consumption and / or the least number of solving tasks are preferentially selected as the current node and container instance for executing the task to be solved.

[0072] Step S1053: If the task to be solved is a flexible body solving task, after the flexible body solving task is completed, the container instance executing the flexible body solving task is destroyed.

[0073] In an embodiment of the present application, when a solution task is submitted, the system will start the corresponding container instance to provide the required computing power for the solution task according to the resource requirements of the solution task. As mentioned above, compared with the rigid body solution task, the flexible body solution task is much more complicated in terms of computational complexity, degree of freedom and mesh refinement, time step and stability, and solution algorithm. Therefore, the flexible body solution task has many characteristics such as large resource consumption or large fluctuations in resource demand, long time consumption, or unpredictable execution time. When the flexible body solution task is submitted to the task manager, the system will provide it with corresponding container instances, computing resources, etc. according to the above characteristics of the flexible body solution task. However, from the perspective of resource utilization, cost reduction and simplified management, when the flexible body solution task is completed, retaining the container instance will increase the user's additional resource usage cost and also lead to resource waste. Therefore, if the task to be solved is a flexible body solving task, the container instance executing the flexible body solving task will be destroyed after the flexible body solving task is completed. The system can immediately reallocate these resources to other solving tasks to ensure maximum resource utilization. This not only avoids unnecessary user overhead, but also saves manual operations by operation and maintenance personnel, thereby reducing the complexity of operation and maintenance.

[0074] If the task resource scheduling method based on the containerized environment in the above embodiment has not achieved the expected effect, a global scheduler can be introduced to optimize the overall resources and coordinate the task scheduling strategy. In other words, by introducing a global scheduler, the task resource scheduling method based on the containerized environment in the above example can also include the following steps Sa11 to Sa15, which are described in detail as follows:

[0075] Step Sa11: Collect status information.

[0076] In an embodiment of the present application, the status information refers to target task data and resource data, wherein the target task data includes the status of the task queue to be solved, the priority of the task to be solved, etc., and the resource data includes the system resource utilization rate, the resource requirements of the task to be solved, and the load information of the node or container instance, etc.

[0077] Step Sa12: Based on the state information, define the state space and action space of the decision model.

[0078] In the embodiment of the present application, each state of the state space strictly depends on the aforementioned collected state information, and determines the environment on which the learning and decision-making of the subsequent decision model are based, and the action space is the scheduling operation that may be performed under each state of the state space, for example, assigning the target task, i.e., the task to be solved, to a specific node or container instance, pausing, canceling the target task, or dynamically adjusting the priority of the target task, etc. Each state of the state space can be a system resource state, a target task queue state, and / or an execution environment state, wherein the system resource state includes the current CPU, memory, disk, network bandwidth and other resource usage, the task queue state includes the properties of the target task, such as the priority of the target task, the estimated execution time, i.e., the time consumption, resource requirements, etc., and the execution environment state is the load of the current node or container instance, the number of assigned target tasks, the target task execution history and other data.

[0079] Step Sa13: Create a training environment for the model based on the state space and action space of the decision model, and design the activation function of the decision model.

[0080] The scheduling problem is represented by creating a training environment for the model, which should include elements such as target task queues, resource pools (such as CPU, memory, bandwidth, etc.), and scheduling strategies. The training environment needs to be able to change dynamically to simulate task arrival and resource usage in the real world. In an embodiment of the present application, a training environment for the model can be created and an incentive function for the decision model can be designed by using tools such as OpenAI Gym and based on the state space and action space of the decision model. The incentive function reflects the performance of the scheduling strategy, such as the reduction of target task execution delay and the maximization of resource utilization. The incentive function can be designed based on the task delay and resource utilization after the execution of the scheduling strategy. For example, reducing the target task execution delay will obtain positive incentives, and increasing resource utilization or balancing resource usage will obtain higher incentives.

[0081] Step Sa14: Train the decision model to obtain a trained decision model.

[0082] The training process of the decision model can be: randomly selecting scheduling actions, recording the completion status of the target task, resource usage, etc.; after each round of scheduling, the algorithm updates the strategy, adjusts the scheduling strategy according to the incentive situation of the target task scheduling, and gradually optimizes the performance of the decision model; using experience replay technology (such as DQN) to utilize previous experience data during training to enhance the learning effect; after multiple training iterations, the decision model will continuously improve its strategy and eventually learn to take the optimal scheduling action under different conditions.

[0083] Step Sa15: Input the global target task and resource data into the trained decision model, and the trained decision model will allocate the target task.

[0084] If the task resource scheduling method based on the containerized environment in the above embodiment has not achieved the expected effect, a global scheduler can also be introduced to optimize the overall resources and coordinate the task scheduling strategy. In other words, as another embodiment of the present application, by introducing a global scheduler, the task resource scheduling method based on the containerized environment in the above example can also include the following steps Sb11 to Sb17, which are described in detail as follows:

[0085] Step Sb11: Decompose the global target task into subtasks of multiple scales.

[0086] The global target task can be decomposed according to different scales. For example, the global target task can be divided into short-term, medium-term, long-term and other subtasks according to the complexity of the target task, the computational cost or the time constraint. Each subtask after decomposition corresponds to a specific scale, such as completing part of the target task in the short term or optimizing the overall resource utilization in the long term, etc.

[0087] Step Sb12: Set optimization goals for subtasks of different scales.

[0088] Define specific optimization goals for each subtask to ensure that subtasks at different scales have feasible optimization directions. This can be achieved by designing an objective function, that is, building a corresponding optimization objective function for each subtask. For example, the goal of a short-term task may be to minimize the solution time, a mid-term task may require maximizing resource utilization, and a long-term task may focus on improving the overall efficiency of the system, and so on.

[0089] Step Sb13: According to the optimization goal of each subtask, select a suitable optimization algorithm and perform targeted configuration.

[0090] According to the characteristics of each subtask, select the corresponding optimization algorithm. For example, for the rapid solution requirements of short-term tasks, heuristic algorithms can be used; medium-term tasks may use precise linear programming or mixed integer programming; and long-term tasks can use more complex meta-heuristic algorithms (for example, genetic algorithms or simulated annealing algorithms). As for the targeted configuration of the optimization algorithm, it includes adjusting specific configuration items in the selected optimization algorithm. These configuration items include algorithm parameters, stopping criteria, and initial conditions, etc. Among them, algorithm parameters include the step size in the heuristic algorithm, the crossover rate and mutation rate in the genetic algorithm, and the stopping criteria include the number of iterations, the tolerance error of the objective function, etc., and the initial conditions can be the generation method of the initial solution, the population size, etc.

[0091] Step Sb14: Optimize and solve each target task at different scales to obtain a preliminary scheduling solution.

[0092] Apply the optimization algorithm selected in step Sb13 at each scale to solve the subtasks and obtain the corresponding scheduling results. Short-term tasks can be solved quickly, medium-term tasks focus more on resource utilization, and long-term tasks focus on the overall performance of the system.

[0093] Step Sb15: Integrate and coordinate the solution results of multi-scale target tasks.

[0094] The purpose of integrating and coordinating the solution results of multi-scale target tasks is to integrate the solution results of different scales, handle the conflicts between subtasks, and form a unified global scheduling solution. Specifically, the solution results of different scales obtained in step Sb14 are integrated to handle conflicts and inconsistencies. The results of each subtask can be coordinated by setting priorities or introducing a weight mechanism to ensure that the final scheduling strategy has consistency and global optimization effect.

[0095] Step Sb16: Verify the integrated scheduling strategy in the actual environment and adjust it according to the actual performance.

[0096] Specifically, the integrated scheduling solution can be run in a simulated or actual environment to evaluate its performance in key indicators such as task completion time and resource utilization efficiency. Based on the results of actual verification, the scheduling strategy can be adjusted and optimized to ensure its adaptability and stability in different scenarios.

[0097] Step Sb17: Dynamically adjust the scheduling strategy of the solution task through online optimization technology to adapt to the real-time changing solution environment.

[0098] The scheduling strategy of the solution task can be dynamically adjusted according to the real-time feedback data to optimize the allocation of tasks and the use of resources, ensuring that the scheduling system can flexibly respond to environmental changes.

[0099] Further, in an embodiment of the present application, the client submitting the solution task can also collect the user's preference information on the type, priority and resource requirements of the solution task, and feed this information back to the server. The server feeds back the progress, status and results of the solution task to the client in real time through an API or interface. Once the solution task is abnormal or fails, the system will promptly notify the client. In addition, the system provides comprehensive monitoring and log management functions (monitoring data includes resource usage of container instances, execution time of tasks, and error logs, etc.), so that administrators and users can keep abreast of the system's operating status and the execution of solution tasks.

[0100] From the above attached Figure 1It can be seen from the example of the task resource scheduling method based on the containerized environment that, on the one hand, after evaluating the computational cost required to solve the target task, the target task is assigned to the container instance corresponding to the computational cost required to solve the target task, which not only ensures the system's rapid response and efficient processing of the task to be solved, but also improves the utilization rate of resources; on the other hand, by real-time monitoring of the operating status of the container instance, according to the attribute information of the task to be solved and the operating status of the container instance, the established allocation of the task to be solved in the container instance is dynamically adjusted, which means that when the operating status of the container instance is not good (for example, a node failure occurs, the load is too heavy, etc.), the task to be solved can be quickly transferred, thereby ensuring the load balancing and stable operation of the system. In summary, compared with the prior art, the technical solution of the present application can ensure the stable operation of the system, the rapid response to the task to be solved, and the reasonable and efficient use of resources.

[0101] Please refer to the attached Figure 2 , is a task resource scheduling device based on a containerized environment provided by an embodiment of the present application, the device may include a receiving module 201, an evaluation module 202, a first scheduling module 203, a monitoring module 204 and a second scheduling module 205, which are described in detail as follows:

[0102] The receiving module 201 is used to receive the target task and its attribute information, wherein the attribute information of the target task includes the type of the target task, resource requirements and priority;

[0103] An evaluation module 202, used to evaluate the computational cost required to solve the target task based on the attribute information of the target task;

[0104] A first scheduling module 203 is used to allocate the target task to a container instance corresponding to the computing cost required to solve the target task for processing according to the attribute information of the target task and / or the computing cost required to solve the target task;

[0105] Monitoring module 204, used to monitor the running status of nodes and container instances in real time;

[0106] The second scheduling module 205 is used to dynamically adjust the established allocation of the tasks to be solved in the container instance according to the attribute information of the tasks to be solved and the operating conditions of the nodes and the container instance, wherein the tasks to be solved include newly received tasks and target tasks.

[0107] From the above attached Figure 2It can be seen from the example of a task resource scheduling device based on a containerized environment that, on the one hand, after evaluating the computational cost required to solve the target task, the target task is assigned to the container instance corresponding to the computational cost required to solve the target task, which not only ensures the system's rapid response and efficient processing of the task to be solved, but also improves the utilization rate of resources; on the other hand, by real-time monitoring of the operating status of the container instance, the established allocation of the task to be solved in the container instance is dynamically adjusted according to the attribute information of the task to be solved and the operating status of the container instance, which means that when the operating status of the container instance is not good (for example, a node failure occurs, the load is too heavy, etc.), the task to be solved can be quickly transferred, thereby ensuring the load balancing and stable operation of the system. In summary, compared with the prior art, the technical solution of the present application can ensure the stable operation of the system, rapid response to the task to be solved, and reasonable and efficient use of resources.

[0108] Figure 3 Schematic diagram of the structure of an electronic device provided by an embodiment of the present application. Figure 3 As shown, the electronic device 3 of this embodiment mainly includes: a processor 30, a memory 31, and a computer program 32 stored in the memory 31 and executable on the processor 30, such as a program of a task resource scheduling method based on a containerized environment. When the processor 30 executes the computer program 32, the steps in the above-mentioned task resource scheduling method based on a containerized environment are implemented, such as Figure 1 Alternatively, when the processor 30 executes the computer program 32, the functions of each module / unit in the above-mentioned device embodiments are implemented, for example Figure 2 The functions of the receiving module 201 , the evaluating module 202 , the first scheduling module 203 , the monitoring module 204 and the second scheduling module 205 are shown.

[0109] Exemplarily, the computer program 32 of the task resource scheduling method based on the containerized environment mainly includes: receiving the target task and its attribute information, wherein the attribute information of the target task includes the type of the target task, resource demand and priority; evaluating the computing cost required to solve the target task according to the attribute information of the target task; assigning the target task to the container instance corresponding to the computing cost required to solve the target task according to the attribute information of the target task and / or the computing cost required to solve the target task; monitoring the running status of the node and the container instance in real time; dynamically adjusting the established allocation of the task to be solved in the container instance according to the attribute information of the task to be solved and the running status of the node and the container instance, wherein the task to be solved includes the newly received task and the target task. The computer program 32 can be divided into one or more modules / units, one or more modules / units are stored in the memory 31, and are executed by the processor 30 to complete the present application. One or more modules / units can be a series of computer program instruction segments that can complete specific functions, and the instruction segments are used to describe the execution process of the computer program 32 in the electronic device 3. For example, the computer program 32 can be divided into the functions of a receiving module 201, an evaluation module 202, a first scheduling module 203, a monitoring module 204 and a second scheduling module 205 (modules in the virtual device), and the specific functions of each module are as follows: a receiving module 201 is used to receive a target task and its attribute information, wherein the attribute information of the target task includes the type, resource demand and priority of the target task; an evaluation module 202 is used to evaluate the computing cost required to solve the target task based on the attribute information of the target task; a first scheduling module 203 is used to allocate the target task to a container instance corresponding to the computing cost required to solve the target task based on the attribute information of the target task and / or the computing cost required to solve the target task; a monitoring module 204 is used to monitor the operating status of nodes and container instances in real time; a second scheduling module 205 is used to dynamically adjust the established allocation of tasks to be solved in the container instance based on the attribute information of the tasks to be solved and the operating status of nodes and container instances, wherein the tasks to be solved include newly received tasks and target tasks.

[0110] The electronic device 3 may include but is not limited to a processor 30 and a memory 31. Those skilled in the art will appreciate that Figure 3 It is only an example of the electronic device 3 and does not constitute a limitation of the electronic device 3. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the electronic device may also include input and output devices, network access devices, buses, etc.

[0111] The processor 30 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0112] The memory 31 may be an internal storage unit of the electronic device 3, such as a hard disk or memory of the electronic device 3. The memory 31 may also be an external storage device of the electronic device 3, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the electronic device 3. Further, the memory 31 may also include both an internal storage unit of the electronic device 3 and an external storage device. The memory 31 is used to store computer programs and other programs and data required by the electronic device. The memory 31 may also be used to temporarily store data that has been output or is to be output.

[0113] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into a processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned device can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0114] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0115] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0116] In the embodiments provided in the present application, it should be understood that the disclosed devices / equipment and methods can be implemented in other ways. For example, the device / equipment embodiments described above are only schematic, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0117] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0118] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0119] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program of the task resource scheduling method based on the containerized environment can be stored in a storage medium. When the computer program is executed by the processor, it can implement the steps of the above-mentioned various method embodiments, that is, receiving the target task and its attribute information, wherein the attribute information of the target task includes the type, resource demand and priority of the target task; according to the attribute information of the target task, the computational cost required to solve the target task is evaluated; according to the attribute information of the target task and / or the computational cost required to solve the target task, the target task is allocated to the container instance corresponding to the computational cost required to solve the target task for processing; real-time monitoring of the operating status of the node and the container instance; according to the attribute information of the task to be solved and the operating status of the node and the container instance, the established allocation of the task to be solved in the container instance is dynamically adjusted, wherein the task to be solved includes the newly received task and the target task. Among them, the computer program includes computer program code, which can be in source code form, object code form, executable file or some intermediate form, etc. Storage media may include: any entity or device capable of carrying computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content contained in the storage medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the storage medium does not include electric carrier signal and telecommunication signal.

[0120] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them; although the present application is described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some of the technical features therein by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application. The specific implementation methods described above further describe the purpose, technical solutions and beneficial effects of the present application in detail. It should be understood that the above description is only the specific implementation method of the present application, and is not used to limit the protection scope of the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should be included in the protection scope of the present invention.

Claims

1. A task resource scheduling method based on a containerized environment, characterized in that: The method comprises: Receiving a target task and its attribute information, wherein the attribute information of the target task includes the type, resource requirement and priority of the target task; According to the attribute information of the target task, evaluating the computational cost required to solve the target task; According to the attribute information of the target task and / or the computational cost required to solve the target task, the target task is assigned to a container instance corresponding to the computational cost required to solve the target task for processing; Monitor the operating status of nodes and container instances in real time; According to the attribute information of the task to be solved and the running status of the node and the container instance, the established allocation of the task to be solved in the container instance is dynamically adjusted, and the task to be solved includes the newly received task and the target task.

2. The method for scheduling task resources based on a containerized environment as claimed in claim 1, characterized in that: The step of evaluating the computational cost required to solve the target task according to the attribute information of the target task includes: If the type of the target task is a rigid body solving task, evaluating the rigid body solving task requires less resource consumption and shorter time; If the target task is a flexible body solving task, it is evaluated that the flexible body solving task requires a lot of resources and takes a long time.

3. The task resource scheduling method based on the containerized environment as claimed in claim 2, characterized in that: The step of allocating the target task to a container instance corresponding to the computing cost required for solving the target task according to the computing cost required for solving the target task includes: If it is evaluated that the rigid body solving task requires less resource consumption and takes less time, the rigid body solving task is assigned to the container cluster environment CCE and processed by the resident container instance in the CCE; If it is assessed that the flexible body solving task requires a lot of resources and takes a long time, the flexible body solving task is allocated to the container cloud instance CCI and processed by the container instance in the CCI.

4. The task resource scheduling method based on the containerized environment as claimed in claim 1, characterized in that: The step of allocating the target task to a container instance corresponding to a computational cost required to solve the target task according to the attribute information of the target task includes: If the resource requirement for solving the target task is small, the target task with small resource requirement is allocated to the container cluster environment CCE and processed by the resident container instance in the CCE; If the resident container instance in the CCE cannot satisfy the solution of the target task with less resource requirements, the target task with less resource requirements is allocated to the container cloud instance CCI and processed by the container instance in the CCI; If solving the target task requires a lot of resources, the target task with the high resource requirement is allocated to the container cloud instance CCI and processed by the container instance in the CCI.

5. The task resource scheduling method based on the containerized environment as claimed in claim 1, characterized in that: The dynamically adjusting the predetermined allocation of the task to be solved in the container instance according to the attribute information of the task to be solved and the running status of the node and the container instance includes: Collect resource consumption status and load of the nodes and container instances; According to the resource consumption status and load of the nodes and container instances, the nodes and container instances with the smallest resource consumption and / or the smallest number of tasks to be solved are preferentially selected as the current nodes and container instances for executing the tasks to be solved; If the task to be solved is a flexible body solving task, after the flexible body solving task is completed, the container instance executing the flexible body solving task is destroyed.

6. The task resource scheduling method based on the containerized environment as claimed in claim 1, characterized in that: The method further comprises: If a failure occurs in the operation of the node and / or container instance, the solution task executed on the failed node and / or container instance is transferred to a node and / or container instance in normal operation; If the task to be solved is a suspended task, when resuming the execution of the suspended task, the data retained on the node and / or container instance that executed the suspended task before the suspension is used to continue the execution; and If the task to be solved is a rescheduled solution task, the rescheduled solution task is assigned to be executed on the node and / or container instance that has executed the rescheduled solution task.

7. The task resource scheduling method based on the containerized environment as claimed in claim 1, characterized in that: The container instance includes a resident container instance in a container cluster environment CCE, and the method further includes: Pre-starting a resident container instance in the container cluster environment CCE; Preheating the pre-started resident container instance.

8. A task resource scheduling device based on a containerized environment, characterized in that: The device comprises: A receiving module, used for receiving a target task and its attribute information, wherein the attribute information of the target task includes the type, resource requirement and priority of the target task; An evaluation module, used to evaluate the computational cost required to solve the target task according to the attribute information of the target task; A first scheduling module, configured to allocate the target task to a container instance corresponding to the computing cost required to solve the target task for processing according to the attribute information of the target task and / or the computing cost required to solve the target task; Monitoring module, used to monitor the operating status of nodes and container instances in real time; The second scheduling module is used to dynamically adjust the established allocation of the tasks to be solved in the container instance according to the attribute information of the tasks to be solved and the operating conditions of the nodes and container instances, wherein the tasks to be solved include the newly received tasks and the target tasks.

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

10. A storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images