System and method for safe stop service

Abstract

The system and method for safe service stopping provided by the application, the system comprises: a communication service module acquires a message instruction, and writes the message instruction into a message queue; a service node of a server cyclically takes out the message instruction from the message queue; when the message instruction is a stop instruction and is inconsistent with the service node, the message instruction is written into the message queue again; when the message instruction is a stop instruction and is consistent with the service node, the service node is stopped after a running business thread of the service node is running. The system can safely stop the service after normal business processing by sending the stop instruction, and avoids the problems of message interruption and data loss caused by directly killing the process to end the program. The system can safely start and stop the service at any time even in the scene of high concurrency or high real-time requirement, so that the system operation and maintenance and program updating are safer.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, specifically relating to a system and method for securely stopping services. Background Technology

[0002] Servers hosting applications typically require secure shutdown. Secure shutdown means waiting for the service to complete its processing before stopping it. This prevents abrupt interruptions to message processing when the service stops, ensuring high availability and security of the system.

[0003] However, most current methods for stopping programs involve first identifying the process ID of the currently running program and then killing the process directly using kill -9. This also causes some services that have not finished executing to exit directly. This is fatal for some high-concurrency or real-time systems, as it poses a risk of losing messages that are being processed and cannot achieve safe service termination. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a system and method for securely stopping services, achieving secure service termination and avoiding the message loss problem inherent in traditional service termination methods.

[0005] A system for safely stopping service includes:

[0006] Communication service module: used to obtain message commands and write them to the message queue;

[0007] Message queue: Used for transmitting message commands;

[0008] Server-side: Includes at least one service node; the service node is used to cyclically retrieve message instructions from the message queue; when the message instruction is a stop instruction and is inconsistent with the service node, the message instruction is rewritten into the message queue; when the message instruction is a stop instruction and is consistent with the service node, the service node is stopped after the business thread currently running on the service node has finished running.

[0009] Furthermore, the message instruction includes the processing node name and the instruction type; the processing node name is used to identify the name of the service node that needs to execute the message instruction; the instruction type is used to identify the type of message instruction.

[0010] Stop commands also have a lifecycle; when a stop command's lifecycle expires, it is removed from the message queue.

[0011] Furthermore, the service nodes are specifically used for:

[0012] If the message instruction is a business instruction, a separate business thread is allocated through the thread pool to perform normal business processing according to the message instruction.

[0013] If the message instruction type is a stop instruction, determine whether the processing node name in the message instruction is the same as the service node name; if not, define the message instruction and the service node as inconsistent; if so, define the message instruction and the service node as consistent.

[0014] Furthermore, service nodes are also used for:

[0015] If the message instruction type is "pause receiving business messages", then stop receiving all business instructions.

[0016] If the message instruction type is "re-receive business message instruction", then re-receive all business instructions.

[0017] Furthermore, the server is also used for:

[0018] When the entire application is stopped, a stop command is generated and sent to each service node in the application.

[0019] Secondly, a method for securely stopping service includes:

[0020] The communication service module obtains message instructions and writes them into the message queue;

[0021] Message queues transmit message commands;

[0022] Each service node on the server side cyclically retrieves message instructions from the message queue; when the message instruction is a stop instruction and is inconsistent with the service node, the message instruction is rewritten into the message queue; when the message instruction is a stop instruction and is consistent with the service node, the service node stops running after the business thread currently running on the service node finishes running.

[0023] Furthermore, the message instruction includes the processing node name and the instruction type; the processing node name is used to identify the name of the service node that needs to execute the message instruction; the instruction type is used to identify the type of message instruction.

[0024] Stop commands also have a lifecycle; when a stop command's lifecycle expires, it is removed from the message queue.

[0025] Furthermore, after retrieving the message instruction from the message queue, the service node specifically includes:

[0026] If the message instruction is a business instruction, a separate business thread is allocated through the thread pool to perform normal business processing according to the message instruction.

[0027] If the message instruction type is a stop instruction, determine whether the processing node name in the message instruction is the same as the service node name; if not, define the message instruction and the service node as inconsistent; if so, define the message instruction and the service node as consistent.

[0028] Furthermore, after retrieving the message instruction from the message queue, the service node also includes:

[0029] If the message instruction type is "pause receiving business messages", then stop receiving all business instructions.

[0030] If the message instruction type is "re-receive business message instruction", then re-receive all business instructions.

