Communication method, device, storage medium, and computer program product

Abstract

Embodiments of the present application provide a communication method, a device, a storage medium, and a computer program product. In the embodiments of the present application, a storage device can be integrally configured for a distributed cluster, and in a main node competition link of the distributed cluster, a node which successfully preempts an exclusive write permission of the storage device can become a main node in the distributed cluster. When the node which achieves successful preemption is used as the main node, a working task generated by the node can be written into the storage device, and is broadcasted to slave nodes in the distributed cluster, and the slave nodes do not need to perform non-volatile storage on the working task. In this way, the distributed cluster only needs to be configured with a time-division multiplexed storage device, without needing to configure persistent storage resources for each node in the distributed cluster any more.

Description

[0001] A communication method, device, storage medium and computer program product

[0002]

[0001] The present application relates to the field of communication technology, and in particular to a communication method, device, storage medium, and computer program product.

[0003] Zookeeper is a distributed application coordination service that can provide consistency services for distributed applications. The Zookeeper cluster includes a master node and several slave nodes. The master node can respond to an operation request, generate a configuration task corresponding to the operation request, and synchronize the configuration task to all other slave nodes for storage.

[0004]

[0003] Currently, it is usually necessary to mount a persistent storage resource, such as a cloud disk, for each node in the Zookeeper cluster to provide storage support for node data. This results in high storage costs in the Zookeeper cluster.

[0005]

[0004] Various aspects of the present application provide a communication method, device, storage medium, and computer program product for reducing storage costs in a distributed cluster.

[0006]

[0005] An embodiment of the present application provides a communication method, which is applicable to any node in a distributed cluster, and the distributed cluster as a whole is configured with a storage device. The method includes: if the node seizes the exclusive write permission for the storage device in the master node election phase, then determining that itself becomes the master node; while serving as the master node, writing the generated work tasks to the storage device, so as to use the storage device to store the work tasks for the distributed cluster; and broadcasting the generated work tasks to the slave nodes in the distributed cluster.

[0007]

[0006] An embodiment of the present application also provides a computing device, comprising a memory, a processor, and a communication component; the memory is used to store one or more computer instructions; the processor is coupled to the memory and the communication component, and is used to execute the one or more computer instructions for use in the aforementioned communication method.

[0008]

[0007] An embodiment of the present application also provides a computer-readable storage medium storing a computer program, which, when the computer instructions are executed by one or more processors, causes the one or more processors to execute the aforementioned communication method.

[0009]

[0008] An embodiment of the present application also provides a computer program product, comprising a computer program; when the computer program is executed by a processor, the processor is caused to execute the aforementioned communication method.

[0009] In an embodiment of the present application, a storage device can be configured for the entire distributed cluster. Each node in the distributed cluster can seize exclusive write permissions to the storage device during the master node election phase. The node that successfully seizes the exclusive write permissions becomes the master node in the distributed cluster. While serving as the master node, the node that seizes the exclusive write permissions can write its generated work tasks to the storage device and broadcast its generated work tasks to the slave nodes in the distributed cluster. After receiving the work tasks, the slave nodes no longer need to perform non-volatile storage and no longer need to occupy persistent storage resources. In this way, it is no longer necessary to configure persistent storage resources for each node in the Zookeeper cluster. Instead, a time-sharing and reusable storage device can be configured for the distributed cluster. The master node dynamically elected in the distributed cluster can ensure that the work tasks in the distributed cluster are correctly persisted to the storage device, thereby effectively reducing storage costs while ensuring the normal operation of the distributed cluster. Description of the Figures

[0010] The accompanying drawings described herein are intended to provide a further understanding of the present application and constitute a part of the present application. The exemplary embodiments of the present application and their descriptions are intended to explain the present application and do not constitute an improper limitation of the present application. In the accompanying drawings:

[0011] FIG1 is a schematic diagram of an exemplary distributed cluster-based existing communication solution;

[0012] FIG2 is a logic diagram of a communication method provided by an exemplary embodiment of the present application;

[0013] FIG3 is a flow chart of a communication method provided by an exemplary embodiment of the present application;

[0014]

[0014] FIG4 is a schematic diagram of the internal structure of a storage device provided by an exemplary embodiment of the present application;

[0015]

[0015] FIG5a is a schematic diagram of an application scenario provided by another exemplary embodiment of the present application;

[0016]

[0016] FIG5b is a schematic diagram of another application scenario provided by another exemplary embodiment of the present application;

[0017]

[0017] FIG6 is a schematic diagram of the structure of a computing device provided by another exemplary embodiment of the present application.

[0018] To make the objectives, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the described embodiments are only some embodiments of this application, rather than all embodiments. All other embodiments obtained by persons of ordinary skill in the art based on the embodiments of this application without creative work are within the scope of protection of this application.

[0019] FIG1 is a logical diagram of an exemplary existing communication solution based on a distributed cluster. Referring to FIG1 , currently, when deploying a distributed cluster on the cloud, a cloud disk is typically mounted for each node in the distributed cluster to store the distributed cluster's work tasks. Each node uploads its own work tasks to its own mounted cloud disk for storage. As a result, the storage cost of distributed clusters remains high.

[0020]

