Consumer container restarting method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of computers, in particular to a consumer container restarting method and device, electronic equipment and a storage medium. According to the method, firstly, the operation information of the consumer container deployed at multiple nodes is acquired in real time, the ongoing asynchronous task information and the process identification information are accurately captured, container resource occupation, task progress, process details and the like are mastered, the task volume and the complexity can be clarified in advance, and the task processing efficiency is improved. And the problems of poor asynchronous task recovery effect and low efficiency are effectively solved. And when a restart instruction is responded, restart performance evaluation is performed by utilizing collected multi-dimensional information, so that the restart opportunity is determined on the basis, the dilemma of restart when the data flow is large in the past is overcome, and the task consumption efficiency is ensured not to be damaged. And finally, based on the specific type of the restart instruction and the evaluation result, customizing a target restart strategy to ensure orderly, efficient and safe restart of the multi-node asynchronous task consumer container and maintain stable operation of the system.

Description

Technical Field

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

[0002] In today's software development and system architecture, the asynchronous model has been widely used due to its feature of allowing multiple events to be processed at the same time. When a program calls a time-consuming function method, it will not block the execution process and can continue to run downward, greatly improving the overall efficiency. Docker container technology also shows many advantages in deploying asynchronous task processors. It can ensure that each service is independent of each other and avoid waste of resources. Deploying asynchronous task processors through Docker to monitor and process asynchronous tasks in real time can not only reduce resource usage, but also create a highly available environment. In addition, deploying multiple consumer containers on multiple nodes can effectively reduce the memory pressure of consumers when processing asynchronous tasks, further speeding up consumption. However, in the key link of restarting multi-node asynchronous task consumer containers, there are many challenges. On the one hand, asynchronous tasks themselves often have high idempotency requirements. Especially when the task information body contains a large amount of data, if a recovery operation is performed, the effect is not satisfactory and the efficiency is relatively low. In addition, when the asynchronous task processing logic is simple, the transformation workload is large, which leads to reduced consumption efficiency. On the other hand, it is extremely difficult to control the timing of restart. When restarting in a scenario with a large data flow, it is difficult for existing technologies to ensure that asynchronous tasks are consumed smoothly without affecting the efficiency of task consumption. At the same time, from a security perspective, existing technologies are relatively weak. External errors or malicious restart instructions can easily cause containers to restart at inappropriate times, ultimately resulting in the loss of asynchronous tasks. In addition, the current restart intention is not clear enough, and the effects of restart methods in different scenarios are significantly different, but there is a lack of targeted methods designed for each restart scenario.

[0003] However, in terms of restarting multi-node asynchronous task consumer containers, there are problems such as poor asynchronous task recovery effect, low efficiency, difficulty in grasping the restart timing, weak security, and lack of targeted restart methods, which affect the normal processing of asynchronous tasks and the stable operation of the system. Summary of the invention

[0004] In view of this, the embodiments of the present invention provide a method, device, electronic device and storage medium for restarting a consumer container to solve the problems of poor asynchronous task recovery effect, low efficiency, difficulty in grasping the restart timing, weak security and lack of targeted restart methods in restarting multi-node asynchronous task consumer containers.

[0005] In a first aspect, an embodiment of the present invention provides a method for restarting a consumer container, the method comprising:

[0006] Acquire the running information of the consumer container deployed on multiple nodes in real time, and acquire the asynchronous task information and process identification information being performed by the consumer container;

[0007] Listening for container restart instructions triggered externally by the operating environment where the consumer container is located;

[0008] In response to the container restart instruction, a restart performance evaluation is performed using the running information, the asynchronous task information, and the process identification information to obtain an evaluation result;

[0009] A target restart strategy is acquired based on the restart instruction and the evaluation result, and the consumer container is controlled to perform a restart operation according to the target restart strategy.

[0010] Furthermore, the real-time acquisition of the operation information of the consumer containers deployed on multiple nodes includes:

[0011] Obtaining a consumer container in a monitoring framework, wherein the monitoring framework is constructed using a consumption task queue associated with the consumer container and a specific number of the consumer containers deployed on each node;

[0012] Acquire multiple key information reported by the consumer container in the monitoring framework according to the container activity determination method;

[0013] The operation information of the consumer container is constructed based on the key information.

[0014] Furthermore, the obtaining of the asynchronous task information and process identification information being performed by the consumer container includes:

[0015] Analyze whether each ongoing asynchronous task is a distributed asynchronous task.

[0016] If it is a distributed asynchronous task, read the corresponding asynchronous task information according to the preset information category list;

[0017] A consumer process corresponding to the consumer container is determined, and process identification information related to the distributed asynchronous task management in the consumer process is obtained.

[0018] Further, the restart performance evaluation is performed using the operation information, the asynchronous task information, and the process identification information to obtain an evaluation result, including:

[0019] evaluating a restart status of the consumer container using the operation information;

[0020] Assessing the restart risk of the consumer container by using the asynchronous task information and the process identification information;

[0021] The assessment result is generated based on the restart status and the restart risk.

[0022] Further, the evaluating the restart status of the consumer container by using the operation information includes:

[0023] Extracting activity determination information and multiple indicator data corresponding to the consumer container from the operation information;

[0024] Analyzing the activation information to obtain the container status of the consumer container;

[0025] Comparing each indicator data with a preset threshold value of the response to obtain the container pressure of the consumer container;

[0026] The container state and the container pressure are matched with the restart conditions corresponding to each preset restart state to obtain a restart state matched by the container state and the container pressure.

[0027] Further, the using the asynchronous task information and the process identification information to evaluate the restart risk of the consumer container includes:

[0028] Using the asynchronous task type, classify the asynchronous tasks currently being performed by the consumer container to obtain different types of asynchronous tasks;

[0029] Determine the task score corresponding to the current asynchronous task of the same type according to the task indicator data of the historical asynchronous tasks of the same type;

[0030] Determining the process number of the consumer process and the amount of monitored data packets from the process identification information;