[0031] Furthermore, it also includes:

[0032] When the server stops the entire application, it generates and initiates a stop command to each service node in the application.

[0033] As can be seen from the above technical solution, the system and method for securely stopping services provided by this invention, by sending a stop command, enables services to be securely stopped after normal business processing, avoiding the problems of message interruption and data loss caused by directly killing the process to terminate the program. Even in scenarios with high concurrency or high real-time requirements, this system can securely start and stop services at any time, making system operation and maintenance and program updates safer. This system can also flexibly securely stop specified service nodes, facilitating the updating of service node programs and achieving secure program updates. Attached Figure Description

[0034] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0035] Figure 1 A block diagram of a system that has stopped providing services for safety reasons.

[0036] Figure 2 A flowchart illustrating the process of handling normal business operations for a system that has been shut down for security reasons.

[0037] Figure 3 Flowchart of the method for stopping a system that needs to be safely shut down. Detailed Implementation

[0038] The embodiments of the technical solution of the present invention will now be described in detail with reference to the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and are therefore merely examples and should not be used to limit the scope of protection of the present invention. It should be noted that, unless otherwise stated, the technical or scientific terms used in this application should have the ordinary meaning understood by those skilled in the art to which this invention pertains.

[0039] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0040] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0041] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrases "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0042] In existing service shutdown methods, if you want to stop service node n on the server side, you usually kill the process corresponding to service node n. This will have the following problems: when service node n is processing messages using resources allocated by the thread pool, if the process of service node n is killed, the messages being processed will also be interrupted, resulting in the loss of the data being processed.

[0043] Example:

[0044] A system for safely stopping service, see [link to documentation]. Figure 1 ,include:

[0045] Communication service module 1: Used to obtain message instructions and write the message instructions into message queue 2;

[0046] Message queue 2: Used for transmitting message commands;

[0047] Server 3: Includes at least one service node; the service node is used to cyclically retrieve message instructions from message queue 2; when the message instruction is a stop instruction and is inconsistent with the service node, the message instruction is rewritten into message queue 2; when the message instruction is a stop instruction and is consistent with the service node, the service node is stopped after the business thread currently running on the service node has finished running.

[0048] In this embodiment, the communication service module 1 can communicate with external devices based on an external communication protocol, receive message instructions requested by the external devices, and write the message instructions into message queue 2. The message instructions can be business instructions, stop instructions, instructions to pause receiving business messages, instructions to resume receiving business messages, etc. Business instructions are used for normal business processing by service nodes, while stop instructions are used to stop a specific service node in the application. The message instructions can include the name of the service node to be executed and the instruction type. Message queue 2 can be a third-party communication middleware, such as IBMMQ or RabbitMQ. It is a message queue independent of server 3 and is used to transmit message instructions to be processed.

[0049] In this embodiment, server 3 is mainly used to read and process message instructions from message queue 2. Server 3 can be a single-machine application consisting of one service node or a cluster service consisting of multiple service nodes. Each service node in server 3 cyclically retrieves message instructions from message queue 2 and determines whether to stop the service node based on the message instructions. For example, if the message instruction read by service node A is a business instruction, normal business processing is performed; if the message instruction read by service node A is a stop instruction from service node B, it means that the message instruction is inconsistent with the service node, so the message instruction is rewritten into message queue 2, waiting for other service nodes to read and process it. If the message instruction read by service node A is a stop instruction from service node A, it means that the message instruction is consistent with the service node, and service node A needs to be stopped. In this case, the service node A will only stop running after the business thread currently running by service node A has finished running.

[0050] Figure 2 This is the normal business processing flow. Communication service module 1 stores received message instructions into message queue 2. The server-side service node continuously retrieves message instructions from message queue 2. If the message instruction is a business instruction, the thread pool allocates a business thread to the service node, allowing the business thread to perform normal business processing independently based on the business instruction.

[0051] This system for securely stopping services uses stop commands to ensure that services only cease after completing normal business processing, avoiding the message interruptions and data loss that occur when terminating programs by directly killing processes. Even in high-concurrency or real-time-critical scenarios, the system can securely start and stop services at any time, making system maintenance and program updates safer. The system also allows for flexible and secure stopping of specified service nodes, facilitating secure updates to those nodes' programs.

[0052] Furthermore, in some embodiments, the message instruction includes a processing node name and an instruction type; the processing node name is used to identify the name of the service node that needs to execute the message instruction; the instruction type is used to identify the type of message instruction.