[0020] In order to improve this situation, some embodiments of the present application propose: configuring a storage device for the entire distributed cluster. Based on the storage device, the normal operation of the distributed cluster can be guaranteed, and the correct persistence of the work tasks in the distributed cluster can be guaranteed, thereby effectively reducing the storage cost of the distributed cluster.

[0021]

[0021] The following describes in detail the technical solutions provided by various embodiments of the present application in conjunction with the accompanying drawings.

[0022]

[0022] FIG2 is a logic diagram of a communication method provided by an exemplary embodiment of the present application. Referring to FIG2, a storage device can be configured for the entire distributed cluster.

[0023]

[0023] Based on this, FIG3 is a flow chart of a communication method provided by an exemplary embodiment of the present application. Referring to FIG3, the communication method provided by this embodiment may include steps 300 to 302.

[0024]

[0024] Step 300: If the node seizes the exclusive write permission for the storage device in the master node election phase, it determines that it becomes the master node.

[0025]

[0025] Step 301: During the period of serving as a master node, the generated work tasks are written to a storage device, so as to use the storage device to store the work tasks for the distributed cluster.

[0026]

[0026] Step 302: broadcast the generated work tasks to the slave nodes in the distributed cluster.

[0027]

[0027] In this embodiment, the slave node does not need to perform non-volatile storage after receiving the work task.

[0028]

[0028] The communication solution provided in this embodiment innovatively proposes configuring a storage device for the entire distributed cluster. The term "centralized" here can be understood as referring to the entire distributed cluster, which relies on this storage device for persistent storage of work tasks. In this embodiment, there is no need to configure persistent storage resources for storing work tasks for slave nodes in the distributed cluster. Clearly, compared to the storage method shown in FIG1 , the communication solution provided in this embodiment can effectively reduce storage costs in a distributed cluster.

[0029] In the present embodiment, the communication logic on the node in the distributed cluster is also transformed to adapt to the new storage mode. The distributed cluster can be a Zookeeper cluster. The Zookeeper cluster will be used as an exemplary distributed cluster below, and the communication method provided in the present embodiment will be described in detail in conjunction with Figures 2 and 3. Of course, the distributed cluster is not limited to the Zookeeper cluster, and can also be other clusters that can provide consistency services for distributed applications, which is not limited herein.

[0030]

[0030] Before the detailed description, several technical concepts involved in this embodiment are briefly explained.

[0031] Zookeeper: Zookeeper is a cluster of multiple servers that provides consistency services for distributed applications. The ZooKeeper cluster implements a master-slave system architecture to maintain data consistency between replicas in the cluster. Application scenarios of the Zookeeper cluster include, but are not limited to, unified configuration management, configuration maintenance, domain name services, distributed synchronization, group services, and load balancing.

[0032] ZooKeeper Automic Broadcast (ZAB): A crash-recovery-supporting consistency protocol specifically designed for ZooKeeper clusters. The ZAB protocol primarily consists of two parts: message broadcast and crash recovery. In a ZooKeeper cluster, distributed data consistency is primarily achieved through the ZAB protocol. Based on this protocol, only the leader node in a ZooKeeper cluster can process external write transaction requests. The leader then synchronizes the data with the other followers.

[0033] Nodes in a ZooKeeper cluster: Servers in a ZooKeeper cluster include a master server (leader) and multiple slave servers (followers). Each server in the cluster stores the same data set, ensuring that clients receive consistent data regardless of which server they access. The master node is the sole scheduler and processor of transaction requests within the cluster's operating mechanism, responsible for responding to all transaction requests that initiate state changes within the ZooKeeper cluster and providing read and write services to clients. Slave nodes are followers within the cluster's operating mechanism, synchronizing the master node's processing results on transaction requests, providing read services to clients, and forwarding client write requests to the master node. A transaction request in a ZooKeeper cluster can be understood as a request initiated by a client to perform a write operation on a server.

[0034]

[0034] Work tasks in the ZooKeeper cluster: The master node in the ZooKeeper cluster can respond to received transaction requests and convert the transaction requests into transaction proposals that can reflect the processing logic required by the transaction. The transaction proposal is the work task involved in this embodiment.

[0035] The communication method provided in the present embodiment is applicable to any node in the Zookeeper cluster. Of course, it should be understood that the identity of a single node in the Zookeeper cluster may be dynamically changed, and the identity of a single node may include a master node or a slave node. For this reason, in the present embodiment, taking any node as an example, the communication logic of the node during different identities is described respectively, to present the technical conception of the communication method provided in the present embodiment.

[0036]

[0036] In the present embodiment, a storage device configured as a Zookeeper cluster as a whole is provided, which only supports the master node in the Zookeeper cluster to perform an exclusive write operation. To this end, in the present embodiment, a mechanism for preempting exclusive write permissions is provided, in which a node that can preempt the exclusive write permission for the storage device in the Zookeeper cluster can automatically become a master node.

[0037] During research, the inventors discovered that in a Zookeeper cluster, a master node must be determined through a master node election process. The master node election process can be understood as the process in which multiple nodes in a Zookeeper cluster compete for the master node. In a Zookeeper cluster, if a master node is missing, the master node election process is triggered. For example, when a Zookeeper cluster is initialized, the node identities are not determined, so the master node election process is triggered. Subsequently, if a master node in the cluster fails, the master node election process is also triggered.

