Method and apparatus for application decommissioning in distributed system, device, system, and medium

Abstract

The present disclosure provides a method and apparatus for application decommissioning in a distributed system, a device, a system, and a medium. The method comprises: in response to a decommissioning request for a target application, determining the distributed tasks in a node corresponding to the target application; if there is a first distributed task that the node acts as a working node among the distributed tasks corresponding to the target application, upon completing subtasks to be processed by the node in the first distributed task, determining that the node has completed processing of the first distributed task; if there is a second distributed task that the node acts as a primary node, upon completing all the plurality of subtasks comprised in the second distributed task, determining that the node has completed processing of the second distributed task; and upon completing all the distributed tasks corresponding to the target application, exiting the target application. Thus, application decommissioning operation in a distributed scenario can be achieved, ensuring the lossless operation of distributed tasks in the application deployment and restart process.

Description

[0001]This disclosure claims priority to a patent application filed with the China Patent Office on December 28, 2023, entitled "Method, Apparatus, Device, System, and Medium for Deleting Applications in a Distributed System," application number 202311849912.1, the entire contents of which are incorporated herein by reference. TECHNICAL FIELD This disclosure relates to the field of computer technology, and more particularly to a method, apparatus, device, system, and medium for deleting applications in a distributed system. BACKGROUND With the continuous development of cloud computing technology, more and more users are relying on cloud services to process tasks. Cloud services allow users to deploy related applications and process tasks through them. When an application needs to be upgraded, the application can be taken offline first, then restarted after the upgrade is successful. Tasks can then be processed using the new version of the application. Current application deleting methods effectively deleting applications that handle ordinary tasks, but are not suitable for applications that handle distributed tasks and struggle to meet the application deleting requirements of distributed systems. SUMMARY OF THE INVENTION The present disclosure provides a method, apparatus, device, system, and medium for shutting down an application in a distributed system, so as to implement a graceful shutdown function for distributed tasks corresponding to applications in the distributed system. In a first aspect, embodiments of the present disclosure provide a method for offline application in a distributed system, the distributed system comprising multiple nodes for processing distributed tasks; any distributed task is jointly completed by a master node and at least one worker node, the master node being configured to allocate multiple subtasks included in the distributed task, and the worker node being configured to process the allocated subtasks; the method, applied to any one of the multiple nodes, comprising: in response to a target application offline request, determining at least one distributed task corresponding to the target application in the node; if, in the at least one distributed task corresponding to the target application, there is a first distributed task for which the node is a worker node, determining that the node has completed processing of the first distributed task after completing a subtask to be processed by the node in the first distributed task; if there is a second distributed task for which the node is a master node, determining that the node has completed processing of the second distributed task after all multiple subtasks included in the second distributed task have been completed; and after all distributed tasks corresponding to the target application have been completed, exiting the target application to offline the target application.Optionally, the method further includes: in response to a target application's offline request, stopping accepting new tasks; wherein the tasks include distributed tasks issued by the server and received by the node as a master node, and / or subtasks corresponding to distributed tasks received by the node as a worker node. Optionally, in response to the target application's offline request, stopping accepting new tasks includes: in response to the target application's offline request, sending a offline notification to the server, causing the server to mark the node's target application as offline and to issue new distributed tasks corresponding to the target application to nodes that are not offline; and, if a first distributed task exists, sending a offline notification to the master node corresponding to the first distributed task, causing the master node to mark the node's target application as offline and to stop assigning subtasks of the distributed task corresponding to the target application to nodes that are offline. Optionally, the distributed task is a periodically executed distributed task; the server specifies a master node corresponding to each period, with different periods corresponding to the same or different master nodes; or, the master node corresponding to any period continues to use the master node of the previous period. The method further includes: in response to a target application's offline request, sending a master node switching notification to the server, the master node switching notification instructing the server to reassign a master node for the periodically executed distributed task. Optionally, after completing a pending subtask of the node in the first distributed task, determining that the node has completed processing of the first distributed task includes: clearing a task queue corresponding to the first distributed task, wherein the task queue contains assigned but unexecuted subtasks; and determining that the node has completed processing of the first distributed task after the executed subtasks are processed and the processing results are sent to the master node. Optionally, if a second distributed task exists, the method further includes: if it is detected that a target application of any worker node corresponding to the second distributed task is offline, and some of the subtasks assigned to the worker node have not returned processing results, assigning the subtasks to a node that is not offline. Optionally, after completing pending subtasks of the node in the first distributed task, determining that the node has completed processing the first distributed task includes: determining that the node has completed processing the first distributed task after all subtasks assigned to the node in the first distributed task have been processed.Optionally, the method further includes: obtaining a corresponding offline mode of the master node and / or working node configured by the user, the offline mode including a first offline mode and a second offline mode; wherein, the first offline mode of the working node is used to indicate that the subtask to be processed is an assigned subtask, and the second offline mode is used to indicate that the subtask to be processed is a running subtask; after the multiple subtasks included in the second distributed task are completed, determining that the node has completed processing the second distributed task includes: if the offline mode of the master node is the first offline mode, then after the multiple subtasks included in the second distributed task are completed, determining that the node has completed processing the second distributed task; the method further includes: if the offline mode of the master node is the second offline mode, then after the running subtask corresponding to the second distributed task is completed, determining that the node has completed processing the second distributed task. Optionally, if there is a second distributed task with the node as the master node, then after multiple subtasks included in the second distributed task are completed, determining that the node has completed processing of the second distributed task includes: if there is a second distributed task, then after obtaining the processing results of the subtasks sent by the working node corresponding to the second distributed task, updating the current completion number, wherein the current completion number is used to indicate the number of subtasks in the second distributed task that have returned processing results; after the current completion number reaches the number of multiple subtasks included in the second distributed task, determining that the node has completed processing of the second distributed task. Optionally, a target container is deployed on the node, and the target application runs in the target container; the offline request of the target application is determined by at least one of the following methods: when a Java hook function is triggered, determining that the offline request of the target application is obtained; wherein, the Java hook function is triggered when the target container is about to be shut down; when a container close event or a container stop event corresponding to the target container is monitored in a spring framework, determining that the offline request of the target application is obtained; the node provides an interface for processing the offline request of the target application, and when the interface is called, determining that the offline request of the target application is obtained.In a second aspect, embodiments of the present disclosure provide a method for offline application in a distributed system, the distributed system comprising multiple nodes for processing distributed tasks. The method is applied to any node in the distributed system and comprises: in response to a target application offline request, determining at least one distributed task corresponding to the target application in the node; determining whether the node has completed the at least one distributed task; and if all distributed tasks corresponding to the target application have been completed, exiting the target application to offline the target application. In a third aspect, embodiments of the present disclosure provide an application offline device for a distributed system, the distributed system comprising multiple nodes for processing distributed tasks; any distributed task is jointly completed by a master node and at least one worker node, the master node being configured to allocate multiple subtasks included in the distributed task, and the worker node being configured to process the allocated subtasks; the device, applied to any of the multiple nodes, comprising: a first determination module being configured to, in response to a target application offline request, determine at least one distributed task corresponding to the target application in the node; a second determination module being configured to, if a first distributed task for which the node is a worker node exists in the at least one distributed task corresponding to the target application, determine that the node has completed processing of the first distributed task after completing a subtask to be processed by the node in the first distributed task; a third determination module being configured to, if a second distributed task for which the node is a master node exists, determine that the node has completed processing of the second distributed task after all multiple subtasks included in the second distributed task have been completed; and an exit module being configured to exit the target application after all distributed tasks corresponding to the target application have been completed, thereby offlinening the target application. In a fourth aspect, embodiments of the present disclosure provide an application offline device for a distributed system, the distributed system comprising multiple nodes for processing distributed tasks. The device, applied to any node in the distributed system, comprises: a fourth determination module for determining, in response to a target application offline request, at least one distributed task corresponding to the target application in the node; a judgment module for determining whether the node has completed the at least one distributed task; and a processing module for exiting the target application after all distributed tasks corresponding to the target application have been completed, thereby offlinening the target application. In a fifth aspect, embodiments of the present disclosure provide an electronic device comprising: at least one processor; and a memory communicatively coupled to the at least one processor; the memory storing instructions executable by the at least one processor, wherein the instructions are executed by the at least one processor to cause the electronic device to perform the method described in any of the above aspects.In a sixth aspect, embodiments of the present disclosure provide a distributed system, comprising multiple nodes for processing distributed tasks; the nodes being configured to execute any of the methods described in any of the aforementioned aspects upon receiving a target application's offline request. In a seventh aspect, embodiments of the present disclosure provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement any of the methods described in any of the aforementioned aspects. In an eighth aspect, embodiments of the present disclosure provide a computer program product, comprising a computer program, which, when executed by a processor, implements any of the methods described in any of the aforementioned aspects. The distributed system application offline method, apparatus, device, system, and medium provided in embodiments of the present disclosure can, in response to a target application offline request, determine at least one distributed task corresponding to the target application on the node. If a first distributed task for which the node is a working node exists in the at least one distributed task corresponding to the target application, the node is determined to have completed processing the first distributed task after completing the pending subtasks of the node in the first distributed task. If a second distributed task for which the node is a master node exists, the node is determined to have completed processing the second distributed task after completing all of the multiple subtasks contained in the second distributed task. After all distributed tasks corresponding to the target application are completed, the target application is exited, thereby offline. Embodiments of the present disclosure can implement application offline operations in distributed scenarios, prevent distributed tasks from being interrupted during the offline process, and ensure the unimpeded operation of distributed tasks during application release and restart. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the specification, serve to explain the principles of the present disclosure.Figure 1 is a diagram illustrating the system architecture for processing distributed tasks according to an embodiment of the present disclosure; Figure 2 is a schematic flow diagram illustrating a method for offline applications in a distributed system according to an embodiment of the present disclosure; Figure 3 is a schematic flow diagram illustrating a method for offline applications in a master node according to an embodiment of the present disclosure; Figure 4 is a schematic diagram illustrating the principles of a method for offline applications in a distributed system according to an embodiment of the present disclosure; Figure 5 is a schematic flow diagram illustrating an offline operation according to an embodiment of the present disclosure; Figure 6 is a schematic diagram illustrating an interface for configuring an offline application method according to an embodiment of the present disclosure; Figure 7 is a schematic diagram illustrating an interface for configuring another offline application method according to an embodiment of the present disclosure; Figure 8 is a schematic flow diagram illustrating another method for offline applications in a distributed system according to an embodiment of the present disclosure; Figure 9 is a schematic diagram illustrating the structure of an application offline device in a distributed system according to an embodiment of the present disclosure; Figure 10 is a schematic diagram illustrating the structure of another application offline device in a distributed system according to an embodiment of the present disclosure; and Figure 11 is a schematic diagram illustrating the structure of an electronic device according to an embodiment of the present disclosure. The above figures illustrate specific embodiments of the present disclosure, which will be described in more detail below. These figures and descriptions are not intended to limit the scope of the present disclosure in any way, but rather to illustrate the concepts of the present disclosure to those skilled in the art by reference to specific embodiments. The exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. When the following description refers to the drawings, identical numerals in different drawings represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present disclosure. User information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display) referred to in this disclosure are all authorized by the user or fully authorized by all parties. The collection, use, and processing of such data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or deny. First, the terms used in this disclosure are explained: Distributed task: refers to a task that can be split into multiple subtasks and assigned to different nodes for parallel processing. Master node: also known as the Master node, an execution node responsible for task splitting and managing the processing status of subtasks. Worker node: A worker node is an execution node responsible for processing subtasks. Embodiments of the present disclosure can be applied to scenarios where distributed tasks are processed. Distributed tasks can include scheduled tasks and non-scheduled tasks. Scheduled tasks can be tasks that are executed at a predetermined time, such as periodic tasks.Figure 1 is a diagram of a system architecture for processing distributed tasks according to an embodiment of the present disclosure. As shown in Figure 1, the publishing and processing of distributed tasks can be implemented jointly by a server, a client, and multiple nodes. Each node can be deployed with at least one container, each of which runs an application. For example, the at least one container in node 1 can be container 1, container 2, and container 3. Container 1 runs application 1, container 2 runs application 2, and container 3 runs application 3. Applications can be used to process distributed tasks, and different applications can handle different distributed tasks. For any application, the user can configure the corresponding distributed task. Specifically, the user can set relevant information about the distributed task, such as the execution time, through the client. The server can issue the corresponding distributed task to a master node at the corresponding execution time. The master node can be any of the multiple nodes. The master node can split the distributed task into multiple subtasks and distribute them. Optionally, the distribution scope can include the master node and worker nodes, meaning that the master node and each worker node may be assigned at least one subtask. Optionally, each node can be configured with a task queue containing at least one assigned subtask. Nodes can use the task queue to sequentially process the at least one subtask. When a new application version is needed, users can choose to take the application offline on at least some nodes, deploy the new version, and restart the application after the shutdown. This allows distributed tasks to be processed using the new version. Some technologies provide a stop method for applications. When an application needs to be taken offline, the corresponding stop method can be called, and the application can be taken offline after the tasks in the task queue are completed. However, applying this method to a distributed system may interrupt running distributed tasks, leading to data incompleteness or other issues. For example, in a master node, calling the stop method will cause the application to be taken offline after the master node completes the tasks in the task queue. At this point, the tasks of the worker nodes may not have yet been completed, resulting in the interruption of distributed tasks.In light of this, embodiments of the present disclosure provide a method for offline applications in a distributed system. This method can be applied separately to master nodes and worker nodes. Specifically, when an application on a node is offline, the distributed task corresponding to the application to be offlined is determined on the node. If the node is the master node for the distributed task, the node waits until the subtasks in its task queue and the subtasks assigned to the worker nodes are completed. The node then determines that the distributed task is complete and exits the corresponding application. If the node is a worker node, the node completes its own subtasks and exits the corresponding application after completing the distributed task. This method enables offline application operations in distributed scenarios, prevents distributed tasks from being interrupted during the offline process, and ensures that distributed tasks continue to run smoothly during application release and restart. Some embodiments of the present disclosure are described in detail below, in conjunction with the accompanying drawings. The following embodiments and features may be combined unless there is a conflict between the embodiments. The sequence of steps in the following method embodiments is provided for illustrative purposes only and is not a strict limitation. Figure 2 is a flow chart of an application offline method for a distributed system provided in an embodiment of the present disclosure. The distributed system includes multiple nodes for processing distributed tasks. Each distributed task is jointly completed by a master node and at least one worker node. The master node is responsible for assigning multiple subtasks contained in the distributed task, and the worker node is responsible for processing the assigned subtasks. The method, applied to any of the multiple nodes, includes: Step 201: In response to a target application's offline request, determining at least one distributed task corresponding to the target application in the node. Optionally, the target application's offline request can be triggered by a user or automatically by a server. The offline request can be triggered when a new version of the target application is required or for other reasons. Optionally, if the target application is deployed on multiple nodes, the offline operation can be performed in batches for the multiple nodes. For example, in each batch, only applications on some nodes are offline and updated, while applications on other nodes can continue to process tasks normally. For each node, upon receiving a target application's offline request, the currently executing distributed task corresponding to the target application can be determined. Optionally, the node can have an application process corresponding to the target application, allowing the application process to handle the corresponding distributed task. Upon receiving a request to log off the target application, the application process can be used to determine whether a corresponding distributed task currently exists. Nodes can play two roles in distributed tasks: master node or worker node.Accordingly, the application process in the master node can be used to split, allocate, and process subtasks of a distributed task, while the application process in the worker node can be used to process subtasks within a distributed task. For a worker node, the at least one distributed task corresponding to the target application in the node determined in this step may specifically refer to the distributed task to which the subtask corresponding to the target application in the node belongs. Optionally, for any distributed task, the master node can be designated by the server, and the worker nodes can be designated by either the server or the master node. There is no limit on the number of worker nodes. The multiple subtasks contained in any distributed task can be distributed among the master node and the worker nodes, or only among the worker nodes. In an optional implementation, the master node can split the distributed task into multiple subtasks and assign the subtasks to multiple worker nodes, with each worker node processing the assigned subtask. In another optional implementation, the master node may split the distributed task into multiple subtasks, assign at least one of the subtasks to itself for processing, and assign the remaining subtasks to at least one worker node. The master node and the worker node each process their assigned subtasks. Step 202: If, in at least one distributed task corresponding to the target application, there is a first distributed task for which the node serves as a worker node, after completing the pending subtasks of the node in the first distributed task, determine that the node has completed processing the first distributed task. Specifically, among the determined distributed tasks, the distributed task for which the node serves as a worker node is referred to as the first distributed task. After the node completes the pending subtasks, it is determined that the node has completed processing the first distributed task. Optionally, the pending subtasks may be assigned subtasks or already executed subtasks. Assigned subtasks include assigned but not executed subtasks and assigned and executed subtasks. Step 203: If a second distributed task exists with the node as the master node, after all subtasks included in the second distributed task are completed, determine that the node has completed processing the second distributed task. Specifically, among the determined distributed tasks, the distributed task with the node as the master node is referred to as the second distributed task. The second distributed task includes multiple subtasks. After all subtasks are completed, that is, after processing results corresponding to each of the multiple subtasks are obtained, determine that the node has completed processing the second distributed task. Step 204: After all distributed tasks corresponding to the target application are completed, exit the target application to achieve offline of the target application.Optionally, when receiving a target application's offline request, the node may have one or more distributed tasks currently executing. These distributed tasks can be scheduled or non-scheduled. When there are multiple distributed tasks, the node can serve as the master node for these multiple distributed tasks, or as a worker node for these multiple distributed tasks, or as the master node for some of these tasks and a worker node for the remaining tasks. For any distributed task, the corresponding steps described above can be performed based on the node's role in the distributed task. After all the distributed tasks are completed, the target application can be exited, that is, the corresponding application process can be closed. In actual applications, a node typically has only one distributed task corresponding to the target application. Based on the node's role in the distributed task, the node can perform corresponding processing. After determining that it has completed processing the distributed task, the target application can be exited. FIG3 is a flow diagram of a method for offline application in a master node provided by an embodiment of the present disclosure. As shown in FIG3 , a distributed system includes three nodes, namely, node 1, node 2, and node 3. All three nodes include a target application. Node 1 is the master node, and nodes 2 and 3 are working nodes. Together, they complete a distributed task. As can be seen from the first phase, the distributed task includes subtasks 1-a, 1-b, 1-c, and 1-d. Subtasks 1-a and 1-b are assigned to node 1, subtask 1-c is assigned to node 2, and subtask 1-d is assigned to node 3. After node 1 receives a request to offline an application, it enters the second phase. During the offline process, it waits for the execution of the four subtasks. After all four subtasks are completed, it enters the third phase. The target application in node 1 exits the process. Nodes 2 and 3 can receive and process subtasks distributed by other master nodes, such as subtasks 2-e and 2-f.In summary, the distributed system application offline method provided in this embodiment can, in response to a target application offline request, determine at least one distributed task corresponding to the target application on the node. If a first distributed task exists for which the node is a working node, then after completing the pending subtasks of the node in the first distributed task, the node is determined to have completed processing of the first distributed task. If a second distributed task exists for which the node is a master node, then after completing all of the multiple subtasks included in the second distributed task, the node is determined to have completed processing of the second distributed task. After all of the distributed tasks corresponding to the target application are completed, the target application is exited. This allows application offline operations in distributed scenarios, avoids interruption of distributed tasks during the offline process, and ensures intact operation of distributed tasks during application release and restart. Optionally, in response to the target application offline request, the node can also stop accepting new tasks. These tasks include distributed tasks issued by the server and received by the node as a master node, and / or subtasks corresponding to distributed tasks received by the node as a working node. The term "new task" refers to a new task corresponding to the target application. A new task can be triggered by a user or initiated by a scheduled task. For example, a periodically executed scheduled task can automatically trigger a new distributed task upon entering a new cycle. For any node, in response to a target application's offline request, stopping accepting new tasks can include the following three implementation options: In one optional implementation, the target application's distributed tasks correspond to fixed master nodes and worker nodes. For example, among the multiple nodes in a cluster, some nodes are fixed as master nodes, while the remaining nodes are fixed as worker nodes. Thus, if the node is fixed as the master node, upon receiving a target application's offline request, it can stop acting as the master node to receive distributed tasks issued by the server. In another optional implementation, if the node is fixed as the worker node for the target application's distributed tasks, upon receiving a target application's offline request, it can stop acting as a worker node to receive subtasks assigned by the corresponding master node. In another optional implementation, the master node and worker nodes corresponding to the target application's distributed tasks are not fixed. Each time a distributed task is triggered, the server selects a master node from multiple nodes. Upon receiving a target application's offline request, any node may subsequently serve as the master node to receive distributed tasks or as a worker node to receive subtasks. In this case, the node may stop receiving both distributed tasks and subtasks simultaneously.Optionally, stopping accepting new tasks in response to a target application's offline request may specifically include: sending a offline notification to the server in response to the target application's offline request, causing the server to mark the target application of the node as offline and dispatch new distributed tasks corresponding to the target application to nodes that are not offline; and, if a first distributed task exists, sending a offline notification to the master node corresponding to the first distributed task, causing the master node to mark the target application of the node as offline and stop dispatching subtasks of the distributed task corresponding to the target application to the offline node. Specifically, after receiving the target application's offline request, any node may send a offline notification for the target application to the server. Upon receiving the offline notification, the server marks the target application on the node as offline. When a new distributed task is triggered, the server will not dispatch the new distributed task to the node, but will dispatch it to other nodes that are not offline. Furthermore, if a first distributed task exists on the node, meaning that the node is currently processing tasks as a working node, a logoff notification is sent to the master node corresponding to the first distributed task. The master node then marks the target application on the node as offline, thereby preventing the master node from continuing to assign subtasks corresponding to the target application to the offline node. In this way, after receiving a logoff request from the target application, a node can simultaneously send a logoff notification to the server and the corresponding master node. This prevents the node from remaining offline due to receiving new distributed tasks and subtasks during the logoff process, thereby improving logoff efficiency. In addition to the aforementioned method of stopping the acceptance of new tasks by sending a logoff notification, other methods can also be used. For example, when a user initiates a logoff request for a node's target application, the logoff request can be synchronized to the server and other nodes, causing the server and other nodes to proactively stop issuing new tasks to the node to be logged off. Optionally, the distributed task described above can be a periodically executed distributed task, i.e., executed once every preset period. Periodically executed distributed tasks may include second-level distributed tasks and non-second-level distributed tasks. A second-level distributed task may refer to a distributed task with a period of seconds, for example, one that is executed every second. Optionally, for non-second-level distributed tasks, the server may specify a master node for each period. Different periods may correspond to the same or different master nodes. That is, the master node specified for each period may be the same as or different from the master node specified for the previous period.For distributed tasks executed at the second level, due to the relatively frequent task triggering, the master node corresponding to any given cycle can continue to use the master node from the previous cycle. Specifically, the server only assigns a master node to a distributed task executed at the second level the first time it is triggered. Subsequent distributed tasks can directly use the master node from the previous cycle. For any node that serves as the master node for a periodically executed distributed task, and that distributed task continues to use the master node from the previous cycle in each cycle, the node can, in response to a target application's offline request, send a master node switch notification to the server. This master node switch notification instructs the server to reassign the master node for the distributed task executed during that cycle. By notifying the server of the reassigned master node and allowing the newly assigned master node to handle distributed tasks in subsequent cycles, this prevents the situation where the current cycle uses the master node from the previous cycle, even though the master node from the previous cycle is offline. This effectively ensures the normal dispatch and processing of distributed tasks. Optionally, the master node switch notification and the aforementioned offline notification can be sent simultaneously or separately. Alternatively, after receiving a target application's offline request, a node can send a heartbeat offline notification to the server. This heartbeat offline notification can serve as either a master node switch notification, instructing the server to reassign a master node for periodically executed distributed tasks, or a offline notification, instructing the server to stop assigning new distributed tasks to the node. This solution allows the application to exit after all distributed tasks have been processed, achieving a graceful offline on both the master and worker nodes. Optionally, the disclosed embodiments also support the following two graceful offline modes: complete graceful offline: all assigned distributed tasks / subtasks are executed to completion; and partial graceful offline: all running subtasks are executed to completion, while assigned, unrunning subtasks are ignored. Furthermore, the disclosed embodiments support a variety of access configuration scenarios, enabling the target application's offline request to be triggered in a variety of ways. This is described in detail below. Figure 4 is a schematic diagram illustrating the principles of a distributed system application offline method provided by the disclosed embodiments.As shown in Figure 4, this embodiment supports multiple access configuration scenarios. Specifically, the target application's offline request can be determined using at least one of the following methods: when a Java hook function is triggered, determining that the target application's offline request has been received; wherein the Java hook function is triggered when the target container is about to be shut down; wherein "about to be shut down" can mean when it is determined to be shut down but has not yet been shut down; when a container close event or container stop event corresponding to the target container is monitored in the spring framework, determining that the target application's offline request has been received; the node provides an interface for processing the target application's offline request, and when the interface is called, determining that the target application's offline request has been received. Specifically, each node can be deployed with at least one container. The container in which the target application is deployed is called the target container, and the target application runs in the target container. The following examples illustrate different access configuration methods supported by the disclosed solution. In one example, when a user shuts down a target container in a node, a Java ShutdownHook (Java hook function) is triggered when the target container is about to shut down. When the Java ShutdownHook is triggered, it can be determined that the target application's offline request has been received. In another example, Spring provides an event monitoring mechanism. When a container needs to be stopped or shut down, a ContextStoppedEvent (container stop event) and a ContextC I osedEvent (container shutdown event) are triggered. When these ContextStoppedEvent and ContextC I osedEvent are triggered, it can be determined that the target application's offline request has been received. In yet another example, the offline processing flow provided in the aforementioned embodiments can be encapsulated as a service or interface for processing offline requests from the target application and made available to the public. When the interface is called, it can be determined that the target application's offline request has been received. Exemplarily, the interface may be in the form of an HTTP (HyperText Transfer Protocol) service interface or an SDK (Software Development Kit) interface, etc., to support other publishing platforms to customize the orchestration of application offline.For example, an HTTP logout interface can be provided to support triggering the HTTP logout interface in the preStop command (the instruction executed before a container stops) of Kubernetes (an open source platform for managing containers). Alternatively, the HTTP logout interface can be integrated into the logout procedure on the EDA (Enterprise Distributed Application Service) platform. This approach supports application logout requests triggered in various scenarios, encapsulates the application logout processing logic, and supports the integration of related logout processes across various platforms, meeting the needs of different scenarios and improving the user experience. Figure 5 is a schematic diagram of a logout operation process provided by an embodiment of the present disclosure. As shown in Figures 4 and 5, for any node, after receiving a logout request from the target application, the logout operation can be implemented through the following steps 501 to 503. Step 501: Entering the logout process, the node proactively notifies the server that the current node is offline, marking the current node as no longer accepting new distributed tasks. The node offline mentioned in this embodiment specifically refers to the target application in the node going offline. From the perspective of the target application, if the target application in a node goes offline, it means that the node is unavailable when the cluster processes the corresponding distributed task. Therefore, for ease of description, the node can be simply referred to as being offline. Optionally, a node can notify the server of its offline status in various ways. For example, the node can notify the server of its offline status via a heartbeat notification. Upon receiving the heartbeat offline notification, the server can mark the node as offline and stop assigning new distributed tasks to the node. Step 502: Processing tasks for the working node. Optionally, if a first distributed task exists, i.e., a distributed task for which the node is a working node, a offline notification can be sent to the corresponding master node to stop accepting new subtasks. Furthermore, after processing the relevant subtasks, it can be determined that the node has completed processing the first distributed task. If the node has no other distributed tasks, the corresponding application process can be exited. Optionally, in a completely graceful offline mode, after all assigned subtasks are processed, it is determined that the node completes processing of the first distributed task.For example, Node 1 is acting as a working node to process a first distributed task. The first distributed task contains multiple subtasks, namely Subtask 1-a, Subtask 1-b, and Subtask 1-c. The master node corresponding to the first distributed task assigns Subtask 1-a and Subtask 1-b to Node 1. After Node 1 completes Subtask 1-a and Subtask 1-b, Node 1 is determined to have completed processing the first distributed task. This ensures that the node has completed processing the first distributed task after all assigned subtasks have been processed. This prevents the application from going offline or no longer processing the first distributed task before the assigned subtasks have been processed, thereby ensuring the smooth execution of the assigned subtasks. Optionally, in partial graceful offline mode, the task queue corresponding to the first distributed task can be cleared. The task queue contains assigned but unrun subtasks. The node is determined to have completed processing the first distributed task after all run subtasks have been processed and the results have been sent to the master node. Specifically, the first distributed task in a working node corresponds to two types of subtasks: the first type of subtasks are assigned but not yet executed, and the second type are assigned and already running. The first type of subtasks exists in the task queue corresponding to the first distributed task on the node. In a partial graceful offline mode, the working node can clear the task queue corresponding to the first distributed task, meaning that the first type of subtasks are no longer executed. The node only needs to complete processing the second type of subtasks, i.e., the already running subtasks, and send the processing results to the corresponding master node to confirm that the node has completed processing the first distributed task. For example, node 1, as a working node, processes the first distributed task. The first distributed task contains multiple subtasks, namely subtask 1-a, subtask 1-b, and subtask 1-c. The master node corresponding to the first distributed task assigns subtasks 1-a and 1-b to node 1. When node 1 receives the offline notification, subtask 1-a has already started running, while subtask 1-b has not yet started running and is in the task queue. At this point, the task queue can be cleared, and subtask 1-b can no longer be executed. After subtask 1-a is completed, it can be determined that node 1 has completed processing the first distributed task. This way, after the running subtasks are processed, the node's completion of processing the first distributed task is confirmed, allowing the node to be quickly offline while ensuring that the running subtasks can be executed normally. In actual applications, the specific offline operation can be implemented in a variety of ways.Optionally, for each distributed task in a node, the corresponding instance can execute the relevant task processing. During the offline process, when the distributed task is determined to be completed, the corresponding instance can be exited. Optionally, task processing can also be implemented using an execution thread pool, which can be used to manage and execute task queues. For example, after receiving a offline request, a worker node can shut down the execution thread pool. The following two modes are supported: Fully graceful offline: Calling the execution thread pool's Shutdown method waits for all subtasks in the task queue to complete before shutting down the thread pool; Partially graceful offline: Clearing the execution thread pool's task queue, calling the Shutdown method, and waiting for all running subtasks to complete before shutting down the thread pool. Step 503: Processing tasks for the master node. Optionally, if a node has a second distributed task (i.e., a distributed task for which the node serves as the master node), the node can determine that it has completed processing the second distributed task after all of the multiple subtasks included in the second distributed task have completed. If the node has no other distributed tasks, the corresponding application process can be exited. Specifically, the process can wait for the worker node to return the processing results of the subtasks, and then exit the application process after confirming that the processing results of the multiple subtasks have been obtained. Optionally, to better support the graceful shutdown of some worker nodes, the master node can further perform the following operation: if it is detected that the target application of any worker node corresponding to the second distributed task is offline, and some of the subtasks assigned to the worker node have not returned processing results, the master node can assign these subtasks to nodes that are not offline. Specifically, when a second distributed task exists on a node, the status of the target application in the worker node corresponding to the second distributed task can be checked at preset intervals. If the target application of any worker node is offline and not all subtasks assigned to that worker node have returned processing results, the subtasks that have not returned processing results are reassigned to a node that is not offline. For example, the second distributed task includes subtasks 2-a, 2-b, and 2-c. The master node assigns subtasks 1-a and 1-b to worker node 1 and subtask 2-c to worker node 2. The master node can check the status of worker nodes 1 and 2 at preset intervals. If it detects that worker node 1 is offline and has only returned the processing result of subtask 2-a, subtask 2-b can be assigned to another node that is not offline for processing.In this way, if a worker node is detected to be offline and any of the subtasks assigned to that worker node have not yet returned a processing result, the subtasks that have not yet returned a processing result are assigned to a node that is not offline. This ensures that all subtasks are processed completely and the master node can obtain the processing results of all subtasks, ensuring the complete execution of the distributed task. Optionally, upon receiving a target application's offline request, the master node can enter a blocking wait mode, waiting for each worker node to return the corresponding processing results. Upon determining, based on the returned processing results, that the processing of the second distributed task has been completed, the master node exits the blocking wait mode and completes the offline of the target application. There are various implementation options for determining the completion of the processing of the second distributed task based on the returned processing results. In one alternative implementation, the number of processing results returned by each worker node can be counted separately. When each worker node returns a corresponding number of processing results, the completion of the processing of the second distributed task is determined. In this implementation, when the application is in partial graceful shutdown mode, it may be necessary to reallocate subtasks on certain nodes and update the number of subtasks on the nodes. In another optional implementation, a parameter can be set to indicate the number of all currently returned processing results, which is used to determine whether processing of the second distributed task has been completed. Specifically, if a second distributed task exists with the node as the master node, determining that the node has completed processing of the second distributed task after all subtasks within the second distributed task have been completed includes: if the second distributed task exists, after obtaining the processing results of the subtasks sent by the worker nodes corresponding to the second distributed task, updating the current completion count, where the current completion count indicates the number of subtasks within the second distributed task that have returned processing results; and determining that the node has completed processing of the second distributed task after the current completion count reaches the number of subtasks within the second distributed task. In this way, using the current completion count parameter to track the processing of the second distributed task can effectively improve processing efficiency. Combined with the blocking wait mode, the graceful shutdown time can be precisely controlled, improving the shutdown efficiency of the target application. Optionally, the master node can be shut down in two modes: fully graceful and partially graceful. In fully graceful shutdown mode, the master node can complete all assigned distributed tasks before exiting the application process. Specifically, after receiving a shutdown notification, undistributed subtasks can continue to be distributed, and the master node waits until all subtasks are completed, thus completing all assigned distributed tasks.In partial graceful shutdown mode, the master node can exit the application process after completing all running subtasks. Optionally, after receiving a shutdown request, the master node can ignore processing for distributed tasks that haven't yet started distributing subtasks, and can stop distributing subtasks for distributed tasks that have already started. Furthermore, the master node can notify corresponding worker nodes that they only need to complete currently running subtasks, ignoring assigned, unrunning subtasks in the task queue. This expedites the master node's access to subtask processing results and enables the fastest possible shutdown. In partial graceful shutdown mode, some subtasks may not be completed, but every running subtask is guaranteed to be fully processed, avoiding data errors and other issues. Typically, completed subtasks result in a state change for the processed object. For example, a subtask used to process an order is incomplete before the subtask is completed. Upon completion, the corresponding order is moved to the completed state. In partial graceful offline mode, although some subtasks are not processed, the corresponding processing objects remain in an uncompleted state. Therefore, when a distributed task is subsequently initiated, these processing objects can still be processed, preventing any missing processing objects. Furthermore, partial graceful offline mode is user-configurable, allowing users to decide whether to enable it based on actual needs. In this embodiment, the aforementioned steps 502 and 503 can be used to perform offline operations based on role type. For any node, when receiving a offline request from the target application, it typically has only one role: if it is a worker node, step 502 is executed to complete the offline process. If it is a master node, step 503 is executed to complete the offline process. Through the aforementioned steps 501 to 503, both fully and partially graceful offline can be achieved in distributed task scheduling scenarios. Furthermore, the offline process is designed to utilize a blocking wait mode, rather than a timed polling or fixed-time wait mode, allowing for precise control of the graceful offline time. Optionally, in the distributed system application offline method provided in the present disclosure, the offline method can be user-configured. The specific method is as follows: Obtaining the user-configured offline methods corresponding to the master node and / or worker node, where the offline methods include a first offline method and a second offline method. Specifically, the user can configure only the offline method for the target application in the master node, or only the offline method for the target application in the worker node, or the user can configure the corresponding offline methods for both the master node and the target node. Default settings may be used for any portions not configured by the user.The first offline mode for a worker node indicates that the worker node has completed processing the first distributed task after all assigned subtasks have been processed, corresponding to the aforementioned fully graceful offline of the worker node. The second offline mode for a worker node indicates that the worker node has completed processing the first distributed task after all running subtasks have been processed, corresponding to the aforementioned partially graceful offline of the worker node. The first and second offline modes for a master node also correspond to the aforementioned fully graceful offline and partially graceful offline modes. In the case of a fully graceful offline, the node may exit after processing all second distributed tasks. That is, determining that the node has completed processing the second distributed task after all subtasks within the second distributed task have been completed in step 203 may include: If the master node's offline mode is the first offline mode, determining that the node has completed processing the second distributed task after all subtasks within the second distributed task have been completed. The method further includes: if the master node's offline method is the second offline method, then after the running subtasks corresponding to the second distributed task are completed, determining that the node has completed processing of the second distributed task, and ignoring the processing of the unrunning subtasks. Specifically, the user can configure the offline method corresponding to the target application on the user terminal. Figure 6 is a schematic diagram of an application offline method configuration interface provided in an embodiment of the present disclosure. As shown in Figure 6, three applications are included, namely Application 1, Application 2, and Application 3. For each application, there is a corresponding input box to the right of the application. The user clicks the drop-down menu in the input box and selects the offline method corresponding to the application. After selecting, clicks the confirmation button. The user terminal sends the offline methods selected by the user for Application 1, Application 2, and Application 3 to the nodes corresponding to each application. When configuring the corresponding offline method for a target application on the user side, users can not only use the above method to uniformly configure the same offline method for all nodes containing the target application, but also configure the offline method for each node containing the target application individually, configuring some nodes with the first offline method and others with the second offline method. After the configuration is complete, click the Confirm button to send the configured offline method to the corresponding nodes. Figure 7 shows another schematic diagram of the application offline method configuration interface provided in an embodiment of the present disclosure. As shown in Figure 7, there are four nodes containing application 1: node 1, node 2, node 3, and node 4. The user selects the first offline method for nodes 1 and 3, and the second offline method for nodes 2 and 4. Click the Confirm button to configure different offline methods for different nodes.In this way, users can configure the same offline policy for the same application in different nodes, or they can configure different offline policies for the same application in different nodes to meet the needs of different applications on different nodes and improve flexibility. Alternatively, the offline method can be configured through other methods. For example, users can set the offline method in a configuration file and complete the offline method configuration by loading the configuration file. Figure 8 is a flow chart of another distributed system application offline method provided by an embodiment of the present disclosure. The distributed system includes multiple nodes for processing distributed tasks; the method is applicable to any node in the distributed system. As shown in Figure 8, the method includes: Step 801: In response to a target application offline request, determine at least one distributed task corresponding to the target application in the node. The specific implementation principles and process of Step 801 can be found in the previous embodiment and will not be repeated here. Step 802: Determine whether the node has completed the at least one distributed task. Step 803: If all distributed tasks corresponding to the target application have been completed, exit the target application to complete the offline process. Optionally, determining whether the node has completed the at least one distributed task may include: if, among the at least one distributed task corresponding to the target application, there is a first distributed task for which the node is a working node, determining that the node has completed processing of the first distributed task after completing a subtask to be processed by the node in the first distributed task; and / or if there is a second distributed task for which the node is a master node, determining that the node has completed processing of the second distributed task after completing multiple subtasks included in the second distributed task. The meanings of the first distributed task and the second distributed task and their specific processing methods may refer to the aforementioned embodiments. In an optional implementation, a node may have a fixed role when processing distributed tasks corresponding to the target application. For example, a node may be fixed as a working node, and the at least one distributed task it processes is the first distributed task. Upon receiving a logoff request corresponding to the target application, the node may determine that all distributed tasks corresponding to the target application have been completed after completing the first distributed task, and then may exit the target application. In another optional implementation, a certain node may be fixed as the master node when processing distributed tasks corresponding to the target application. In this case, at least one distributed task processed may be a second distributed task. When a logoff request corresponding to the target application is obtained, after completing the second distributed task, it can be determined that all distributed tasks corresponding to the target application are completed, and then the target application can be exited.In another optional implementation, the roles of nodes may not be fixed. When a target application's offline request is received, the at least one distributed task processed may include a first distributed task and a second distributed task. After both the first distributed task and the second distributed task are processed, the target application may be exited. The distributed system application offline method provided in this embodiment can, in response to the target application's offline request, determine at least one distributed task corresponding to the target application in the node, determine whether the node has completed the at least one distributed task, and if all distributed tasks corresponding to the target application are completed, exit the target application. This allows for application offline operations in distributed scenarios, reduces the risk of distributed tasks being interrupted during the offline process, facilitates lossless operation of distributed tasks during application release and restart, improves task processing efficiency, and enhances user experience. The present disclosure also provides a distributed system comprising multiple nodes for processing distributed tasks; the nodes are configured to execute the method described in any of the above embodiments upon receiving a target application's offline request. The specific implementation principles and beneficial effects of the distributed system provided in this embodiment can be found in the aforementioned embodiments and will not be further elaborated here. Corresponding to the above-mentioned distributed system application offline method, an embodiment of the present disclosure further provides a distributed system application offline device. FIG9 is a structural diagram of a distributed system application offline device provided by an embodiment of the present disclosure. The distributed system includes multiple nodes for processing distributed tasks; any distributed task is jointly completed by a master node and at least one worker node, the master node is configured to allocate multiple subtasks included in the distributed task, and the worker node is configured to process the allocated subtasks; the apparatus, applied to any of the multiple nodes, includes: a first determination module 901, configured to, in response to a target application's offline request, determine at least one distributed task corresponding to the target application in the node; a second determination module 902, configured to, if a first distributed task for which the node is a worker node exists in the at least one distributed task corresponding to the target application, determine that the node has completed processing of the first distributed task after completing a subtask to be processed by the node in the first distributed task; a third determination module 903, configured to, if a second distributed task for which the node is a master node exists, determine that the node has completed processing of the second distributed task after all multiple subtasks included in the second distributed task have been completed; and an exit module 904, configured to exit the target application after all distributed tasks corresponding to the target application have been completed, thereby offlinening the target application.Optionally, the first determination module 901 is further configured to: in response to a target application's offline request, stop accepting new tasks; wherein the tasks include distributed tasks issued by the server and received by the node as a master node, and / or subtasks corresponding to distributed tasks received by the node as a worker node. Optionally, when stopping accepting new tasks in response to the target application's offline request, the first determination module 901 is specifically configured to: in response to the target application's offline request, send a offline notification to the server, causing the server to mark the node's target application as offline and to issue new distributed tasks corresponding to the target application to nodes that are not offline; and, if a first distributed task exists, send a offline notification to the master node corresponding to the first distributed task, causing the master node to mark the node's target application as offline and to stop assigning subtasks of the distributed task corresponding to the target application to nodes that are offline. Optionally, the distributed task is a periodically executed distributed task; the server specifies a master node corresponding to each period, with different periods corresponding to the same or different master nodes; or, the master node corresponding to any period continues to use the master node of the previous period. The first determination module 901 is further configured to: in response to a target application's offline request, send a master node switching notification to the server, wherein the master node switching notification instructs the server to reassign a master node for the periodically executed distributed task. Optionally, the second determination module 902, upon completing a pending subtask of the node in the first distributed task and determining that the node has completed processing of the first distributed task, is specifically configured to: clear a task queue corresponding to the first distributed task, wherein the task queue contains assigned but unexecuted subtasks; and after the executed subtasks are processed and the processing results are sent to the master node, determine that the node has completed processing of the first distributed task. Optionally, if a second distributed task exists, the third determining module 903 is further configured to: if it is detected that the target application of any work node corresponding to the second distributed task is offline, and some of the subtasks assigned to the work node have not returned processing results, assign these subtasks to a node that is not offline. Optionally, the second determining module 902, when determining that the node has completed processing of the first distributed task after completing the pending subtasks of the node in the first distributed task, is specifically configured to: determine that the node has completed processing of the first distributed task after all subtasks assigned to the node in the first distributed task have been processed.Optionally, the first determination module 901 is further used to: obtain a user-configured offline mode corresponding to the master node and / or working node, the offline mode including a first offline mode and a second offline mode; wherein the first offline mode of the working node is used to indicate that the subtask to be processed is an assigned subtask, and the second offline mode is used to indicate that the subtask to be processed is a running subtask; the third determination module 903 is specifically used to: if the offline mode of the master node is the first offline mode, then after the multiple subtasks included in the second distributed task are completed, determine that the node has completed processing the second distributed task; the third determination module 903 is further used to: if the offline mode of the master node is the second offline mode, then after the running subtasks corresponding to the second distributed task are completed, determine that the node has completed processing the second distributed task. Optionally, the third determination module 903 is specifically configured to: if a second distributed task exists, update the current completion count after obtaining the processing results of the subtasks sent by the working node corresponding to the second distributed task, wherein the current completion count indicates the number of subtasks in the second distributed task that have returned processing results; and determine that the node has completed processing of the second distributed task after the current completion count reaches the number of subtasks included in the second distributed task. Optionally, the node is deployed with a target container, and the target application runs in the target container; the target application's offline request is determined in at least one of the following ways: determining that the target application's offline request has been obtained when a Java hook function is triggered; wherein the Java hook function is triggered when the target container is about to shut down; determining that the target application's offline request has been obtained when a container close event or a container stop event corresponding to the target container is monitored in the spring framework; and the node provides an interface for processing the target application's offline request, and when the interface is called, determining that the target application's offline request has been obtained. The specific implementation principle and beneficial effects of the application offline device of the distributed system provided by the embodiment of the present disclosure can be found in the above embodiments and will not be repeated here. FIG10 is a structural diagram of another application offline device of the distributed system provided by the embodiment of the present disclosure.The distributed system includes multiple nodes for processing distributed tasks; the apparatus is applied to any node in the distributed system and includes: a fourth determination module 1001 for determining, in response to a target application's offline request, at least one distributed task corresponding to the target application in the node; a determination module 1002 for determining whether the node has completed the at least one distributed task; and a processing module 1003 for exiting the target application after all distributed tasks corresponding to the target application have been completed, thereby offline the target application. The present disclosure provides another distributed system application offline apparatus; the specific implementation principles and beneficial effects can be found in the aforementioned embodiments and are not further described here. Figure 11 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure. As shown in Figure 11, the electronic device in this embodiment may include: at least one processor 1101; and a memory 1102 communicatively connected to the at least one processor; wherein the memory 1102 stores instructions executable by the at least one processor 1101, and the instructions are executed by the at least one processor 1101 to cause the electronic device to perform a method as described in any of the aforementioned embodiments. Optionally, memory 1102 can be independent or integrated with processor 1101. The implementation principles and technical effects of the electronic device provided in this embodiment can be found in the aforementioned embodiments and will not be elaborated upon here. The present disclosure also provides a computer-readable storage medium storing computer-executable instructions. When a processor executes the computer-executable instructions, the method described in any of the aforementioned embodiments is implemented. The present disclosure also provides a computer program product comprising a computer program. When executed by a processor, the computer program implements the method described in any of the aforementioned embodiments. In the several embodiments provided in this disclosure, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the module division is merely a logical functional division. In actual implementation, other division methods may be used. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. The integrated modules implemented in the form of software functional modules can be stored in a computer-readable storage medium. The above software function module is stored in a storage medium, and includes a number of instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor to execute some steps of the method described in various embodiments of the present disclosure.It should be understood that the processor described above may be a processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the application may be directly executed by a hardware processor or by a combination of hardware and software modules within the processor. The memory may include high-speed random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device, or may be a USB flash drive, a mobile hard drive, a read-only memory, a magnetic disk, or an optical disk. The above-mentioned storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer. An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and the storage medium may reside in an application specific integrated circuit (ASIC).Of course, the processor and storage medium may also exist as discrete components within an electronic device or a host control device. It should be noted that, as used herein, the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising a..." does not preclude the presence of other identical elements within the process, method, article, or apparatus comprising such an element. The serial numbers of the embodiments disclosed above are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments. Through the above description of the embodiments, those skilled in the art will clearly understand that the methods of the embodiments described above can be implemented using software plus a necessary general-purpose hardware platform. Hardware can also be used, but in many cases the former is a more preferred implementation. Based on this understanding, the technical solution of this disclosure, or the portion that contributes to the prior art, can be embodied in the form of a software product. This computer software product, stored in a storage medium (e.g., ROM / RAM, magnetic disk, or optical disk), includes instructions for enabling a terminal device (such as a mobile phone, computer, server, air conditioner, or network device) to execute the methods described in the various embodiments of this disclosure. The above are merely preferred embodiments of this disclosure and are not intended to limit the scope of the patent. Any equivalent structures or equivalent processes derived from the disclosure and accompanying drawings, or any direct or indirect application in other related technical fields, are similarly encompassed within the scope of patent protection of this disclosure.