[0053] Stop commands also have a lifecycle; when a stop command's lifecycle expires, it is removed from the message queue.

[0054] In this embodiment, the message instruction includes at least two types of information: the processing node name and the instruction type. The processing node name identifies the name of the service node to be processed. For example, when you want to stop service node A, the processing node name is the name of service node A. The instruction type is a stop flag, mainly used to determine whether the message instruction is a stop instruction. For example, if the instruction type of message instruction A is stop or a specified value, it means that message instruction A is a stop instruction.

[0055] In this embodiment, the stop command is subject to a lifecycle limitation when it is transmitted in the message queue. When the stop command in the message queue exceeds its lifecycle, it is automatically removed from the message queue to prevent the stop command from remaining in the message queue after it has not been processed by any service node.

[0056] Furthermore, in some embodiments, the service node is specifically used for:

[0057] If the message instruction is a business instruction, a separate business thread is allocated through the thread pool to perform normal business processing according to the message instruction.

[0058] If the message instruction type is a stop instruction, determine whether the processing node name in the message instruction is the same as the service node name; if not, define the message instruction and the service node as inconsistent; if so, define the message instruction and the service node as consistent.

[0059] In this embodiment, the service node first determines whether the message instruction is a stop instruction based on the instruction type. If not, the instruction type is a business instruction, and normal business processing can proceed. If it is, the stop instruction is determined by checking if the processing node name in the message instruction matches the name of the service node. For example, assuming the service to be stopped is service node A, the processing node name in the message instruction is the name of service node A. If service node A reads this message instruction, the stop instruction is defined as consistent with service node A because the processing node name in the message instruction is the name of service node A. If service node C reads this message instruction, the stop instruction is inconsistent with service node C because the processing node name in the message instruction is not the name of service node C.

[0060] Furthermore, in some embodiments, the service node is specifically used for:

[0061] If the message instruction type is "pause receiving business messages", then stop receiving all business instructions.

[0062] If the message instruction type is "re-receive business message instruction", then re-receive all business instructions.

[0063] In this embodiment, the message command type can be further extended to include pause receiving business message commands and resume receiving business message commands. When the command type is a pause receiving business message command, the service node will stop receiving all business commands. At this time, all thread pool resources of the service node are idle and will not occupy too many server resources. When the command type is a resume receiving business message command, the service node will resume receiving business commands. In this way, by sending pause / resume receiving business message commands to any one or more service nodes, this method facilitates control over the maximum resource consumption of each service node and prevents the risk of overall downtime due to insufficient server resources when processing large amounts of high-concurrency data.

[0064] Furthermore, in some embodiments, the server is also used for:

[0065] When the entire application is stopped, a stop command is generated and sent to each service node in the application.

[0066] In this embodiment, the system for safely stopping services can support stopping a service node or an application. Since an application typically needs to be associated with one or more service nodes, when an application needs to be stopped, a stop command is generated and sent to each service node within the application. The server needs to determine whether all service nodes associated with the application have stopped running. If all have stopped, it means the application is not processing any business and can safely exit. If some service nodes are still running, it means the application is still executing business; in this case, the application cannot be exited until all service nodes associated with it have stopped.

[0067] A method for securely stopping service includes:

[0068] The communication service module obtains message instructions and writes them into the message queue;

[0069] Message queues transmit message commands;

[0070] Each service node on the server side cyclically retrieves message instructions from the message queue; when the message instruction is a stop instruction and is inconsistent with the service node, the message instruction is rewritten into the message queue; when the message instruction is a stop instruction and is consistent with the service node, the service node stops running after the business thread currently running on the service node finishes running.

[0071] See Figure 3 After the service node on the server reads the message instruction from the message queue, it determines whether the message instruction is a stop instruction. If not, it allocates thread resources through the thread pool to process the message separately. If it is, it checks whether the processing node name in the message instruction is the name of the service node. If not, it puts the stop instruction back into the message queue. If it is, it waits for the thread in the thread pool to finish processing before exiting the service.

[0072] Furthermore, the message instruction includes the processing node name and the instruction type; the processing node name is used to identify the name of the service node that needs to execute the message instruction; the instruction type is used to identify the type of message instruction.

[0073] Stop commands also have a lifecycle; when a stop command's lifecycle expires, it is removed from the message queue.