[0031] The interactive influence among the process quantity of the consumer process, the data packet volume and the task score of the asynchronous task is analyzed, and the restart risk of the consumer container is obtained based on the interactive influence.

[0032] Further, controlling the consumer container to perform a restart operation according to the target restart strategy includes:

[0033] Obtain a key pair associated with the consumer container to be restarted, and send the public key information in the key pair and the stop instruction corresponding to the target restart strategy to the cache, wherein the consumer process detects whether the cache contains a restart instruction based on a set rule, and when a stop instruction is detected, enters a dormant state and suspends reading and consuming subsequent asynchronous tasks;

[0034] The cache is continuously monitored, and when it is detected that there is no real-time data packet of the consumer container to be restarted in the cache, a restart operation is performed according to the target restart strategy, and after the consumer container is restarted, the original consumer process is terminated, and the stop instruction in the cache is cleared.

[0035] In a second aspect, an embodiment of the present invention provides a restart device for a consumer container, the device comprising:

[0036] An acquisition module, used to acquire in real time the operation information of the consumer container deployed on multiple nodes, and to acquire the asynchronous task information and process identification information being performed by the consumer container;

[0037] A monitoring module, used to monitor the container restart instruction triggered externally by the operating environment where the consumer container is located;

[0038] An evaluation module, configured to perform restart performance evaluation based on the container restart instruction by using the operation information, the asynchronous task information, and the process identification information to obtain an evaluation result;

[0039] An execution module is used to obtain a target restart strategy based on the restart instruction and the evaluation result, and control the consumer container to perform a restart operation according to the target restart strategy.

[0040] In a third aspect, an embodiment of the present invention provides an electronic device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, computer instructions being stored in the memory, and the processor executing the method of the first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0041] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the method of the first aspect or any corresponding embodiment thereof.

[0042] This application first obtains the operating information of consumer containers deployed on multiple nodes in real time, and accurately captures the ongoing asynchronous task information and process identification information, so as to grasp the container resource occupancy, task progress, process details, etc., and can clarify the task volume and complexity in advance, and effectively deal with the problems of poor recovery effect and low efficiency of asynchronous tasks. When responding to the restart instruction, the collected multi-dimensional information is used to carry out the restart performance evaluation, and the restart timing is clarified based on this, so as to overcome the dilemma of restarting when the data flow is large in the past, and ensure that the task consumption efficiency is not affected. Finally, based on the specific type of restart instruction and the evaluation results, the target restart strategy is customized to ensure that the restart of multi-node asynchronous task consumer containers is orderly, efficient, and safe, and to maintain the stable operation of the system. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0044] Figure 1 is a flowchart of a method for restarting a consumer container according to some embodiments of the present invention;

[0045] Figure 2 is a schematic diagram of restarting a container according to some embodiments of the present invention;

[0046] Figure 3 is a schematic diagram of the operation of a consumer process in a container according to some embodiments of the present invention;

[0047] Figure 4 is a schematic diagram of a process for determining container restart risk by a monitoring system according to some embodiments of the present invention;

[0048] Figure 5 is a structural block diagram of a restart device for a consumer container according to an embodiment of the present invention;

[0049] Figure 6 It is a schematic diagram of the hardware structure of the electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0050] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0051] According to an embodiment of the present invention, a method, apparatus, electronic device, and storage medium for restarting a consumer container are provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0052] In this embodiment, a method for restarting a consumer container is provided. Figure 1 is a flowchart of a method for restarting a consumer container according to an embodiment of the present invention. Figure 1 As shown, the process includes the following steps:

[0053] Step S101, obtaining in real time the operation information of the consumer container deployed on multiple nodes, and obtaining the asynchronous task information and process identification information being performed by the consumer container.

[0054] In an embodiment of the present application, real-time acquisition of operation information of consumer containers deployed on multiple nodes includes: acquiring consumer containers in a monitoring framework, wherein the monitoring framework is constructed using the consumer task queue associated with the consumer container and the specific number of consumer containers deployed on each node. Acquiring multiple key information reported by the consumer container in the monitoring framework according to the container live judgment method. Constructing the operation information of the consumer container based on the key information.

[0055] First, sort out the consumption task queues associated with the consumer container, that is, figure out which task queue or queues each consumer container is responsible for consuming, which is equivalent to clarifying the "work task scope" of each container. At the same time, count the specific number of consumer containers deployed on each node, and know how many containers are deployed on different nodes, so as to grasp the distribution of containers. These two elements together constitute the basis for building a monitoring framework. For example, suppose there are three nodes, marked as node A, node B, and node C, and 5 consumer containers are deployed on node A, which are responsible for consuming task queues Q1 and Q2; node B deploys 3 consumer containers, which are responsible for consuming task queues Q2 and Q3; node C deploys 4 consumer containers, which are responsible for consuming task queues Q1 and Q3. Through such detailed sorting, the collection of basic information of the overall monitoring framework is completed.

[0056] Based on the above-collected information about the distribution of the number of consumer task queues and containers on each node, determine which consumer containers belong to the current monitoring category. As long as they are on the set nodes and are associated with the corresponding task queues, they are included in this monitoring framework. For example, according to the example given above, all consumer containers on nodes A, B, and C and associated with task queues Q1, Q2, and Q3 constitute the set of consumer containers in the monitoring framework that need to be obtained this time.

[0057] Establish a specific method for determining whether a container is alive. For example, a specific detection request can be sent to the container periodically (such as once a minute). After receiving the request, the container must respond according to the established rules to determine whether the container is alive and can communicate normally. At the same time, it is stipulated that when the consumer container is judged to be alive, it needs to report multiple key information. These key information include container status (such as running, idle, busy, etc.), container name (a name that uniquely identifies the container to facilitate the distinction between different containers), consumer task queue (clearly specify which task queue or queues are being consumed), etc. And set the time interval for information reporting, data format and other requirements to ensure the standardization and processability of information.