Claims

Claims 1. A method for taking an application offline in a distributed system, wherein, The distributed system includes multiple nodes for processing distributed tasks; any distributed task is jointly completed by a master node and at least one worker node. The master node is used to allocate multiple subtasks included in the distributed task, and the worker node is used to process the allocated subtasks. The method is applied to any one of the multiple nodes and includes: in response to a logout request of a target application, determining at least one distributed task corresponding to the target application in the node; in at least one distributed task corresponding to the target application, if there is a first distributed task with the node as a worker node, after completing the subtasks to be processed by the node in the first distributed task, determining that the node has completed the processing of the first distributed task; if there is a second distributed task with the node as a master node, after all the multiple subtasks included in the second distributed task are completed, determining that the node has completed the processing of the second distributed task; after all the distributed tasks corresponding to the target application are completed, logging out the target application to implement the logout of the target application.

2. The method according to claim 1, wherein, The method further includes: in response to a logout request of a target application, stopping receiving new tasks; where the tasks include distributed tasks received by the node as a master node and issued by the server, and / or subtasks corresponding to distributed tasks received by the node as a worker node.

3. The method according to claim 2, wherein, Stopping receiving new tasks in response to a logout request of a target application includes: in response to the logout request of the target application, sending a logout notice to the server, so that the server marks the target application of the node as a logged-out state, and issues new distributed tasks corresponding to the target application to nodes that are not in a logged-out state; if there is the first distributed task, sending a logout notice to the master node corresponding to the first distributed task, so that the master node marks the target application of the node as a logged-out state, and stops allocating subtasks of the distributed task corresponding to the target application to nodes in a logged-out state.