[0038] It should be understood that this embodiment essentially reforms the master node election process in the Zookeeper cluster by introducing the aforementioned exclusive write permission preemption mechanism into the master node election process. That is, in this embodiment, in addition to meeting the original Zookeeper cluster requirements for master nodes, a node must also preempt exclusive write permission to the storage device in this embodiment in order to become a master node. After this reform, it is ensured that write permission to the storage device is always exclusively held by the master node in the Zookeeper cluster.

[0039] Based on this, from the perspective of communication logic, referring to FIG3 , this embodiment proposes in step 300 that if the node seizes exclusive write permission for the storage device during the master node election phase, it determines that it becomes the master node. If the node fails to seize the exclusive write permission, it will automatically become a slave node in the Zookeeper cluster.

[0040]

[0040] As mentioned in the technical concept explanation section above, the master node in the Zookeeper cluster is the scheduler of work transactions in the cluster and needs to send its own work tasks to at least one slave node to ensure data consistency between the master node and the slave nodes.

[0041]

[0041] To this end, referring to FIG3, in step 301, while serving as a master node, the node may generate work tasks for the Zookeeper cluster. In one optional work task generation scheme, the node may receive a transaction request and convert the transaction request into a work task. For example, if the transaction request received by the node is to change the variable name in the data stored by the node from A to B, the content of the generated work task may be "A=B", which represents that the replacement between A and B can be achieved by assigning B to A. Of course, other data representations can also be used to express the work content, as long as they can reflect the replacement logic between A and B. This will not be elaborated here. It is worth mentioning that the transaction request can be initiated by a client connected to the master node, can be initiated by the master node itself at a scheduled time, or can be initiated by a client connected to a slave node and forwarded by the slave node. This embodiment does not limit this.

[0042]

[0042] Referring to FIG. 3 , in this embodiment, while serving as a master node, the node also writes generated work tasks to a storage device for persistent storage of the work tasks. Thus, although persistent storage resources are not configured for each slave node in the Zookeeper cluster, the dynamically elected master node in the Zookeeper cluster ensures that all work tasks generated in the Zookeeper cluster are correctly and persistently stored.

[0043] In an exemplary work task writing scheme, after seizing exclusive write permission for the storage device, the node may mount the storage device. The storage device may use a log file to support the storage of work tasks. Based on this, the node may write the generated work task to the log file in the storage device to achieve persistent storage of the work task. Of course, this is merely exemplary. In this embodiment, other work task writing schemes may be used to ensure that the work task can be persistently stored in the storage device. Further examples are not provided here.

[0044]

[0044] Further optionally, while the node is acting as the master node, the number of work tasks for which a snapshot has not yet been generated may also be monitored. If it is detected that the number of work tasks for which a snapshot has not yet been generated exceeds a preset threshold, a snapshot file is generated for the work tasks for which a snapshot has not yet been generated and the snapshot file is written to the storage device. The work tasks for which a snapshot has not yet been generated may also be deleted from the storage device. Subsequently, when it is detected that the number of work tasks for which a snapshot has not yet been generated again exceeds the preset threshold, new snapshot files may continue to be generated and written to the storage device. In this way, from the perspective of the storage device, continuously generated snapshot files will be stored thereon, and work tasks that occupy a large amount of storage resources may be continuously and iteratively deleted to free up storage resources on the storage device, which can effectively improve the utilization rate of the storage resources in the storage device.

[0045]

[0045] In addition, in this embodiment, the node may also temporarily store the generated work tasks, for example, in its own memory or cache. This can provide an implementation basis for subsequent work task application links, thereby ensuring that the work task application can be completed smoothly and quickly in the node.

[0046] Continuing with FIG3 , in step 302, the node may also broadcast the generated work tasks to the slave nodes in the Zookeeper cluster. An exemplary broadcasting scheme may be: the node may allocate a separate queue for each slave node, and then place the work tasks into the queue, so that the slave nodes can retrieve the work tasks from the queue for storage. If the node generates multiple work tasks while serving as the master node, the work tasks may be placed into the queue in the order in which they were generated. Optionally, the work tasks may be sent according to a first-in, first-out (FIFO) sending strategy.

[0047]

[0047] It should be noted that, in this embodiment, the slave node no longer needs to persistently store the received work tasks. However, considering that the slave node needs to use the work tasks in the subsequent work task application process, in this embodiment, the slave node can temporarily store the received work tasks. Temporary storage here can be understood as volatile storage, such as storage in its own memory or cache.

[0048]

[0048] As mentioned above, in step 300, if the node does not seize exclusive write permission for the storage device, it will serve as a slave node in the Zookeeper cluster. The communication logic during the period when the node serves as a slave node will be described below.

[0049]

[0049] While serving as a slave node, the node no longer needs to persistently store the work tasks after receiving them from the master node in the Zookeeper cluster. Of course, while serving as a slave node, the node can temporarily store the received work tasks as a basis for applying the work tasks. For example, the node can store the received work tasks in local RAM. RAM is a random access memory (RAM), which is typically used as a temporary data storage medium for operating systems or other running programs. It can be used to temporarily store programs, data, and intermediate results. Data stored in RAM will disappear upon power failure and cannot be restored.

[0050]

[0050] It can be seen that in this embodiment, when the node is acting as a slave node, there is no need to persistently store the work tasks sent by the master node. This not only effectively reduces the storage cost, but also effectively eliminates the persistence work of the node during its period as a slave node, so that the performance of the Zookeeper cluster can be effectively improved.