[0058] The monitoring system waits for the consumer container to actively report information according to the set rules. Taking the previously set reporting once every minute as an example, the monitoring system receives data content containing key information such as container status, container name, and consumer task queue from each consumer container in the monitoring framework in each cycle. For example, the information reported by a container is "Container status: running, container name: Container_001, consumer task queue: Q1", and the monitoring system will continue to collect such reporting information from each container.

[0059] The key information reported by each consumer container is uniformly sorted and classified according to dimensions such as container name or node. For example, the information from all containers on node A is classified into one category, and the specific information of different containers is distinguished according to the name of each container in this category. For each container, the same type of key information reported multiple times is integrated. For example, for container Container_001, the container status information reported at different time points is arranged in chronological order, and the consumer task queue information is summarized, etc., to form a complete and organized information collection about the container.

[0060] Extract key elements that can reflect the operation status of the container from the integrated information set, and comprehensively construct the operation information of the consumer container. For example, by analyzing the changes in the container status over time, determine whether the container has frequent fluctuations or is in an abnormal state for a long time; understand the task load of the container based on the consumer task queue information; combine the container name and other identification information to accurately associate the operation trajectory of each container. In this way, we can eventually build a set of operation information system that contains multiple dimensions and can comprehensively present the actual operation status of the consumer container, providing strong data support for subsequent monitoring, analysis, and decision-making operations.

[0061] In the embodiment of the present application, obtaining the asynchronous task information and process identification information of the consumer container in progress includes: analyzing whether each asynchronous task in progress belongs to a distributed asynchronous task. If it belongs to a distributed asynchronous task, reading the corresponding asynchronous task information according to the preset information category list; determining the consumer process corresponding to the consumer container, and obtaining the process identification information of the consumer process and the distributed asynchronous task management.

[0062] First, it is necessary to comprehensively sort out all the asynchronous tasks currently in progress and clarify which consumer containers are responsible for processing each asynchronous task. This can be done by querying existing task allocation records or real-time task scheduling systems to obtain relevant information. For example, there are asynchronous tasks T1, T2, T3, etc., among which asynchronous task T1 is jointly processed by consumer containers C1 and C2, asynchronous task T2 is processed by consumer containers C3, C4, and C5, and asynchronous task T3 is only processed by consumer container C6. Through such detailed sorting, the set of consumer containers corresponding to each asynchronous task is clearly presented.

[0063] Based on the results of the above analysis, check the consumer container set corresponding to each asynchronous task one by one. If the number of consumer containers corresponding to an asynchronous task is greater than 1, that is, there are multiple consumer containers processing the same asynchronous task, then it can be determined that the asynchronous task belongs to a distributed asynchronous task. For example, the asynchronous task T1 mentioned above is processed by consumer containers C1 and C2, which meets the condition that multiple containers process the same task, so T1 is a distributed asynchronous task; while asynchronous task T3 is only processed by C6, which does not meet this condition and does not belong to a distributed asynchronous task. For all ongoing asynchronous tasks, they are analyzed according to this judgment logic to determine which asynchronous tasks belong to the category of distributed asynchronous tasks.

[0064] A list of asynchronous task information categories that need to be read is pre-set, which includes key information items such as the asynchronous task running start time (job_starttime), asynchronous task number (job_id), asynchronous task type (job_type), asynchronous task name (job_name), asynchronous task result (job_status), etc. This is to ensure that the information is read comprehensively and in a standardized manner, and that detailed content sufficient to reflect all aspects of the asynchronous task can be obtained.

[0065] For those tasks that have been determined to be distributed asynchronous tasks, such as the asynchronous task T1 determined earlier, read the corresponding information from the corresponding task management system or storage module according to the preset information category list. For example, by querying the relevant database table or calling a specific task query interface, the running start time of the asynchronous task T1 is obtained as "October 15, 2024 10:00:00", the task number is "T1_001", the task type is "data processing class", the task name is "customer order data integration", and the current task result is "in progress". For each task that belongs to a distributed asynchronous task, the corresponding information is accurately read in this way to prepare data for further processing and analysis.

[0066] Based on the previously determined distributed asynchronous tasks and the corresponding consumer containers, we focus again on the consumer containers involved in processing the distributed asynchronous tasks. For example, for the distributed asynchronous task T1, the corresponding consumer containers are C1 and C2, and these two containers are the focus of attention.

[0067] In the determined consumer container (such as C1, C2), use the process management tool at the operating system level or the monitoring module of the container itself to find the consumer process that is running and responsible for processing the corresponding distributed asynchronous task (such as T1). These tools and modules can present detailed information about each process in the container, including process name, process ID, tasks associated with the process, etc., so as to accurately identify the consumer process associated with a specific distributed asynchronous task. For example, in the consumer container C1, through the process view command, it is found that the process with process ID "P1001" is processing asynchronous task T1, then "P1001" is one of the consumer processes we are looking for.

[0068] Extract process identification information for distributed asynchronous task management from the identified consumer process. This may involve a variety of methods. A common approach is to check the property configuration of the process or a specific identification field. For example, some container environments will automatically add a custom identification tag to the process when it starts, or include a key identifier that can be used to distinguish in the process description information. In addition, unique process identification information can also be generated or extracted based on the unique identification of the container itself (such as the Docker container unique identification information docker_info) combined with some process-related features. For example, for the Docker container where the consumer process "P1001" is located, its docker_info is "Container_001_info". This docker_info can be combined with other related features such as the process ID to form a process identification information such as "Container_001_info_P1001", which is used to accurately distinguish different consumer processes in the distributed asynchronous task management scenario, so as to facilitate subsequent monitoring, scheduling, and data association operations of each process.

[0069] Step S102: monitor the container restart instruction triggered externally by the running environment where the consumer container is located.