4. The method according to any one of claims 1 - 3, wherein The distributed task is a periodically executed distributed task; the server designates a master node corresponding to each period respectively in each period, and the master nodes corresponding to different periods are the same or different. Alternatively, the master node corresponding to any period continues to use the master node of the previous period. The method further includes: in response to the logout request of the target application, sending a master node switch notice to the server, and the master node switch notice is used to instruct the server to re-allocate a master node for the periodically executed distributed task.

5. The method according to any one of claims 1 - 4, wherein After completing the subtasks to be processed by the node in the first distributed task, determining that the node has completed processing the first distributed task includes: emptying the task queue corresponding to the first distributed task, where the task queue contains assigned but not yet run subtasks; after the processed subtasks have been processed and the processing results are sent to the master node, determining that the node has completed processing the first distributed task.

6. The method according to claim 5, wherein, If there is a second distributed task, the method further includes: If it is detected that the target application of any worker node corresponding to the second distributed task is in the offline state, and among the subtasks assigned to this worker node, there are some subtasks that have not returned processing results, then allocate the some subtasks to nodes that are not in the offline state.

7. The method according to any one of claims 1 to 4, wherein, After completing the subtasks to be processed by the node in the first distributed task, determining that the node has completed processing the first distributed task includes: after all the subtasks assigned to the node in the first distributed task have been processed, determining that the node has completed processing the first distributed task.