[0051] In summary, in this embodiment, a storage device can be configured for the entire Zookeeper cluster. Each node in the Zookeeper cluster can seize exclusive write permission on the storage device during the master node election phase. The node that successfully seizes the exclusive write permission becomes the master node in the Zookeeper cluster. While serving as the master node, the node that seizes the exclusive write permission can write the work tasks it generates to the storage device and broadcast the generated work tasks to the slave nodes in the Zookeeper cluster. After receiving the work tasks, the slave nodes no longer need to perform non-volatile storage and no longer need to occupy persistent storage resources. In this way, it is no longer necessary to separately configure persistent storage resources for each node in the Zookeeper cluster. Instead, the Zookeeper cluster can be configured with a time-sharing multiplexed storage device. The master node dynamically elected in the Zookeeper cluster can ensure that the work tasks in the Zookeeper cluster can be correctly persisted to the storage device, thereby effectively reducing storage costs while ensuring the normal operation of the Zookeeper cluster.

[0052]

[0052] In the above or following embodiments, the storage device may be a shared disk array, a network attached storage (NAS), or a shared cloud disk, but this embodiment does not limit this. Several exemplary storage devices are briefly introduced below.

[0053]

[0053] Shared disk array: Connect multiple computers to the same disk array to enable multiple computers to share data in the storage device.

[0054]

[0054] Network Attached Storage (NAS): A device connected to the network that has data storage capabilities. It is data-centric and completely separates storage devices from servers, enabling centralized data management. When using NAS as a storage device, sharing heartbeats between Zookeeper cluster nodes requires file locks to maintain the accuracy of heartbeat acquisition. o

[0055] Shared cloud disk: A data storage and sharing platform based on cloud computing technology. It supports the use of the NVMe (Non-Volatile Memory Express) protocol and can flexibly modify node mount permissions.

[0056]

[0056] Preferably, in this embodiment, a shared cloud disk can be selected as a storage device, which not only enables data storage in the cloud, but also effectively avoids the problem that when a new node initiates access to the storage device, the old node has not been completely uninstalled, thereby improving the smoothness of switching access rights to the storage device between nodes, thereby effectively improving the efficiency of communication and storage.

[0057]

[0057] Furthermore, FIG. 4 is a schematic diagram of the internal structure of a storage device provided in an exemplary embodiment of the present application. Referring to FIG. 4 , the storage device in this embodiment may include a work task storage area, which may utilize a stand-alone file system. A stand-alone file system refers to a file system that only allows read and write access by a single machine, which corresponds to the exclusive write permission in this embodiment. The exclusive write permission for the storage device herein can be understood as exclusive write permission for the work task storage area in the storage device.

[0058] In this embodiment, based on the exclusivity of the write permission of the storage device, only one node can perform a write operation on the storage device at the same time, which avoids data confusion caused by simultaneous writing by multiple nodes, and can ensure the accuracy of data written by the node to the storage device, thereby ensuring the accuracy of the data stored in the Zookeeper cluster.

[0059]

[0059] Continuing with FIG. 4 , in an optional modification scheme, a shared read / write area may be provided in the storage device. In this way, the storage device may include a work task storage area and a shared read / write area. Each node in the Zookeeper cluster has read / write permissions to the shared read / write area.

[0060]

[0060] In this optional transformation scheme, it is further proposed that: a shared read-write area can be used to support the master node election link.

[0061] During research, the inventors discovered that, after modifying the master node election process according to the communication solution provided in this embodiment, the master node election process includes two stages: the node identity self-recognition stage and the exclusive write permission preemption stage. In this optional modification solution, the node identity self-recognition stage is optimized by utilizing a shared read-write area. Specifically, the shared read-write area can be used to store the heartbeat information of each node in the Zookeeper cluster. The heartbeat information may include, but is not limited to, the node's identity information, the node's connection status with other devices, etc. Based on this, continuing with the node used as an example in the technical solution, after the node is started, the heartbeat information of each node in the Zookeeper cluster can be read from the shared read-write area. The startup of the node may be a power-on startup or a restart caused by a fault or manual control during the communication process.

[0062]

[0062] For this node, two different situations may occur after reading the heartbeat information. The following briefly introduces these two situations.

[0063] In one case, if the node reads the heartbeat information corresponding to the master node from the shared read-write area, it is determined that the node itself becomes a slave node. After determining its own identity, the node can continue to write its own heartbeat information to the shared read-write area.

[0064] In this case, if the heartbeat information read includes the heartbeat information corresponding to the master node, it can be determined that there is a master node in the Zookeeper cluster, that is, automatically determine itself as a slave node. And the heartbeat information comprising its own slave node identity is written in the shared read-write area of ​​the storage device, for subsequent reference by other nodes in the Zookeeper cluster.

[0065]

[0065] In another case, if the heartbeat information corresponding to the master node is not read, it is determined that the Zookeeper cluster is in the master node election phase. Moreover, the node will recognize itself as the master node and execute the operation of seizing the exclusive write permission for the storage device.

[0066] Wherein, if the heartbeat information corresponding to the master node is not read, the node will lack the master node in the cognitive Zookeeper cluster, and itself should become the master node. The inventor found in the research process that based on the heartbeat information, multiple node cognitions themselves may appear in the Zookeeper cluster and should become the master node. Therefore, the brain fissure phenomenon may occur in the node identity self-cognition stage.