[0070] In an embodiment of the present application, a monitoring mechanism for receiving external information is constructed. This mechanism can be built based on network communication protocols and related monitoring ports, so that it can monitor various types of messages from the outside in real time. For example, using common network communication foundations such as the TCP / IP protocol stack, a monitoring service is enabled on a specific port to ensure that instruction information from different sources can be captured. Then, it is clearly defined which external sources have the power to trigger container restart instructions. This may include the upper-level management module in the system, which will issue restart instructions based on the resource allocation of the overall system, business update requirements, etc.; at the same time, operation and maintenance personnel can also manually trigger restart instructions through special management consoles or command line tools and other operation interfaces, based on their manual observation of the system's operating status and maintenance strategies. These are external sources that need to be focused on. During the monitoring process, each message received must be parsed and judged according to the pre-set message format and instruction identification rules to distinguish which ones are real container restart instructions. For example, the restart instruction is required to have a specific command word, message header format, or carry the corresponding authority authentication identification. Only messages that meet these requirements will be recognized as valid container restart instructions. Once a container restart instruction that meets the requirements is identified, it will be passed to the subsequent processing module in a timely manner to carry out related processes such as restart risk assessment, to ensure that the entire container restart operation can be carried out in an orderly manner based on external triggers.

[0071] Step S103, responding to the container restart instruction, performing restart performance evaluation using the running information, asynchronous task information, and process identification information to obtain an evaluation result.

[0072] In the embodiment of the present application, restart performance evaluation is performed using operation information, asynchronous task information, and process identification information to obtain an evaluation result, including the following steps A1-A3:

[0073] Step A1: Use the running information to evaluate the restart status of the consumer container.

[0074] In an embodiment of the present application, the restart state of the consumer container is evaluated by using the operation information, including: extracting activation information and multiple indicator data corresponding to the consumer container from the operation information; analyzing the activation information to obtain the container state of the consumer container; comparing each indicator data with a preset threshold value of the response to obtain the container pressure of the consumer container; matching the container state and the container pressure with the restart conditions corresponding to each preset restart state to obtain the restart state of the container state and the container pressure hit.

[0075] First, obtain the collected and organized operation information of the consumer container. This information is usually stored in the corresponding monitoring system database or cache, covering various data records of the container during operation. Through specific data extraction programs or query statements, accurately filter out information related to liveness judgment from this massive amount of operation information, such as whether the container can normally respond to periodic detection requests, the timestamp of the most recent response, etc. This information can intuitively reflect whether the container is alive and communicative, which is the liveness judgment information.

[0076] At the same time, multiple key indicator data representing the internal operation status of the container are extracted from the operation information, including memory status (such as the amount of used memory, memory utilization rate, etc.), CPU utilization rate, and disk IO volume, etc. For example, from the container resource usage log recorded by the system, specific data such as the memory usage value, CPU utilization rate percentage, and disk IO read and write rate corresponding to each time node are extracted according to the time series to ensure that the extracted data is accurate and complete, laying the foundation for subsequent analysis and evaluation work.

[0077] The extracted liveness information is analyzed in depth to check whether the container can respond to external detection requests normally according to the preset rules and time intervals. If the container does not respond for a long time or the response is abnormal (such as the response content does not meet the specifications, the response timeout, etc.), it can be preliminarily judged that the container may be in a stopped state; if the container can respond normally on the surface, but the actual internal task processing is stagnant, such as no longer consuming the allocated asynchronous tasks, then the container can be determined to be in a suspended state; and when the container can respond to the detection request stably and normally without the above abnormal performance, the container is judged to be in a normal operating state. Through such a detailed analysis based on the liveness information, the specific container state of the consumer container can be clearly obtained.

[0078] For each indicator data extracted, such as memory status, CPU usage, disk IO volume, etc., the corresponding pre-set thresholds are retrieved. These thresholds are determined based on multiple factors such as the system's past operating experience, container performance carrying capacity, and normal business operation requirements. For example, the CPU usage threshold is set to 70%, the memory usage threshold is set to 80%, and the disk IO read and write rate threshold is set to several megabytes per second.

[0079] Then, the actual indicator data corresponding to each time node is compared with the corresponding preset thresholds one by one. If it is found that one of the attributes of CPU usage, memory, and disk IO exceeds its corresponding preset threshold multiple times in a short period of time (for example, in several consecutive monitoring cycles), this means that the consumer process in the container is too active in using the resource and consumes too many resources, causing the container to face greater pressure. It can be judged that the container is in a resource-constrained situation, that is, the container pressure is too high; on the contrary, if the indicator data are all stably maintained within the threshold range, it means that the container pressure is at a normal level. Through such comparative analysis, the container pressure status of the consumer container can be fully grasped.

[0080] Based on business needs and system characteristics, clear restart conditions are set for different restart states (such as frequent resource utilization rate is too high, real-time resource utilization rate is too high, and normal state). For example, for the restart state of frequent resource utilization rate is too high, the restart condition set may be "In the past 10 monitoring cycles, one of the attributes of CPU utilization rate, memory or disk IO has exceeded the corresponding threshold more than 6 times"; for the restart state of real-time resource utilization rate is too high, the set condition may be "At the current moment, the CPU utilization rate exceeds 80%, or the memory utilization rate exceeds 90%, or the disk IO read and write rate exceeds the preset high load rate value", etc.

[0081] Next, the container status (stop, suspended, or normal operation) and container pressure (too high or normal) obtained from the previous analysis are matched according to these preset restart conditions. If the container status meets the condition range required by a certain restart status, and the container pressure also matches it (for example, the container status is normal, but the container pressure shows the characteristics of frequent high resource utilization, which meets the corresponding set conditions), then it can be determined that the operation of the current consumer container hits the corresponding restart status, and it is clear whether it belongs to one of the frequent high resource utilization, real-time high resource utilization, or normal status, thereby providing an accurate basis for subsequent selection of appropriate restart strategies and other operations.

[0082] Step A2: Use the asynchronous task information and process identification information to evaluate the restart risk of the consumer container.