[0074] Furthermore, after retrieving the message instruction from the message queue, the service node specifically includes:

[0075] If the message instruction is a business instruction, a separate business thread is allocated through the thread pool to perform normal business processing according to the message instruction.

[0076] If the message instruction type is a stop instruction, determine whether the processing node name in the message instruction is the same as the service node name; if not, define the message instruction and the service node as inconsistent; if so, define the message instruction and the service node as consistent.

[0077] Furthermore, after retrieving the message instruction from the message queue, the service node also includes:

[0078] If the message instruction type is "pause receiving business messages", then stop receiving all business instructions.

[0079] If the message instruction type is "re-receive business message instruction", then re-receive all business instructions.

[0080] Furthermore, it also includes:

[0081] When the server stops the entire application, it generates and initiates a stop command to each service node in the application.

[0082] The methods provided in the embodiments of the present invention are for brief description. For any parts not mentioned in the embodiments, please refer to the corresponding content in the foregoing embodiments.

[0083] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered within the scope of the claims and specification of the present invention.

Claims

1. A system for safely stopping service, characterized in that, include: Communication service module: used to obtain message instructions and write the message instructions into the message queue; Message queue: used to transmit the message instructions; Server-side: Includes multiple service nodes; each service node is used to cyclically retrieve the message instruction from the message queue; when the message instruction is a stop instruction and is inconsistent with the service node, the message instruction is rewritten into the message queue, waiting for other service nodes to read and process it; when the message instruction is a stop instruction and is consistent with the service node, the service node is stopped after the business thread currently running on the service node has finished running. The service node is specifically used for: If the message instruction is a business instruction, a separate business thread is allocated through the thread pool to perform normal business processing according to the message instruction; If the instruction type of the message instruction is a stop instruction, determine whether the processing node name in the message instruction is the name of the service node; If not, define the message instruction as inconsistent with the service node; If so, define the message instruction to be consistent with the service node; The service node is also used for: If the instruction type of the message instruction is a pause receiving business message instruction, then all business instructions will be stopped; at this time, all thread pool resources of the service node will be idle and will not occupy too many server resources. If the instruction type of the message instruction is a re-receive service message instruction, then re-receive all service instructions; By sending pause / start command to any one or more service nodes, it is easy to control the maximum resource consumption of each service node; The server is also used for: When the entire application is stopped, a stop command is generated and initiated for each of the service nodes in the application.

2. The system for securely stopping service according to claim 1, characterized in that, The message instruction includes a processing node name and an instruction type; the processing node name is used to identify the name of the service node that needs to execute the message instruction; the instruction type is used to identify the type of the message instruction; The stop instruction also has a lifecycle; when the lifecycle of the stop instruction expires, it is removed from the message queue.

3. A method for safely stopping service, characterized in that, include: The communication service module obtains the message instruction and writes the message instruction into the message queue; The message queue transmits the message instructions; In the server, each service node cyclically retrieves the message instruction from the message queue; when the message instruction is a stop instruction and is inconsistent with the service node, the message instruction is rewritten into the message queue, waiting for other service nodes to read and process it; when the message instruction is a stop instruction and is consistent with the service node, the service node stops running after the business thread it is currently running finishes running. After the service node retrieves the message instruction from the message queue, the specific steps include: If the message instruction is a business instruction, a separate business thread is allocated through the thread pool to perform normal business processing according to the message instruction; If the instruction type of the message instruction is a stop instruction, determine whether the processing node name in the message instruction is the name of the service node; if not, define that the message instruction is inconsistent with the service node; if yes, define that the message instruction is consistent with the service node. After retrieving the message instruction from the message queue, the service node further includes: If the instruction type of the message instruction is a pause receiving business message instruction, then all business instructions will be stopped; at this time, all thread pool resources of the service node will be idle and will not occupy too many server resources. If the instruction type of the message instruction is a re-receive service message instruction, then re-receive all service instructions; By sending pause / start command to any one or more service nodes, it is easy to control the maximum resource consumption of each service node; When the server stops the entire application, it generates and initiates the stop command to each service node in the application.

4. The method for securely stopping service according to claim 3, characterized in that, The message instruction includes a processing node name and an instruction type; the processing node name is used to identify the name of the service node that needs to execute the message instruction; the instruction type is used to identify the type of the message instruction; The stop instruction also has a lifecycle; when the lifecycle of the stop instruction expires, it is removed from the message queue.

Images