[0067]

[0067] In response to the aforementioned exclusive write permission preemption phase, in this case, each node in the Zookeeper cluster that recognizes itself as a master node will try to preempt exclusive write permission to the storage device. Only the node that successfully preempts will be called the master node, while the node that fails to preempt will be called the slave node. In this way, the exclusive write permission preemption phase can effectively solve the brain split problem that may occur during the node identity self-recognition phase.

[0068] In an optional preemption implementation, a PR (Persistent Reservation) lock mechanism can be used to preempt exclusive write permissions. The PR (Persistent Reservation) lock mechanism is an important mechanism for managing shared storage resources. A PR lock is a logical lock used to control node access to a storage device. A PR lock establishes an exclusive relationship between a node and a storage device. Once a node acquires a PR lock, other nodes are no longer able to write to the resource. In this preemption implementation, each node in the Zookeeper cluster that recognizes itself as a master node will attempt to add a PR lock to the work task storage area in the storage device. Only one node can successfully add the PR lock. The node that successfully adds the PR lock preempts exclusive write permissions to the work task storage area and automatically becomes the master node. In this way, through the PR lock mechanism, it can be ensured that only one node in the Zookeeper cluster can seize the exclusive write permission to the work task storage area, thereby ensuring the uniqueness of the master node in the Zookeeper cluster, effectively avoiding the occurrence of the split-brain problem, and further ensuring the normal operation of the Zookeeper cluster.

[0069] In summary, in the present embodiment, in the master node election link, the nodes in the Zookeeper cluster no longer need to perform complex interactions. Instead, each node can be supported to complete self-identity recognition through the heartbeat information stored in the shared read-write area of ​​the storage device, which can effectively improve the self-identity recognition efficiency of each node in the Zookeeper cluster. Moreover, combined with the exclusive write permission preemption phase added in the master node election link, the possible occurrence of brain fissure problem can be effectively avoided.

[0070]

[0070] In the above or following embodiments, nodes in the Zookeeper cluster may fail during the communication process. As explained in the previous section on technical concepts, crash recovery in the ZooKeeper cluster can be supported based on the ZooKeeper Automic Broadcast (ZAB) protocol.

[0071]

[0071] However, the inventors discovered during the research that after the present embodiment transforms the storage mode, it is no longer possible to support crash recovery in the ZooKeeper cluster according to the traditional ZAB protocol. To this end, the present embodiment further proposes that the ZAB protocol be transformed to ensure that the ZooKeeper cluster can normally achieve crash recovery under the transformed storage mode.

[0072]

[0072] The following describes the crash recovery logic for the two cases of "the node serving as a master node" and "the node serving as a slave node".

[0073] In the first case, if the node itself fails during its time as the master node, the node's exclusive write permission to the storage device will also become invalid. Moreover, the node failure will cause the Zookeeper cluster to lose the master node, thereby triggering the Zookeeper cluster to re-enter the master node election phase. For details about the master node election phase, please refer to the previous description and will not be repeated here.

[0074]

[0074] In this case, if the node fails while serving as the master node, the Zookeeper cluster will automatically select a new master node to ensure that there is always a master node in the Zookeeper cluster, avoiding the situation where work tasks cannot be generated or work tasks cannot be written to the storage device, thereby ensuring the normal operation of the cluster.

[0075]

[0075] Accordingly, during its period as a master node, a slave node in the Zookeeper cluster may also fail. After a slave node fails, it may automatically restart or be manually restarted by a staff member. If a target slave node in the Zookeeper cluster restarts, the node may control the storage device to suspend responding to write operations on the work task in response to a pause request sent by the target slave node after restarting. The node may also subsequently control the storage device to resume responding to write operations on the work task in response to a recovery request sent by the target slave node. Wherein, the target slave node is any slave node in the Zookeeper cluster, and the target slave node may perform node recovery by mounting a storage device.

[0076] While the node controls the storage device to pause responding to write operations related to work tasks, it still holds exclusive write permissions for the storage device and does not need to disconnect the storage device. It only needs to pause its own work task generation process and the process of writing work tasks to the storage device to ensure that no new work tasks are added to the storage device during the target slave node recovery period. After the target slave node completes node recovery, the node can resume its own work task generation and work task writing operations to the storage device.

[0077]

[0077] It should be understood that in this case, both the node and the target slave node mount the storage device, and the target slave node also has read permission on the storage device and can read the data required for recovery (such as the snapshot file mentioned above) from the storage device. However, the exclusive write permission of the storage device is always held by the node as the master node, and no transfer of exclusive write permission occurs.

[0078]

[0078] Accordingly, in this embodiment, when a slave node in the cluster fails, data recovery can be performed on the slave node based on the storage device without changing the write permission allocation of the storage device. After the data recovery of the slave node is completed, the normal operation of the cluster is immediately restored, thereby avoiding the impact of the node failure on the overall function of the cluster.

[0079] In the second case, the node fails while it is a slave node: If the node fails while it is a slave node, the node can be restarted actively or passively, and after restarting, a pause request is sent to the master node in the Zookeeper cluster to cause the master node to suspend write operations on the work task. Afterwards, a storage device can be mounted and the data required for recovery can be read from the storage device to complete node recovery. After completing node recovery, a recovery request can be sent to the master node in the Zookeeper cluster to restore the normal operation of the master node.