[0083] In an embodiment of the present application, asynchronous task information and process identification information are used to evaluate the restart risk of a consumer container, including: using asynchronous task types to classify asynchronous tasks currently being performed by the consumer container to obtain different types of asynchronous tasks; determining a task score corresponding to a current asynchronous task of the same type according to task indicator data of historical asynchronous tasks of the same type; determining the number of processes of the consumer process and the amount of monitored data packets from the process identification information; analyzing the interactive impact between the number of processes of the consumer process, the amount of data packets, and the task score of the asynchronous task, and obtaining the restart risk of the consumer container based on the interactive impact.

[0084] First, collect all the information related to the asynchronous tasks currently being performed by the consumer container, focusing on the type (job_type) field of each asynchronous task. This information may be stored in the database of the task management system or obtained by interacting with the task execution module in the container.

[0085] Then, all collected asynchronous tasks are identified and classified one by one according to the pre-set asynchronous task type classification standards. For example, if several large asynchronous task types such as data processing, file transfer, and computational analysis are set, when a specific asynchronous task is encountered, its job_type is marked as "data cleaning and integration", and after comparison, it is classified into the "data processing" type. By sorting out each asynchronous task by type in this way, all currently ongoing asynchronous tasks are finally divided into different types, clearly presenting the specific asynchronous task sets contained in each type, laying the foundation for further analysis and evaluation.

[0086] For each type of asynchronous task that has been classified, query the relevant task indicator data recorded when the asynchronous task of this type was executed in the past. This data covers key information such as the execution time, failure rate, and resource consumption rate of this type of asynchronous task in the past. It is usually stored in the historical task data warehouse and can be extracted through the corresponding query interface.

[0087] Take a certain type of asynchronous task as an example, such as the "data processing" type, and check the average consumption time, the proportion of failures, and the system resources consumed by each execution in its historical records (such as memory, CPU usage, etc.). Then, determine the corresponding task score for the currently executing asynchronous task of the same type based on the pre-defined score division rules. Generally speaking, the shorter the task consumption time, the lower the failure rate, and the less resources consumed, the easier it is to be consumed and completed, and the lower the score assigned accordingly. For example, after comprehensive comparison and analysis of historical data, for a specific asynchronous task of the "data processing" type that is relatively simple and has good past execution, its score is set to 1 point according to the rules (assuming that the score range is 1-5 points, 1 point means the easiest to consume), while for another asynchronous task of the same type that is relatively complex, takes a long time in historical execution, and has a slightly higher failure rate, it may be assigned 3 points. In this way, the corresponding task score is determined for each asynchronous task currently in progress under each type.

[0088] By obtaining the previously collected and stored process identification information, which contains unique identifiers used to distinguish different consumer processes and related attribute descriptions, it may be stored in a process management module or a coordination center of a distributed system in a specific data structure. In these process identification information, the number of consumer processes belonging to the current consumer container is accurately counted through data analysis and statistical methods. For example, if there are 10 processes with a specific container associated identifier and in an active state, then the number of consumer processes in the consumer container is 10.

[0089] At the same time, combined with data from related modules such as network monitoring and data transmission records, the data packets currently being transmitted, temporarily stored, or waiting to be processed in the container are monitored, and the specific number of data packets is counted. For example, by viewing the data packet transmission and reception records of the container recorded by the network traffic monitoring tool and the number of data packets in the internal buffer area, it is concluded that there are currently 50 data packets flowing or waiting to be processed in the container, thereby determining the key data of the data packet volume.

[0090] The three key factors of the previously determined consumer process number, data packet volume, and task scores corresponding to each asynchronous task are put together for comprehensive analysis.

[0091] From the perspective of the number of processes, if the number of processes is large, it means that the task execution logic and resource coordination within the container are more complicated. When restarting, it is necessary to coordinate many issues such as state switching, data preservation and recovery of multiple processes. Problems caused by mutual influence between processes are prone to occur, such as data inconsistency, and some processes cannot be restarted normally. Generally speaking, the difficulty of restarting will increase significantly and the waiting time will be longer. Therefore, the restart threshold of the container should be appropriately increased to measure the increase in restart risk.

[0092] As for the data packet volume, too many data packets indicate that the data transmission and cache pressure in the container is high. During the restart process, there may be risks such as data loss, damaged data integrity, and chaotic data packet processing, which will also increase the restart risk of the entire container.

[0093] Combined with the task scores of asynchronous tasks, higher-scoring asynchronous tasks usually mean that they are difficult to execute, consume more resources, or are prone to failure. When continuing to execute these tasks after the container is restarted, there may be more uncertainties and potential problems, further increasing the risk of restart.

[0094] Comprehensively analyze the interaction between these three factors. For example, when there are a large number of consumer processes, a large amount of data packets, and multiple high-scoring asynchronous tasks are running simultaneously, the risk of restarting the container will be very high. On the contrary, if the number of processes is moderate, the amount of data packets is small, and the asynchronous task scores are generally low, the restart risk will be relatively low. By weighing the potential impact of the interaction between the various factors on the restart, we can finally determine the current restart risk of the consumer container, providing a strong basis for subsequent decisions on whether to restart and what restart strategy to adopt.

[0095] As an example, the asynchronous task volume is classified according to the asynchronous task type job_type, and the scores are divided according to the previous asynchronous task execution consumption time, failure rate, and resource consumption rate. The easier the asynchronous task is to consume, the lower the score. num 、Number of packets Job num , asynchronous task score Jc i Conduct a second round of restart risk assessment:

[0096]

[0097] Where i is the number of asynchronous tasks of each score. For containers with different numbers of consumer processes, the restart risk value D status Should also be different.

[0098] Step A3: Generate an assessment result based on the restart status and restart risk.