8. The method according to any one of claims 1-7, wherein, The method further includes: obtaining the offline methods corresponding to the master node and / or worker nodes configured by the user, where the offline methods include a first offline method and a second offline method; where the first offline method of the worker node is used to indicate that the subtasks to be processed are assigned subtasks, and the second offline method is used to indicate that the subtasks to be processed are processed subtasks; after all the subtasks included in the second distributed task have been completed, determining that the node has completed processing the second distributed task includes: if the offline method of the master node is the first offline method, then after all the subtasks included in the second distributed task have been completed, determining that the node has completed processing the second distributed task; the method further includes: if the offline method of the master node is the second offline method, then after the processed subtasks corresponding to the second distributed task have been completed, determining that the node has completed processing the second distributed task.

9. The method according to any one of claims 1 - 8, wherein If there is a second distributed task with the node as the master node, then after all the subtasks included in the second distributed task have been completed, determining that the node has completed processing the second distributed task includes: if there is a second distributed task, then after obtaining the processing results of the subtasks sent by the worker nodes corresponding to the second distributed task, updating the current completion count, where the current completion count is used to indicate the number of subtasks that have returned processing results in the second distributed task; after the current completion count reaches the number of subtasks included in the second distributed task, determining that the node has completed processing the second distributed task.

10. The method according to any one of claims 1-9, wherein, The node deploys a target container, and the target application runs in the target container; the offline request of the target application is determined by at least one of the following methods: when a Java hook function is triggered, it is determined that an offline request of the target application is obtained; wherein, the Java hook function is triggered when the target container is about to close; when a container shutdown event or a container stop event corresponding to the target container is monitored in the Spring framework, it is determined that an offline request of the target application is obtained; the node provides an interface for processing the offline request of the target application, and when the interface is called, it is determined that an offline request of the target application is obtained.