[0080] While the node is performing node recovery as a slave node, it can mount a storage device. However, the node only has read access to the storage device and cannot write to it. After mounting, the node can read the latest snapshot file from the storage device and perform node recovery based on the device status, data structure, and context information recorded in the snapshot file. After node recovery is complete, a recovery request is sent to the master node to restore the normal operation of the Zookeeper cluster. In other words, after any node in the cluster is restarted, it can obtain the data required for recovery from the storage device, allowing it to quickly update the latest cluster status. This allows the restarted node to quickly maintain consistency with the status of other nodes in the cluster, thereby ensuring data consistency across all nodes in the cluster.

[0081] In summary, in this embodiment, if a master node in a Zookeeper cluster fails during communication, the Zookeeper cluster can re-enter the master node election phase, where a new master node is selected to take over the work of the failed master node, allowing the Zookeeper cluster to maintain normal operation. If a slave node in a Zookeeper cluster fails during communication, it can mount a storage device and read the data required for recovery from the storage device. Furthermore, the storage device will not add new tasks during the slave node recovery period, allowing the slave node to quickly recover to the latest state of the cluster. In this way, regardless of which node in the cluster fails, the corresponding solution can be activated to restore the normal operation of the Zookeeper cluster, achieving high availability of the Zookeeper cluster.

[0082]

[0082] FIG5a is a schematic diagram of an application scenario provided by an exemplary embodiment of the present application. FIG5b is a schematic diagram of another application scenario provided by an exemplary embodiment of the present application. Referring to FIG5a, the Zookeeper cluster includes three nodes: Node 1, Node 2, and Node 3. The Zookeeper cluster is configured with a cloud disk that supports sharing. The shared cloud disk is provided with a work task storage area and a shared read-write area. The shared read-write area in the Zookeeper cluster can support any node to perform read and write operations related to heartbeat information, but the work task storage area uses a stand-alone file system and only supports a single node to perform exclusive write operations. Based on this, in this application scenario, the communication logic in the Zookeeper cluster may generally include:

[0083] The three nodes in the Zookeeper cluster start up, and each node obtains the heartbeat information of other nodes from the shared read-write area of ​​the storage device. If node 1 obtains exclusive write permission to the work task storage area in the shared cloud disk after self-identification based on the heartbeat information, node 1 becomes the master node, and nodes 2 and 3 become slave nodes. Node 1 mounts the shared cloud disk and holds exclusive write permission to the work task storage area.

[0084] 2. In response to the received transaction request "request to change the value of variable A in node memory from 0 to 1", node 1 generates a work task that reflects the processing logic required by the transaction request: {change device status A to 1};

[0084]

[0085] 3. Node 1 stores the generated work task in its own memory and writes the work task to the work task storage area of ​​the shared cloud disk;

[0085]

[0086] 4. Node 1 broadcasts the work task to nodes 2 and 3. After receiving the work task, nodes 2 and 3 can store it in their own memory without the need for persistent storage;

[0086]

[0087] 5. Node 2 and Node 3 return ACK symbols after temporarily storing the work tasks. Node 1 counts the number of ACK symbols received.

[0087]

[0088] 6. Node 1 counts the number of received ACK symbols and finds that it is greater than 2, which is more than half of the number of nodes in the Zookeeper cluster. Node 1 then determines that the task can be applied and changes the device state A to 1.

[0088]

[0089] 7. Node 1 sends a Commit message to nodes 2 and 3 regarding the aforementioned work task. In response to the Commit message, nodes 2 and 3 each apply the work task, i.e., they each change device state A to 1. At this point, nodes 1, 2, and 3 maintain consistency in the value of device state A.

[0089]

[0090] 8. Referring to Figure 5b, after Node 1 fails during communication, its exclusive write access to the storage device becomes invalid. The shared read / write area no longer contains the master's heartbeat information, triggering the Zookeeper cluster to re-enter the master election phase. If Node 2 successfully seizes exclusive write access to the storage device during the master election phase, it becomes the new master in the Zookeeper cluster.

[0090]

[0091] 9. Continuing with Figure 5b, after Node 2 becomes the master node, if Node 3 fails during communication and is restarted, Node 3 can send a pause request to Node 2 after restart, causing Node 2 to suspend write operations for its workload. Node 3 can then mount the storage device and read the data required for recovery from the storage device to complete node recovery. After node recovery is complete, Node 3 sends a resume request to Node 2, allowing Node 2 to resume write operations for its workload. Node 3 then unmounts the storage device.

[0091]

[0092] In summary, in this exemplary application scenario, a single shared cloud disk is configured for the entire Zookeeper cluster, with a work task storage area and a shared read / write area set up within the shared cloud disk. Based on the heartbeat information stored in the shared read / write area and the results of preempting exclusive write permissions to the work task storage area, a unique election can be made for the Zookeeper cluster's master node, thus preventing the occurrence of split-brain in the Zookeeper cluster. Furthermore, although the master node in the Zookeeper cluster may dynamically switch, and persistent storage resources are not configured for the slave nodes in the Zookeeper cluster, the dynamically changing master node can ensure that generated work tasks are correctly written to the work task storage area, thereby ensuring the correct persistence of work tasks in the Zookeeper cluster. This effectively reduces storage costs in the Zookeeper cluster. Furthermore, although persistent storage resources are not configured for slave nodes, in the event of a slave node failure and restart, the slave node can be mounted to a shared cloud disk to support node recovery. This allows crash recovery in the Zookeeper cluster to be guaranteed while using a single shared cloud disk, effectively ensuring data consistency between nodes and thus ensuring high availability of the cluster.