[0099] When this application uses operation information to evaluate the restart status, it can accurately understand whether the container is in a state of excessive frequent resource utilization, excessive real-time resource utilization, or normal state by deeply analyzing key operation indicators such as container memory, CPU usage, disk IO, and liveness judgment, so as to avoid potential failures caused by blind restart and ensure system stability. In evaluating the restart risk with the help of asynchronous task information and process identification information, the task type, volume score, and multiple factors such as the number of consumer processes and the number of data packets are comprehensively considered to comprehensively weigh the difficulty of the task, the complexity of the process, and the pressure of data flow, and to warn in advance of the hidden dangers such as task execution obstruction and data loss that may be faced after the restart, so as to help formulate a comprehensive response strategy and effectively control the restart risk. The evaluation results generated based on the restart status and restart risk are like a clever "puzzle", which organically integrates the insights obtained from the two, comprehensively analyzes and weighs the pros and cons, and produces accurate and targeted conclusions covering the restart timing, the optimal restart strategy, etc., providing a clear action guide for operation and maintenance personnel to ensure that the restart of consumer containers is efficient, safe, and orderly, greatly improving the overall system operation and maintenance efficiency and reliability.

[0100] Step S104: acquiring a target restart strategy based on the restart instruction and the evaluation result, and controlling the consumer container to perform a restart operation according to the target restart strategy.

[0101] In the embodiment of the present application, the monitoring system obtains the target restart strategy based on the result of the restart evaluation and the received restart instruction. If the restart status is a frequent resource occupancy rate that is too high or a normal state, a real-time strategy is adopted, and the container is selected to restart in real time or rebuild in real time; if it is in a state where the real-time resource occupancy rate is too high, the waiting strategy is executed. If the container still maintains this state after waiting for three set cycles, a long-term abnormal alarm of the container is issued and fed back to the relevant personnel for investigation. When the restart instruction is a service update restart, one of the two methods of container real-time reconstruction and container waiting and then rebuilding is selected; if it is a healthy restart of the container, the two methods of container real-time restart and container waiting and then restart are selected; if it is an inactivated container restart instruction, the container real-time restart method is directly selected. If the container fails to be successfully pulled up, it is fed back to the relevant personnel for investigation; when encountering a false dead container restart instruction, the container real-time reconstruction method is selected to reset the container consumer process to restore the consumer environment. After determining the target restart strategy, the monitoring system controls the consumer container in an orderly manner according to the strategy to perform the corresponding restart operation to ensure that the entire restart process is carried out smoothly according to the established plan.

[0102] In an embodiment of the present application, the consumer container is controlled to perform a restart operation according to the target restart strategy, including: obtaining a key pair associated with the consumer container to be restarted, and sending the public key information in the key pair and the stop instruction corresponding to the target restart strategy to the cache, wherein the consumer process detects whether the cache contains the restart instruction based on the set rules, and when the stop instruction is detected, enters a dormant state and suspends reading and consuming subsequent asynchronous tasks; continuously monitors the cache, and when it is detected that there is no real-time data packet of the consumer container to be restarted in the cache, performs the restart operation according to the target restart strategy, and after the consumer container is restarted, terminates the original consumer process and clears the stop instruction in the cache.

[0103] First, in the architecture of the entire system, a special key management module is set up to generate, store and manage the key pairs corresponding to each consumer container. After the consumer container to be restarted is determined, the system will use the unique identification information of the container, such as the unique number or name of the container, to perform an accurate search in the key management module. For example, if the consumer container to be restarted is named "Container_123", the system will use this name as an index condition in the key management database to search for matching key pair records. Once the corresponding record is found, the key pair dedicated to this "Container_123" consumer container can be successfully obtained. This key pair contains two parts, the public key and the private key. They are generated by a specific encryption algorithm and have a high degree of security and uniqueness. They are an important basis for subsequent safe and orderly restart operations.

[0104] After obtaining the key pair of the consumer container to be restarted, extract the public key information from it. At the same time, based on the predetermined target restart strategy, such as whether to choose real-time restart, restart after waiting for a certain period, or other specific restart methods, generate a stop instruction that matches it. The content of this stop instruction clearly informs the consumer process in the container that it needs to suspend the current task processing and prepare for the upcoming restart operation, so as to avoid data inconsistency, resource conflicts and other problems caused by continuing to execute tasks during the restart process.

[0105] Then, using the communication interface between the system and the cache (usually a cache tool like Redis), the public key information and stop instructions are sent and stored in the cache in a predetermined data format. For example, by calling the SET command provided by the Redis client, such as executing "SETContainer_123_PublicKey[specific public key content]" and "SETContainer_123_StopInstruction[specific stop instruction content]", the corresponding information is successfully stored in the specified key-value pair position in Redis, so that the consumer process in the subsequent container can detect and obtain these key information, so as to coordinate and control the entire restart process.

[0106] Inside the consumer container, each consumer process follows the pre-set rules when executing tasks, and periodically (for example, every certain time interval, such as every 10 seconds) accesses the cache (for example, Redis) to check whether there is a restart instruction related to the container it is in. This detection process is implemented through the cache access module integrated inside the process, which sends the corresponding query request to Redis and searches for the corresponding key-value pair content according to the pre-set key name format (for example, "Container_123_StopInstruction" is the stop instruction key name corresponding to the container "Container_123").

[0107] When the consumer process detects that there is indeed a stop instruction for its container in the cache, it will immediately start the hibernation mechanism. In the hibernation state, the consumer process will suspend all reading and consumption operations of subsequent asynchronous tasks, release the currently occupied system resources such as memory and CPU, and enter a waiting state. The purpose of this is to ensure that before the container is restarted, there will be no data confusion, resource contention, or interference with the restart process due to the process continuing to execute tasks, thereby ensuring the stability of the entire system environment and creating good conditions for the upcoming restart operation.

[0108] The system has a dedicated monitoring module that continuously monitors the cache (such as Redis), focusing on the real-time data packets related to the consumer container to be restarted. It periodically scans all key-value pairs in Redis that begin with the container identifier to determine whether there are still data packets representing real-time task data being transmitted or processed.