11. A method for taking an application offline in a distributed system, wherein, The distributed system includes multiple nodes for processing distributed tasks; The method is applied to any node in the distributed system and includes: in response to an offline request of a target application, determining at least one distributed task corresponding to the target application in the node; determining whether the node has completed the at least one distributed task; If all the distributed tasks corresponding to the target application are completed, then exit the target application to implement the offline of the target application.

12. An application offline device for a distributed system, wherein, The distributed system includes multiple nodes for processing distributed tasks; any distributed task is jointly completed by a master node and at least one worker node. The master node is used to allocate multiple subtasks included in the distributed task, and the worker node is used to process the allocated subtasks; the device is applied to any one of the multiple nodes and includes: a first determination module, configured to, in response to an offline request of a target application, determine at least one distributed task corresponding to the target application in the node; a second determination module, configured to, in at least one distributed task corresponding to the target application, if there is a first distributed task with the node as a worker node, after completing the subtasks to be processed by the node in the first distributed task, determine that the node has completed the processing of the first distributed task; a third determination module, configured to, when there is a second distributed task with the node as a master node, after all the multiple subtasks included in the second distributed task are completed, determine that the node has completed the processing of the second distributed task; an exit module, configured to, after all the distributed tasks corresponding to the target application are completed, exit the target application to implement the offline of the target application.

13. An application offline device for a distributed system, wherein, The distributed system includes multiple nodes for processing distributed tasks; The device is applied to any node in a distributed system, and includes: a fourth determination module, configured to determine at least one distributed task corresponding to the target application in the node in response to a logout request of the target application; a judgment module, configured to judge whether the node has completed the at least one distributed task; and a processing module, configured to exit the target application after all the distributed tasks corresponding to the target application are completed, so as to implement the logout of the target application.

14. An electronic device, wherein, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the electronic device to execute the method according to any one of claims 1-11.

15. A distributed system, wherein, The distributed system includes multiple nodes for processing distributed tasks; the nodes are configured to execute the method according to any one of claims 1-11 when a logout request of a target application is obtained.

16. A computer-readable storage medium, wherein, The computer-readable storage medium stores computer-executable instructions, and when the processor executes the computer-executable instructions, the method according to any one of claims 1-11 is implemented.

17. A computer program product, wherein, including a computer program, and when the computer program is executed by the processor, the method according to any one of claims 1-11 is implemented.

Images