[0092]

[0093] It should be noted that the execution entity of each step of the method provided in the above embodiment may be the same device, or the method may be executed by different devices. For example, the execution entity of steps 300 to 302 may be device A; for another example, the execution entity of steps 300 and 301 may be device A, and the execution entity of step 302 may be device B; and so on.

[0093]

[0094] In addition, some of the processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be understood that these operations may be executed in a different order than the order in which they appear herein or in parallel. Operation sequence numbers, such as 301 and 302, are merely used to distinguish between different operations and do not represent any specific execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that terms such as "first" and "second" herein are used to distinguish between different messages, devices, modules, etc., and do not represent a specific order or limit the "first" and "second" to different types.

[0094]

[0095] Embodiments of the present application also provide a computer program product, including a computer program. When executed by a processor, the computer program can implement the steps of the aforementioned communication method. It should be noted that the technical solution of the computer program and the technical solution of the aforementioned communication method share the same concept. For details not described in detail in the technical solution of the computer program, please refer to the description of the technical solution of the aforementioned communication method.

[0095]

[0096] FIG6 is a schematic diagram of the structure of a computing device provided in yet another exemplary embodiment of the present application. The computing device can be any node in a distributed cluster, where the entire distributed cluster is configured with a storage device. As shown in FIG6 , the computing device includes a memory 64, a processor 65, and a communication component 66.

[0096]

[0097] Processor 65 is coupled to memory 64 and is configured to execute a computer program in memory 64 to: determine that the node becomes the master node if it seizes exclusive write permission to the storage device during the master node election phase; write generated work tasks to the storage device while serving as the master node, so as to use the storage device to store the work tasks for the distributed cluster; and broadcast the generated work tasks to the slave nodes in the distributed cluster via communication component 66.

[0097]

[0098] In an optional embodiment, if the node fails while serving as the master node, the node's exclusive write permission to the storage device becomes invalid.

[0098]

[0099] In an optional embodiment, the processor 65 is further used to: during the period when the node serves as the master node, if the target slave node in the distributed cluster restarts, then in response to a pause request sent by the target slave node after the restart, control the storage device to pause responding to write operations regarding the work task; in response to a recovery request sent by the target slave node after completing node recovery, control the storage device to resume responding to write operations regarding the work task; wherein, the target slave node performs node recovery by mounting the storage device.

[0099]

[0100] In an optional embodiment, the processor 65 is further configured to: if the node is a slave node and a restart occurs, send a pause request to the master node in the distributed cluster; mount a storage device; perform node recovery based on the work tasks stored in the storage device; and after completing the node recovery, send a recovery request to the master node in the distributed cluster.

[0100]

[0101] In an optional embodiment, the processor 65 is further configured to: if the node serves as a slave node, after receiving the work task broadcasted by the master node in the distributed cluster, perform volatile storage on the work task as a basis for applying the work task.

[0101]

[0102] In an optional embodiment, the storage device includes a work task storage area, and the work task storage area is set as a stand-alone file system. When the processor 65 seizes the exclusive write permission for the storage device, it is further configured to: seize the exclusive write permission for the work task storage area in the storage device.

[0102]

[0103] In an optional embodiment, the storage device further includes a shared read / write area, and all nodes in the distributed cluster have read and write permissions to the shared read / write area. The processor 65 is further configured to: after the node is started, read the heartbeat information of other nodes in the distributed cluster from the shared read / write area; if no heartbeat information corresponding to the master node is read, determine that the distributed cluster is in the master node election phase; and execute an operation to preempt the exclusive write permission on the storage device to determine whether the node itself has become the master node.

[0103]

[0104] In an optional embodiment, the processor 65 is further configured to: determine itself as a slave node if heartbeat information corresponding to the master node is read from the shared read-write area; and write its own heartbeat information to the shared read-write area after determining its own identity.

[0104]

[0105] In an optional embodiment, the processor 65 is further configured to: generate a snapshot file for the work tasks that have not yet been snapshotted, if it is monitored that the number of work tasks that have not yet been snapshotted exceeds a preset threshold value during the period when the node serves as the master node; write the snapshot file to a storage device; and delete the work tasks that have not yet been snapshotted from the storage device.

[0105]

[0106] In an optional embodiment, the storage device adopts a shared disk array, a network storage NAS, or a cloud disk that supports sharing.

[0106]

[0107] Furthermore, as shown in Figure 6, the computing device also includes other components such as a display 67 and a power supply component 68. Figure 6 schematically illustrates only some components, which does not mean that the computing device only includes the components shown in Figure 6.

[0107]

[0108] It is worth noting that for the technical details of the above-mentioned embodiments of the computing device, reference can be made to the relevant descriptions of the actions of the computing device in the above-mentioned embodiments of the communication method. To save space, they will not be repeated here, but this should not cause any loss of the protection scope of this application.

[0108]

[0109] Accordingly, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, which, when executed, can implement the steps that can be executed by a computing device in the above method embodiment.