[0109] After multiple monitorings, it was found that the real-time data packets of the consumer container to be restarted no longer exist in the cache, which means that there are no ongoing and unfinished data processing tasks in the current container, and the environment is suitable for restart operations. The monitoring module will perform the corresponding restart actions according to the previously determined target restart strategy. For example, if the target restart strategy is real-time restart, the monitoring module will immediately send instructions to the container management component to trigger the container restart process; if the target restart strategy is to wait for a certain period of time before restarting, the monitoring module will continue to poll and monitor according to the set waiting time until the waiting conditions are met, and then execute the restart operation, so as to ensure that the restart operation is carried out in an orderly manner at the right time, avoid various potential problems caused by premature or improper restart, and ensure the stable operation of the entire system.

[0110] When the consumer container completes the restart process according to the established target restart strategy, the system will locate all the original consumer processes running in the container through the relevant mechanisms of container management, such as sending specific signals to the operating system in the container or calling the container management API, etc. (It can be accurately found based on the unique identifier of the process, such as the process ID and other information), and then execute the termination (kill) operation to forcibly end these old consumer processes and release the system resources they occupy, so as to prevent resource conflicts with the newly generated consumer processes or interfere with the normal operation of the new processes.

[0111] At the same time, the system will again use the interactive interface with the cache (such as Redis) to find and delete the stop instruction information previously stored in the cache corresponding to this container. For example, by executing the Redis DEL command, such as "DELContainer_123_StopInstruction", the key-value pair corresponding to the stop instruction is completely deleted from Redis. This is done to clear the instruction that plays a temporary control role during the restart process, to prevent subsequent new consumer processes from mistakenly detecting this stop instruction after startup, and then abnormal behavior occurs, to ensure that the cache environment is clean and tidy, to create good conditions for subsequent consumer processes to consume tasks normally, and to ensure that the entire system can smoothly return to normal operation.

[0112] As an example, Figure 2As shown in the figure, the process is started by "starting", and then the internal state of Docker is detected. If the consumer sequence survives, the asynchronous task currently consumed is further detected; if the consumer sequence does not survive, the consumer process is initialized. When asynchronous task consumption is detected, it will wait for the consumer process to consume the task; if there is no asynchronous task consumption, the restart Docker command is issued. Then the Docker container is restarted, and finally the consumer process is initialized and the whole process ends. The whole process determines whether to restart the Docker container by detecting the internal state of Docker and the consumption of asynchronous tasks, and performs corresponding initialization operations when necessary.

[0113] like Figure 3 As shown, the consumer process is initialized. Then it checks whether Redis has a restart instruction. If so, the consumer stops listening to the queue; if not, the consumer reads the asynchronous task from the queue. After reading the task, it sends the current asynchronous task information data packet, then consumes the asynchronous task, deletes the current asynchronous task information data packet after completion, and finally completes the consumption task and continues to consume. If a restart instruction is detected, the consumer process goes dormant and waits for the container to restart. The entire process determines whether the consumer continues to consume asynchronous tasks by detecting the restart instruction in Redis.

[0114] like Figure 4 As shown in the figure, the "start" startup process is started, and then the restart instruction is received. Then the restart instruction type is judged. If it is an abnormal restart instruction, it fails to pass the verification; if it is not an abnormal restart instruction, the restart status is detected. If the polled restart status is no, the restart status is polled again; if the polled restart status is yes, it is determined whether it is a real-time restart strategy. If it is a real-time restart strategy, the restart risk detection is performed. If the restart can be performed, the restart instruction is issued, otherwise the restart status is polled. If it is not a real-time restart strategy, the restart status is polled. If the polling number reaches the upper limit, an abnormal alarm is issued, and finally the process ends. The whole process determines whether to issue a restart instruction by detecting the restart instruction type, restart status and restart risk.

[0115] In this embodiment, a restart device for a consumer container is also provided, which is used to implement the above embodiments and preferred implementations, and will not be repeated for what has been described. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0116] This embodiment provides a restart device for a consumer container, such as Figure 5 As shown, including:

[0117] The acquisition module 501 is used to acquire the operation information of the consumer container deployed on multiple nodes in real time, and acquire the asynchronous task information and process identification information being performed by the consumer container;

[0118] A monitoring module 502 is used to monitor the container restart instruction triggered externally by the running environment where the consumer container is located;

[0119] An evaluation module 503 is used to evaluate the restart performance based on the container restart instruction using the operation information, the asynchronous task information, and the process identification information to obtain an evaluation result;

[0120] The execution module 504 is used to obtain a target restart strategy based on the restart instruction and the evaluation result, and control the consumer container to perform a restart operation according to the target restart strategy.

[0121] In an embodiment of the present application, an acquisition module 501 is used to acquire a consumer container in a monitoring framework, wherein the monitoring framework is constructed using a consumption task queue associated with the consumer container and a specific number of consumer containers deployed at each node; acquire multiple key information reported by the consumer container in the monitoring framework according to a container activation method; and construct operation information of the consumer container based on the key information.

[0122] In the embodiment of the present application, the acquisition module 501 is used to analyze whether each ongoing asynchronous task belongs to a distributed asynchronous task. If it belongs to a distributed asynchronous task, the corresponding asynchronous task information is read according to the preset information category list; the consumer process corresponding to the consumer container is determined, and the process identification information of the consumer process and the distributed asynchronous task management is obtained.

[0123] In an embodiment of the present application, the evaluation module 503 is used to evaluate the restart status of the consumer container using the operation information; evaluate the restart risk of the consumer container using the asynchronous task information and the process identification information; and generate an evaluation result based on the restart status and the restart risk.

[0124] In the embodiment of the present application, the evaluation module 503 is used to extract activation information and multiple indicator data corresponding to the consumer container from the operation information; analyze the activation information to obtain the container state of the consumer container; compare each indicator data and the corresponding preset threshold to obtain the container pressure of the consumer container; match the container state and the container pressure with the restart conditions corresponding to each preset restart state to obtain the restart state hit by the container state and the container pressure.