[0109]

[0110] The memory described in Figure 6 is used to store computer programs and can be configured to store various other data to support operations on the computing platform. Examples of such data include instructions for any application or method operating on the computing platform, contact data, phone book data, messages, images, videos, and so on. The memory can be implemented using 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 memory, flash memory, magnetic disk, or optical disk.

[0110]

[0111] The communication component in Figure 6 is configured to facilitate wired or wireless communication between the device housing the communication component and other devices. The device housing the communication component can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G / LTE, 5G, or other mobile communication networks, or a combination thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID), infrared data association (IrDA), ultra-wideband (UWB), Bluetooth (BT), or other technologies.

[0111]

[0112] The display in FIG. 6 includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, it may be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, slides, and gestures on the touch panel. The touch sensors can detect not only the boundaries of a touch or slide action, but also the duration and pressure associated with the touch or slide action.

[0112]

[0113] The power supply assembly in FIG6 provides power to various components of the device in which the power supply assembly resides. The power supply assembly may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply assembly resides.

[0113]

[0114] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0114]

[0115] This application is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the application. It should be understood that each process flow and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing device, produce means for implementing the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams.

[0115]

[0116] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0116]

[0117] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0117]

[0118] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0118]

[0119] Memory may include non-permanent storage in computer-readable media, random access memory (RAM), and / or non-volatile memory such as read-only memory (ROM) or flash RAM. o Memory is an example of a computer-readable medium.

[0119]

[0120] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can be implemented using any method or technology to store information. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change RAM (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves.

[0120]

[0121] It should also be noted that the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, product, or apparatus comprising a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, product, or apparatus. In the absence of further limitations, the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, product, or apparatus comprising the elements.

[0121]

[0122] The foregoing description is merely an embodiment of the present application and is not intended to limit the present application. Persons skilled in the art will readily appreciate that various modifications and variations are possible with this application. Any modifications, equivalent substitutions, or improvements within the spirit and principles of this application are intended to be encompassed by the claims of this application.

Claims

Claims 1. A communication method, applicable to any node in a distributed cluster, wherein the distributed cluster is configured as a whole with a storage device, the method comprising: If the node seizes the exclusive write permission for the storage device during the master node election phase, it determines that it will become the master node; During the period of serving as the master node, writing the generated work tasks to the storage device, so as to use the storage device to store the work tasks for the distributed cluster; The generated work tasks are broadcasted to the slave nodes in the distributed cluster.

2. The method according to claim 1, wherein: If the node fails while serving as the master node, the node's exclusive write permission to the storage device becomes invalid.

3. The method according to claim 1, further comprising: During the period when the node serves as the master node, if a target slave node in the distributed cluster restarts, in response to a pause request sent by the target slave node after the restart, controlling the storage device to pause responding to write operations related to the work task; In response to a recovery request sent by the target slave node after completing node recovery, controlling the storage device to resume responding to write operations on work tasks; wherein, the target slave node performs node recovery by mounting the storage device.

4. The method according to claim 3, further comprising: If the node is a slave node and restarts, a pause request is sent to the master node in the distributed cluster; the storage device is mounted; Performing node recovery according to the work tasks stored in the storage device; After the node recovery is completed, a recovery request is sent to the master node in the distributed cluster.

5. The method according to claim 1, further comprising: If the node acts as a slave node, after receiving the work task broadcast by the master node in the distributed cluster, the node performs volatile storage on the work task as a basis for applying the work task.

6. The method according to claim 1, wherein: The storage device includes a work task storage area, and the work task storage area is configured as a stand-alone file system. Seizing exclusive write permission for the storage device includes: seizing exclusive write permission for the work task storage area in the storage device.

7. The method according to claim 6, wherein: The storage device further includes a shared read-write area, and the nodes in the distributed cluster all have read and write permissions to the shared read-write area. The method further includes: after the node is started, reading the heartbeat information of other nodes in the distributed cluster from the shared read-write area. If the heartbeat information corresponding to the master node is not read, it is determined that the distributed cluster is in the master node election phase; and the operation of seizing the exclusive write permission for the storage device is executed to determine whether the distributed cluster becomes the master node.

8. The method according to claim 7, further comprising: If the heartbeat information corresponding to the master node is read from the shared read-write area, it is determined that the node itself becomes a slave node; After determining its own identity, it writes its own heartbeat information into the shared read-write area.

9. The method according to claim 1, further comprising: During the period when the node serves as the master node, if it is monitored that the number of work tasks for which snapshots have not been taken exceeds a preset threshold, a snapshot file is generated for the work tasks for which snapshots have not been taken; The snapshot file is written into the storage device; and the work task for which the snapshot has not yet been taken is deleted from the storage device.

10. A computing device comprising a memory, a processor, and a communication component; the memory is configured to store one or more computer instructions; and the processor is coupled to the memory and the communication component, configured to execute the one or more computer instructions to perform the communication method according to any one of claims 1 to 9.

11. A computer-readable storage medium storing a computer program, wherein: When the computer program is executed by one or more processors, the one or more processors are caused to execute the communication method according to any one of claims 1 to 9.

12. A computer program product comprising a computer program, wherein: When the computer program is executed by a processor, the processor is caused to execute the communication method according to any one of claims 1 to 9.

Images