[0125] In an embodiment of the present application, the evaluation module 503 is used to classify the asynchronous tasks currently performed by the consumer container by using the asynchronous task type to obtain different types of asynchronous tasks; determine the task score corresponding to the current asynchronous task of the same type according to the task indicator data of the historical asynchronous tasks of the same type; determine the number of processes of the consumer process and the amount of monitored data packets from the process identification information; analyze the interactive impact between the number of processes of the consumer process, the amount of data packets and the task score of the asynchronous task, and obtain the restart risk of the consumer container based on the interactive impact.

[0126] In an embodiment of the present application, the execution module 504 is used to obtain a key pair associated with the consumer container to be restarted, and send the public key information in the key pair and the stop instruction corresponding to the target restart strategy to the cache, wherein the consumer process detects whether the cache contains a restart instruction based on the set rules, and when the stop instruction is detected, it enters a dormant state and suspends reading and consuming subsequent asynchronous tasks; the cache is continuously monitored, and when it is detected that there is no real-time data packet of the consumer container to be restarted in the cache, the restart operation is performed according to the target restart strategy, and after the consumer container is restarted, the original consumer process is terminated and the stop instruction in the cache is cleared.

[0127] See also Figure 6 , Figure 6 is a schematic diagram of the structure of an electronic device provided by an optional embodiment of the present invention, such as Figure 6 As shown, the electronic device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process instructions executed in the electronic device, including instructions stored in or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple electronic devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 6 A processor 10 is taken as an example.

[0128] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0129] The memory 20 stores instructions executable by at least one processor 10, so that the at least one processor 10 executes the method shown in the above embodiment.

[0130] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created by the use of an electronic device based on the presentation of a small program landing page, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the electronic device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0131] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.

[0132] The electronic device further comprises a communication interface 30 for the electronic device to communicate with other devices or a communication network.

[0133] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0134] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A method for restarting a consumer container, characterized in that: The method comprises: Acquire the running information of the consumer container deployed on multiple nodes in real time, and acquire the asynchronous task information and process identification information being performed by the consumer container; Listening for container restart instructions triggered externally by the operating environment where the consumer container is located; In response to the container restart instruction, a restart performance evaluation is performed using the running information, the asynchronous task information, and the process identification information to obtain an evaluation result; A target restart strategy is acquired based on the restart instruction and the evaluation result, and the consumer container is controlled to perform a restart operation according to the target restart strategy.

2. The method according to claim 1, characterized in that The real-time acquisition of the operation information of the consumer containers deployed on multiple nodes includes: Obtaining a consumer container in a monitoring framework, wherein the monitoring framework is constructed using a consumption task queue associated with the consumer container and a specific number of the consumer containers deployed on each node; Acquire multiple key information reported by the consumer container in the monitoring framework according to the container activity determination method; The operation information of the consumer container is constructed based on the key information.

3. The method according to claim 1, characterized in that The obtaining the asynchronous task information and process identification information being performed by the consumer container includes: Analyze whether each ongoing asynchronous task belongs to a distributed asynchronous task; If it is a distributed asynchronous task, read the corresponding asynchronous task information according to the preset information category list; A consumer process corresponding to the consumer container is determined, and process identification information related to the distributed asynchronous task management in the consumer process is obtained.

4. The method according to claim 1, characterized in that: The restart performance evaluation is performed using the operation information, the asynchronous task information, and the process identification information to obtain an evaluation result, including: evaluating a restart status of the consumer container using the operation information; Assessing the restart risk of the consumer container by using the asynchronous task information and the process identification information; The assessment result is generated based on the restart status and the restart risk.

5. The method according to claim 4, characterized in that The using the operation information to evaluate the restart status of the consumer container includes: Extracting activity determination information and multiple indicator data corresponding to the consumer container from the operation information; Analyzing the activation information to obtain the container status of the consumer container; Comparing each indicator data with a preset threshold value of the response to obtain the container pressure of the consumer container; The container state and the container pressure are matched with the restart conditions corresponding to each preset restart state to obtain a restart state matched by the container state and the container pressure.

6. The method according to claim 4, characterized in that The using the asynchronous task information and the process identification information to evaluate the restart risk of the consumer container includes: Using the asynchronous task type, classify the asynchronous tasks currently being performed by the consumer container to obtain different types of asynchronous tasks; Determine the task score corresponding to the current asynchronous task of the same type according to the task indicator data of the historical asynchronous tasks of the same type; Determining the process number of the consumer process and the amount of monitored data packets from the process identification information; The interactive influence among the process quantity of the consumer process, the data packet volume and the task score of the asynchronous task is analyzed, and the restart risk of the consumer container is obtained based on the interactive influence.

7. The method according to claim 1, characterized in that The controlling the consumer container to perform a restart operation according to the target restart strategy includes: Obtain a key pair associated with the consumer container to be restarted, and send the public key information in the key pair and the stop instruction corresponding to the target restart strategy to the cache, wherein the consumer process detects whether the cache contains a restart instruction based on a set rule, and when a stop instruction is detected, enters a dormant state and suspends reading and consuming subsequent asynchronous tasks; The cache is continuously monitored, and when it is detected that there is no real-time data packet of the consumer container to be restarted in the cache, a restart operation is performed according to the target restart strategy, and after the consumer container is restarted, the original consumer process is terminated, and the stop instruction in the cache is cleared.

8. A restart device for a consumer container, characterized in that: The device comprises: An acquisition module, used to acquire in real time the operation information of the consumer container deployed on multiple nodes, and to acquire the asynchronous task information and process identification information being performed by the consumer container; A monitoring module, used to monitor the container restart instruction triggered externally by the operating environment where the consumer container is located; An evaluation module, configured to perform restart performance evaluation based on the container restart instruction by using the operation information, the asynchronous task information, and the process identification information to obtain an evaluation result; An execution module is used to obtain a target restart strategy based on the restart instruction and the evaluation result, and control the consumer container to perform a restart operation according to the target restart strategy.

9. An electronic device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the method according to any one of claims 1 to 7 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the method according to any one of claims 1 to 7.

Images