WO2025181569A1 - 一种通信方法、设备、存储介质及计算机程序产品 - Google Patents

一种通信方法、设备、存储介质及计算机程序产品

Info

Publication number
WO2025181569A1
WO2025181569A1 PCT/IB2025/050353 IB2025050353W WO2025181569A1 WO 2025181569 A1 WO2025181569 A1 WO 2025181569A1 IB 2025050353 W IB2025050353 W IB 2025050353W WO 2025181569 A1 WO2025181569 A1 WO 2025181569A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
storage device
master node
distributed cluster
cluster
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/IB2025/050353
Other languages
English (en)
French (fr)
Inventor
张游
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cloud Intelligence Singapore Holding Pvt Ltd
Original Assignee
Cloud Intelligence Singapore Holding Pvt Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cloud Intelligence Singapore Holding Pvt Ltd filed Critical Cloud Intelligence Singapore Holding Pvt Ltd
Publication of WO2025181569A1 publication Critical patent/WO2025181569A1/zh
Anticipated expiration legal-status Critical
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1044—Group management mechanisms 
    • H04L67/1051—Group master selection mechanisms
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9026—Single buffer per packet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes

Definitions

  • the present application relates to the field of communication technology, and in particular to a communication method, device, storage medium, and computer program product.
  • Zookeeper is a distributed application coordination service that provides consistency services for distributed applications.
  • a Zookeeper cluster consists of a master node and several slave nodes.
  • the master node can respond to operation requests, generate configuration tasks corresponding to the operation requests, and synchronize the configuration tasks to all other slave nodes for storage.
  • 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.
  • An embodiment of the present application provides a communication method applicable to any node in a distributed cluster, wherein the distributed cluster as a whole is configured with a storage device, and the method comprises: if the node seizes exclusive write permission for the storage device during the master node election phase, determining that it 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.
  • 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.
  • the 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.
  • a storage device can be configured for the entire distributed cluster.
  • Each node in the distributed cluster can seize the exclusive write permission of the storage device during the master node election phase.
  • the node that successfully seizes the exclusive write permission can become the master node in the distributed cluster.
  • the node that seizes the exclusive write permission can write the work tasks it generates to the storage device and broadcast the work tasks it generates to the slave nodes in the distributed cluster.
  • the slave nodes 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 separately. 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 can be correctly persisted to the storage device, thereby effectively reducing storage costs while ensuring the normal operation of the distributed cluster.
  • Figure 1 is a logical diagram of an exemplary existing communication solution based on distributed clusters
  • Figure 2 is a logical diagram of a communication method provided by an exemplary embodiment of the present application.
  • Figure 3 is a flow chart of a communication method provided by an exemplary embodiment of the present application.
  • Figure 4 is a schematic diagram of the internal structure of a storage device provided by an exemplary embodiment of the present application.
  • Figure 5a is a schematic diagram of an application scenario provided by another exemplary embodiment of the present application.
  • Figure 5b is a schematic diagram of another application scenario provided by another exemplary embodiment of the present application.
  • Figure 6 is a schematic diagram of the structure of a computing device provided by another exemplary embodiment of the present application.
  • FIG. 1 is a logical diagram of an exemplary existing communication solution based on a distributed cluster.
  • a cloud disk is usually mounted separately for each node in the distributed cluster to store data.
  • each node uploads its own workload to its own mounted cloud disk for storage. Consequently, storage costs in distributed clusters remain high.
  • some embodiments of the present application propose: configuring a storage device for the entire distributed cluster. Based on this 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.
  • FIG2 is a logical diagram of a communication method provided by an exemplary embodiment of the present application.
  • a storage device may be configured for the entire distributed cluster.
  • FIG3 is a flow chart of a communication method provided by an exemplary embodiment of the present application.
  • the communication method provided by this embodiment may include steps 300 to 302.
  • Step 300 If the node seizes the exclusive write permission for the storage device during the master node election phase, it determines that it has become the master node.
  • Step 301 while serving as the master node, writes the generated work tasks to the storage device to use the storage device to store the work tasks for the distributed cluster.
  • Step 302 broadcast the generated work tasks to the slave nodes in the distributed,cluster.
  • the slave node does not need to perform non-volatile storage after receiving the work task.
  • a storage device is innovatively configured for the entire distributed cluster.
  • the term "centralized” can be understood as the entire distributed cluster, which relies on the storage device for persistent storage of work tasks.
  • the communication solution provided in this embodiment can effectively reduce the storage cost in the distributed cluster.
  • the communication logic on the nodes in the distributed cluster is also modified to adapt to the new storage method.
  • the distributed cluster can be a Zookeeper cluster.
  • the following will use the Zookeeper cluster as an exemplary distributed cluster to describe the communication method provided in this embodiment in detail in conjunction with Figures 2 and 3.
  • the distributed cluster is not limited to the Zookeeper cluster, but can also be other clusters that can provide consistency services for distributed applications. This article does not limit this.
  • Zookeeper is a cluster of multiple servers that can provide consistency for distributed applications
  • ZooKeeper clusters implement a master-slave architecture to maintain data consistency across replicas in the cluster.
  • Application scenarios for ZooKeeper clusters include, but are not limited to, unified configuration management, configuration maintenance, domain name services, distributed synchronization, group services, and load balancing.
  • Nodes in a Zookeeper cluster The servers in a Zookeeper cluster include a master server (leader) and multiple slave servers (followers). Each server in the cluster stores the same data, so that no matter which server the client accesses, the data obtained is consistent.
  • the master node is the only scheduler and processor of transaction requests in the cluster working mechanism. It is responsible for responding to all transaction requests that initiate state changes to the ZooKeeper cluster and can also provide read and write services to clients; the slave node is a follower in the cluster working mechanism. It synchronizes the processing results of the transaction request with the master node, can provide read services to clients, and forward the client's write request to the master node.
  • Transaction requests in a ZooKeeper cluster can be understood as requests initiated by the client to perform write operations on the server.
  • the communication method provided in this embodiment is applicable to any node in a Zookeeper cluster.
  • identity of a single node in a Zookeeper cluster may change dynamically, and the identity of a single node may include a master node or a slave node. Therefore, in this embodiment, any node will be taken as an example to explain the communication logic of the node in different identities, so as to present the technical concept of the communication method provided in this embodiment.
  • a storage device configured for the entire Zookeeper cluster supports exclusive write operations only by the master node in the Zookeeper cluster.
  • this embodiment proposes an exclusive write permission preemption mechanism. The node in the Zookeeper cluster that can preempt exclusive write permission to the storage device automatically becomes the master node.
  • the master node election phase can be understood as the phase in which multiple nodes in the Zookeeper cluster compete for the master node.
  • the master node election phase once the master node is missing, it will trigger the master node election phase. For example, When the Zookeeper cluster is initialized, the node identities are not determined, so the master node election phase will be triggered; if the master node in the cluster fails later, the master node election phase will also be triggered.
  • this embodiment reforms the master node election process in the Zookeeper cluster: the aforementioned exclusive write permission preemption mechanism is introduced into the master node election process. That is, in this embodiment, in addition to meeting the original requirements of the Zookeeper cluster for master nodes, a node must also preempt exclusive write permissions to the storage device in this embodiment before becoming a master node. After the reform, it can be ensured that the write permission to the storage device is always exclusively held by the master node in the Zookeeper cluster.
  • this embodiment proposes in step 300 that if the node seizes the 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.
  • the master node in the Zookeeper cluster is the scheduler of work transactions in the cluster. It needs to send its own work tasks to at least one slave node to ensure the consistency of data between the master node and the slave nodes.
  • the node may generate work tasks for the Zookeeper cluster while serving as the master node.
  • A the content of the generated work task
  • other data expressions may 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 described in detail here.
  • the transaction request may be initiated by a client connected to the master node, may be initiated by the master node itself at a fixed time, or may be initiated by a client connected to a slave node and forwarded by the slave node. This embodiment does not limit this.
  • the node while serving as the master node, the node also writes the generated work tasks to the storage device to perform persistent storage of the work tasks.
  • the Zookeeper cluster does not configure persistent storage resources for each slave node, the master node dynamically elected in the Zookeeper cluster can ensure that the work tasks generated in the Zookeeper cluster can all be correctly stored persistently.
  • the node after the node seizes the exclusive write permission to the storage device, it can mount the storage device.
  • the storage device can use a log file to support the storage of work tasks. Based on this, the node can write the generated work tasks into the log file in the storage device to achieve persistent storage of the work tasks.
  • this is only exemplary.
  • other work task writing schemes can also be used to ensure that the work tasks are stored. As long as the task can be persistently stored in the storage device, no further examples will be given here.
  • the number of work tasks that have not yet been snapshotted may be monitored. If the number of work tasks that have not yet been snapshotted exceeds a preset threshold, snapshot files are generated for the work tasks that have not yet been snapshotted and written to the storage device. The work tasks that have not yet been snapshotted may also be deleted from the storage device. Subsequently, when the number of work tasks that have not yet been snapshotted exceeds the preset threshold again, new snapshot files may be generated and written to the storage device.
  • the node can also temporarily store the generated work tasks, for example, in its own memory or cache. This can provide an implementation basis for the subsequent work task application link, thereby ensuring that the application of the work tasks can be completed smoothly and quickly in the node.
  • 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 policy.
  • FIFO first-in-first-out
  • the slave node no longer needs to persistently store the received work tasks.
  • 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.
  • step 300 if the node does not seize exclusive write permission for the storage device, it will act as a slave node in the Zookeeper cluster. The following will explain the communication logic of the node during its slave status.
  • the node When the node is a slave node, it no longer needs to store the work tasks persistently after receiving the work tasks broadcast by the master node in the Zookeeper cluster.
  • the node when the node is a slave node, it can temporarily store the received work tasks as a basis for the application of the work tasks.
  • the node can store the received work tasks in the local RAM.
  • RAM is a random access memory (RAM), which is usually 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, the data stored in RAM will disappear after power failure and cannot be recovered.
  • a storage device can be configured for the entire Zookeeper cluster.
  • Each node in the Zookeeper cluster can seize the exclusive write permission of the storage device during the master node election phase.
  • the node that successfully seizes the exclusive write permission can become the master node in the Zookeeper cluster.
  • the node that seizes the exclusive write permission can write the work tasks it generates to the storage device and broadcast the work tasks it generates to the slave nodes in the Zookeeper cluster.
  • 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.
  • a time-sharing and reusable storage device can be configured for the Zookeeper cluster.
  • 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.
  • the storage device may be a shared disk array, a network attached storage (NAS), or a cloud disk that supports sharing, but this embodiment does not limit this.
  • NAS network attached storage
  • the storage device may be a shared disk array, a network attached storage (NAS), or a cloud disk that supports sharing, but this embodiment does not limit this.
  • Shared disk array Connect multiple computers to the same disk array to enable multiple computers to share data in the storage device.
  • NAS 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.
  • the shared heartbeat between Zookeeper cluster nodes requires file locks to maintain the correctness of heartbeat acquisition .
  • Shared cloud disk A data storage and sharing platform based on cloud computing technology. It supports the use of NVMe (Non-Volatile Memory Express) protocol and can flexibly modify the node's mount permissions.
  • NVMe Non-Volatile Memory Express
  • 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, and improves the smoothness of switching access rights to the storage device between nodes, thereby effectively improving the efficiency of communication and storage.
  • FIG4 is a schematic diagram of the internal structure of a storage device provided by an exemplary embodiment of the present application.
  • the storage device in this embodiment may include a work task storage area, which may utilize a standalone file system.
  • a standalone file system is a file system that only allows read and write access from a single machine, which corresponds to the exclusive write permission in this embodiment.
  • Exclusive write permission for the storage device can be understood as exclusive write permission for the work task storage area within the storage device.
  • a shared read-write area can also be set up in the storage device.
  • the storage device can include a work task storage area and a shared read-write area.
  • each node in the Zookeeper cluster has read and write permissions to the shared read-write area.
  • the shared read-write area can be used to support the master node election process.
  • the master node election process included two stages: the node identity self-recognition stage and the exclusive write permission preemption stage.
  • the shared read-write area is used to optimize the node identity self-recognition stage.
  • 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 identity information, the connection status of the node with other devices, etc.
  • 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.
  • the node if the node reads the heartbeat information corresponding to the master node from the shared read-write area, it determines that it has become a slave node. After determining its own identity, the node can continue to write its own heartbeat information to the shared read-write area.
  • the heartbeat information read contains the heartbeat information corresponding to the master node, it can be determined that there is already a master node in the Zookeeper cluster, that is, it automatically identifies itself as a slave node.
  • the heartbeat information containing its own slave node identity is written to the shared read-write area of the storage device for subsequent reference by other nodes in the Zookeeper cluster.
  • the node will recognize that the master node is missing in the Zookeeper cluster and that it should become the master node.
  • the inventors found that based on the heartbeat information, multiple nodes in the Zookeeper cluster may recognize that they should become the master node. Therefore, the split-brain phenomenon may occur during the node identity self-recognition stage.
  • the 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 a node's 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 will no longer be able to write to the resource.
  • 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, but only one node can successfully add a PR lock.
  • the node that successfully adds the PR lock that is, the node that preempts the exclusive write permission to the work task storage area, automatically becomes the master node.
  • 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 brain split problems, and further ensuring the normal operation of the Zookeeper cluster.
  • each node in the Zookeeper cluster no longer need to perform complex interactions. Instead, each node can 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 phase, the possible occurrence of split-brain problems can be effectively avoided.
  • nodes in the ZooKeeper cluster may fail during communication.
  • crash recovery in the ZooKeeper cluster can be supported based on the ZooKeeper Automic Broadcast (ZAB) protocol.
  • ZAB ZooKeeper Automic Broadcast
  • this embodiment further proposes to modify the ZAB protocol.
  • the protocol is modified to ensure that the ZooKeeper cluster can recover from crashes normally under the modified storage method.
  • 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 cannot be written to the storage device, thereby ensuring the normal operation of the cluster.
  • a slave node in the Zookeeper cluster may also fail. After a slave node fails, it can be automatically restarted or manually restarted by a staff member. If a target slave node in the Zookeeper cluster restarts, the node can respond to a pause request sent by the target slave node after the restart and control the storage device to pause responding to write operations related to the work task. The node can also subsequently respond to a resume request sent by the target slave node and control the storage device to resume responding to write operations related to the work task.
  • the target slave node is any slave node in the Zookeeper cluster, and the target slave node can perform node recovery by mounting a storage device.
  • the node controls the storage device to suspend responding to write operations related to work tasks, it still holds exclusive write permissions to the storage device and does not need to disconnect the storage device. It only needs to suspend its own work task generation process and the process of writing work tasks to the storage device to ensure that the storage device will not add new work tasks during the recovery of the target slave node. After the target slave node completes node recovery, the node can resume its own work task generation and work task writing operations on the storage device.
  • 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.
  • 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.
  • the node fails during its period as a slave node: If a failure occurs during this period, the node can be actively or passively restarted. After restarting, it sends a pause request to the Zookeeper cluster master node, causing the master node to suspend write operations for its workloads. The node can then mount the storage device and read the data needed for recovery from the storage device to complete node recovery. After node recovery is complete, it can send a recovery request to the Zookeeper cluster master node to resume normal operation.
  • the node can mount the storage device, but the node can only obtain read permission on the storage device and cannot perform write operations on the storage device.
  • the latest snapshot file can be read from the storage device, and the node can be recovered based on the device status, data structure, and context information recorded in the snapshot file.
  • a recovery request is sent to the master node to restore the normal operation of the Zookeeper cluster.
  • any node in the cluster after any node in the cluster is restarted, it can obtain the data required for recovery from the storage device, so that it can update the latest status of the cluster as quickly as possible, so that the restarted node can be consistent with the status of other nodes in the cluster as soon as possible, thereby ensuring the consistency of data between nodes in the cluster.
  • the Zookeeper cluster can re-enter the master node election phase to select a new master node for the Zookeeper cluster in the master node election phase to take over the work of the failed master node, so that the Zookeeper cluster can maintain normal operation.
  • a slave node in a Zookeeper cluster fails during the communication process, it can mount a storage device and read the data required for recovery from the storage device; and the storage device will not add new work tasks during the slave node recovery period, so that the slave node can recover to the latest state of the cluster as quickly as possible. In this way, no matter 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.
  • 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.
  • 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.
  • the communication logic in the Zookeeper cluster may generally include:
  • node 1 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; [84] 2. In response to the received transaction request "request to change the value of variable A in the node memory from 0 to 1", node 1 generates a work task that can reflect the processing logic required by the transaction request: ⁇ change the device status A to 1 ⁇ ;
  • 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;
  • 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;
  • Node 2 and Node 3 return ACK symbols after temporarily storing the work tasks.
  • Node 1 counts the number of ACK symbols received.
  • Node 1 counts that the number of received ACK symbols is greater than 2, which is more than half of the number of nodes in the Zookeeper cluster. It then determines that the work task can be applied, and changes the device state A to 1.
  • Node 1 sends a Commit message to Node 2 and Node 3 for the aforementioned work task.
  • Node 2 and Node 3 respond to the Commit message and apply the work task respectively, that is, each changes the device state A to 1.
  • Node 1, Node 2, and Node 3 maintain consistency in the value of device state A.
  • node 1 fails during the communication process, its exclusive write permission to the storage device becomes invalid; the heartbeat information of the master node is no longer available in the shared read-write area, which triggers the Zookeeper cluster to re-enter the master node election phase. If node 2 successfully seizes the exclusive write permission to the storage device during the master node election phase, node 2 will become the new master node in the Zookeeper cluster.
  • node 3 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 restarting, causing node 2 to suspend write operations related to the work task. 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 recovery request to node 2, and node 2 can resume write operations related to the work task. Node 3 unmounts the storage device.
  • a single shared cloud disk is configured for the entire Zookeeper cluster, and a work task storage area and a shared read-write area are set up in the shared cloud disk.
  • the master node of the Zookeeper cluster can be uniquely elected, which can avoid the occurrence of brain split in the Zookeeper cluster.
  • the master node in the Zookeeper cluster may be dynamically switched and persistent storage resources are not configured for the slave nodes in the Zookeeper cluster
  • the dynamically changing master node can ensure that the generated work tasks are correctly written into the work task storage area, thereby ensuring the correct persistence of the work tasks in the Zookeeper cluster, which can effectively reduce the Zookeeper cluster.
  • persistent storage resources are not configured for slave nodes, if a slave node fails and restarts, it can be mounted to a shared cloud disk to support node recovery. This allows crash recovery within the Zookeeper cluster even when using a single shared cloud disk, effectively ensuring data consistency across nodes and thus ensuring high cluster availability.
  • 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.
  • 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.
  • the present application also provides a computer program product, including a computer program.
  • a computer program product including a computer program.
  • the steps in the above-mentioned communication method can be implemented.
  • the technical solution of the computer program and the technical solution of the above-mentioned communication method are of the same concept.
  • the technical solution of the computer program and the technical solution of the above-mentioned communication method are of the same concept.
  • details not described in detail in the technical solution of the computer program please refer to the description of the technical solution of the above-mentioned communication method.
  • FIG6 is a schematic diagram of the structure of a computing device provided in another exemplary embodiment of the present application.
  • the computing device can be any node in a distributed cluster, and the distributed cluster as a whole is configured with a storage device.
  • the computing device includes: a memory 64, a processor 65, and a communication component 66.
  • the processor 65 is coupled to the memory 64 and is used to execute the computer program in the memory 64, so as to: determine that the node becomes the master node if it seizes the exclusive write permission for the storage device during the master node election phase; write the generated work tasks to the storage device during the period of being 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 through the communication component 66.
  • the node fails while serving as the master node, the node's exclusive write permission to the storage device becomes invalid.
  • the processor 65 is further configured to: during the period when the node serves as the master node, if If the target slave node restarts, the target slave node controls the storage device to suspend responding to write operations related to the work task in response to a pause request sent by the target slave node after the restart; and controls the storage device to resume responding to write operations related to the work task in response to a resume request sent by the target slave node after node recovery is complete.
  • the target slave node performs node recovery by mounting the storage device.
  • 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.
  • the processor 65 is further configured to: if the node acts as a slave node, after receiving the work task broadcast by the master node in the distributed cluster, perform volatile storage on the work task as a basis for applying the work task.
  • the storage device includes a work task storage area, and the work task storage area is set as a stand-alone file system.
  • the processor 65 seizes the exclusive write permission for the storage device, it is also used to: seize the exclusive write permission for the work task storage area in the storage device.
  • 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 processor 65 is further used to: after the node is started, read 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, determine that the distributed cluster is in the master node election stage; execute the operation of seizing the exclusive write permission for the storage device to determine whether itself becomes the master node.
  • the processor 65 is further configured to: determine that it becomes a slave node if the 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.
  • the processor 65 is further configured to: during the period when the node serves as the master node, if it is detected that the number of work tasks that have not yet been snapshotted exceeds a preset number threshold, generate a snapshot file for the work tasks that have not yet been snapshotted; write the snapshot file to a storage device; and delete the work tasks that have not yet been snapshotted from the storage device.
  • the storage device adopts a shared disk array, a network storage NAS or a cloud disk that supports sharing.
  • the computing device also includes other components such as a display 67 and a power supply component 68.
  • FIG6 only schematically illustrates some components, which does not mean that the computing device only includes the components shown in FIG6 .
  • an embodiment of the present application also 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.
  • the memory in FIG6 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, pictures, videos, etc.
  • the memory 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 memory, flash memory, magnetic disk or optical disk.
  • SRAM static random access memory
  • EEPROM electrically erasable programmable read-only memory
  • EPROM erasable programmable read-only memory
  • PROM programmable read-only memory
  • ROM read-only memory
  • magnetic memory flash memory
  • flash memory magnetic disk or optical disk.
  • the communication component in FIG. 6 is configured to facilitate wired or wireless communication between the device in which the communication component is located and other devices.
  • the device in which the communication component is located can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G/LTE, 5G, or a combination thereof.
  • the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel.
  • the communication component further includes a near field communication (NFC) module to facilitate short-range communication.
  • the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.
  • RFID radio frequency identification
  • IrDA infrared data association
  • UWB ultra-wideband
  • Bluetooth Bluetooth
  • the display in FIG6 includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen 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 may not only sense the boundaries of a touch or slide action, but also detect the duration and pressure associated with the touch or slide action.
  • the power supply assembly in FIG6 provides power to various components of the device in which the power supply assembly is located.
  • 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 is located.
  • the embodiments of the present application may be provided as methods, systems, or computer program products.
  • the present application may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects.
  • the present application may take the form of one or more computer programs containing computer program code. in the form of a computer program product implemented on a computer-usable storage medium (including but not limited to disk storage, CD-ROM, optical storage, etc.).
  • 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 blocks in the block diagram.
  • These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are performed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in a flowchart and/or one or more blocks in a block diagram.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • Memory may include non-permanent storage in a computer-readable medium, in the form of random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash random access memory
  • Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information.
  • the 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 memory (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 technology, 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 medium that can be used to store information that can be computer-readable. Information accessed by the device. As defined in this article, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请实施例提供一种通信方法、设备、存储介质及计算机程序产品。在本申请实施例中，可为分布式集群整体配置一存储设备，在分布式集群的主节点竞选环节，成功抢占到存储设备的独占写权限的节点可成为分布式集群中的主节点。抢占成功的节点在作为主节点期间，可将其生成的工作任务写入存储设备，并将其生成的工作任务广播至分布式集群中的从节点，而从节点无需对工作任务进行非易失性存储。这样，无需再为分布式集群中的各个节点分别配置持久化存储资源，只需为分布式集群配置可分时复用的存储设备即可。

Description

一种通信方法、 设备、 存储介质及计算机程序产品 技术领域
[01]本申请涉及通信技术领域， 尤其涉及一种通信方法、 设备、 存储介质及计算机程序 产品。 背景技术
[02] Zookeeper是一种分布式应用协调服务，可为分布式应用提供一致性服务。 Zookeeper 集群中包括一个主节点和若干个从节点， 主节点可响应于操作请求， 生成操作请求对应 的配置任务， 并将该配置任务同步更新到其他所有的从节点上进行存储。
[03]目前， 通常需要为 Zookeeper集群中的每个节点单独挂载持久化存储资源， 例如， 云盘等， 以为各节点提供节点数据的存储支持。 这导致 Zookeeper集群中的存储的成本 居高不下。 发明内容
[04]本申请的多个方面提供一种通信方法、 设备、 存储介质及计算机程序产品， 用以降 低分布式集群中的存储成本。
[05]本申请实施例提供一种通信方法， 适用于分布式集群中的任一节点， 所述分布式集 群整体配置有一存储设备， 所述方法包括： 若所述节点在主节点竞选环节抢占到针对所 述存储设备的独占写权限， 则确定自身成为主节点； 在作为主节点期间， 将所生成的工 作任务写入所述存储设备， 以利用所述存储设备为所述分布式集群存储工作任务； 将所 生成的工作任务广播至所述分布式集群中的从节点。
[06]本申请实施例还提供一种计算设备， 包括存储器、 处理器和通信组件； 所述存储器 用于存储一条或多条计算机指令； 所述处理器与所述存储器和所述通信组件耦合， 用于 执行所述一条或多条计算机指令， 以用于前述的通信方法。
[07]本申请实施例还提供一种存储计算机程序的计算机可读存储介质， 当所述计算机指 令被一个或多个处理器执行时， 致使所述一个或多个处理器执行前述的通信方法。
[08]本申请实施例还提供一种计算机程序产品， 包括计算机程序； 当计算机程序被处理 器执行时， 致使所述处理器执行前述通信方法。 [09]在本申请实施例中， 可为分布式集群整体配置一存储设备， 分布式集群中的各个节 点可在主节点竞选环节， 对该存储设备的独占写权限进行抢占， 成功抢占到该独占写权 限的节点即可成为分布式集群中的主节点。抢占到独占写权限的节点在作为主节点期间 , 可将其生成的工作任务写入存储设备，并将其生成的工作任务广播至分布式集群中的从 节点， 而从节点在接收到工作任务后无需再进行非易失性存储， 不再需要占用持久化存 储资源。 这样， 不再需要为 Zookeeper集群中的各个节点分别配置持久化存储资源， 而 是为分布式集群配置可分时复用的存储设备即可，分布式集群中动态竞选出的主节点可 保证分布式集群中工作任务能够正确持久化到该存储设备中，从而可在保证分布式集群 正常工作的前提下， 有效降低存储成本。 附图说明
[10]此处所说明的附图用来提供对本申请的进一步理解， 构成本申请的一部分， 本申请 的示意性实施例及其说明用于解释本申请， 并不构成对本申请的不当限定。 在附图中：
[11]图 1为一种示例性的基于分布式集群的现有通信方案的逻辑示意图；
[12]图 2为本申请一示例性实施例提供的一种通信方法的逻辑示意图；
[13]图 3为本申请一示例性实施例提供的一种通信方法的流程示意图；
[14]图 4为本申请一示例性实施例提供的一种存储设备的内部结构示意图；
[15]图 5a为本申请另一示例性实施例提供的一种应用场景的示意图；
[16]图 5b为本申请另一示例性实施例提供的另 - —种应用场景的示意图；
[17]图 6为本申请又一示例性实施例提供的计算设备的结构示意图。 具体实施方式
[18]为使本申请的目的、 技术方案和优点更加清楚， 下面将结合本申请具体实施例及相 应的附图对本申请技术方案进行清楚、 完整地描述。 显然， 所描述的实施例仅是本申请 一部分实施例， 而不是全部的实施例。 基于本申请中的实施例， 本领域普通技术人员在 没有做出创造性劳动前提下所获得的所有其他实施例， 都属于本申请保护的范围。
[19]图 1为一种示例性的基于分布式集群的现有通信方案的逻辑示意图。 参考图 1 , 目 前在云上部署分布式集群，通常会为分布式集群中的每个节点单独挂载一块云盘来存储 分布式集群中的工作任务，各个节点都会将自身所持有的工作任务上传至各自挂载的云 盘上进行存储。 因此， 分布式集群中的存储成本一直居高不下。
[20]为了改善这一现状， 本申请的一些实施例中提出： 为分布式集群整体配置一存储设 备， 基于该存储设备， 即可保障分布式集群的正常工作， 且保障分布式集群中的工作任 务正确持久化， 从而可有效降低分布式集群的存储成本。
[21]以下结合附图， 详细说明本申请各实施例提供的技术方案。
[22]图 2为本申请一示例性实施例提供的一种通信方法的逻辑示意图。 参考图 2, 可为 分布式集群整体配置一存储设备。
[23]基于此， 图 3为本申请一示例性实施例提供的一种通信方法的流程示意图。 参考图 3, 本实施例提供的通信方法， 可包括步骤 300至骤 302。
[24]步骤 300, 若该节点在主节点竞选环节抢占到针对存储设备的独占写权限， 则确定 自身成为主节点。
[25]步骤 301 , 在作为主节点期间， 将所生成的工作任务写入存储设备， 以利用存储设 备为分布式集群存储工作任务。
[26]步骤 302, 将所生成的工作任务广播至分布式，集群中的从节点。
[27]其中， 本实施例中， 从节点在接收到工作任务后无需进行非易失性存储。
[28]本实施例提供的通信方案中， 创新性地提出分布式集群整体配置一存储设备。 这里 的集中可理解为分布式集群整体， 依赖该存储设备进行工作任务的持久化存储。 本实施 例中，无需再为分布式集群中的从节点配置用于存储工作任务的持久化存储资源。显然, 与图 1所示的存储方式相比，本实施例提供的通信方案可有效降低分布式集群中的存储 成本。
[29]本实施例中， 还对分布式集群中节点上的通信逻辑进行了改造， 以适配新的存储方 式。 分布式集群可以是 Zookeeper集群， 以下将以 Zookeeper集群作为一种示例性的分 布式集群， 结合图 2和图 3对本实施例提供的通信方法进行展开详述。 当然， 分布式集 群并不仅限于 Zookeeper集群，还可以是其他能够为分布式应用提供一致性服务的集群, 本文对此不做限定。
[30]在展开详述之前， 先对本实施例中涉及到的几个技术概念进行简要解释。
[31] Zookeeper: Zookeeper是由多个服务器组成的集群， 可以为分布式应用提供一致性 服务。 ZooKeeper集群实现了一种主备模式的系统架构来保持集群中各个副本之间的数 据一致性。 Zookeeper集群的应用场景包括但不限于： 统一配置管理、 配置维护、 域名 服务、 分布式同步、 组服务以及转负载均衡等。
[32]原子广播协议（ ZooKeeper Automic Broadcast, ZAB） : 为 ZooKeeper集群专门设计 的一种支持崩溃恢复的一致性协议。 ZAB协议主要包括 “消息广播"和 "崩溃恢复" 两 部分， 在 ZooKeeper集群中， 主要依赖 ZAB协议来实现分布式数据一致性。 基于该协 议， Zookeeper集群中只有主节点 （Leader）可以处理外部的写事务请求， 然后 Leader 将数据同步到其他从节点 （ Follower） .
[33] Zookeeper集群中的节点： Zookeeper集群中的服务器包括一个主服务器（主节点， Leader）和多个从服务器（从节点， Fllower） , 集群中每个服务器都存储有相同的数据 副札 使得客户端无论访问哪个服务器， 所获得的数据都是一致的。 其中， 主节点是集 群工作机制中事务请求的唯一调度者和处理者， 负责响应所有对 ZooKeeper集群发起 状态变更的事务请求，还可为客户端提供读写服务；从节点是集群工作机制中的跟随者， 同步主节点对事务请求的处理结果， 可为客户端提供读服务， 并将客户端的写请求转发 给主节点。 ZooKeeper 集群中的事务请求可理解为客户端发起的对服务端执行写操作的 请求。
[34] Zookeeper集群中的工作任务： ZooKeeper 集群中的主节点可响应接收到的事务请 求， 将事务请求转化成能够反映事务所需处理逻辑的事务提案（Proposal） , 该事务提 案即为本实施例中所涉及的工作任务。
[35]本实施例提供的通信方法可适用于 Zookeeper集群中的任一节点。 当然， 应当理解 的是， Zookeeper集群中单个节点的身份可能是动态变化的， 单个节点的身份可包括主 节点或从节点。 为此， 本实施例中， 将以任一节点为例， 对该节点处于不同身份期间的 通信逻辑进行分别说明， 以呈现本实施例提供的通信方法的技术构思。
[36]本实施例中提出， 为 Zookeeper集群整体配置的存储设备， 仅支持 Zookeeper集群 中的主节点进行独占式写操作。 为此， 本实施例中提出了一种独占写权限抢占机制， Zookeeper集群中能够抢占到对存储设备的独占写权限的节点可自动成为主节点。
[37]发明人在研究过程中发现， 在 Zookeeper集群中需通过主节点竞选环节确定出主节 点。 其中， 主节点竞选环节可以理解为是 Zookeeper集群中的多个节点竞选主节点的环 节。 在 Zookeeper集群中， 一旦主节点缺失， 即会触发进入主节点竞选环节。 例如， 在 Zookeeper 集群初始化时， 节点身份均未确定， 因此， 将触发进入主节点竟选环节； 后 续在集群中的主节点发生故障的情况下， 也会触发进入主节点竞选环节。
[38]应当理解的是， 本实施例中， 实质是对 Zookeeper集群中的主节点竞选环节进行了 改造： 在主节点竞选环节中引入了前述的独占写权限抢占机制。 也即是， 本实施例中， 节点在符合 Zookeeper集群原本对主节点的要求之外， 还需要抢占到对本实施例中存储 设备的独占写权限， 才会成为主节点。 经过改造后， 可保证对存储设备的写权限始终由 Zookeeper集群中的主节点独占 °
[39]基于此， 从通信逻辑的角度来看， 参考图 3 , 本实施例在步骤 300中提出， 若该节 点在主节点竞选环节抢占到针对存储设备的独占写权限， 则确定自身成为主节点。 而若 该节点抢占失败， 则将自动成为 Zookeeper集群中的从节点。
[40] i如前文中的技术概念解释部分提及的， Zookeeper 集群中的主节点是集群中工作 事务的调度者， 需将自身拥有的工作任务发送给至少一个从节点， 以保证主节点和从节 点之间数据的一致性。
[41]为此， 参考图 3 , 在步骤 301中， 该节点在作为主节点期间， 可为 Zookeeper集群 生成工作任务。 在一种可选的工作任务生成方案中： 该节点可接收事务请求， 将该事务 请求转换为工作任务。 例如， 该节点接收到的事务请求为将该节点所存储的数据中的变 量名称由 A改为 B , 则生成的工作任务的内容可以是 “A=B” ， 其代表可以通过将 B 赋值给 A来实现 A、 B之间的替换。 当然， 也可以使用其它的数据表达方式来对工作内 容进行表述，只要能够反映 A、 B之间的替换逻辑即可，在此不再赘述。值得一提的是， 事务请求可以是与主节点连接的客户端发起的， 可以是主节点自身定时发起的， 也可以 是与从节点连接的客户端发起而由从节点转发过来的， 本实施例对此不做限定。
[42]参考图 3 , 本实施例中， 该节点在作为主节点期间， 还会将生成的工作任务写入至 存储设备中， 以对工作任务进彳亍持久化存储。 这样， 尽管 Zookeeper集群中未为各个从 节点配置持久化存储资源， 但是基于 Zookeeper 集群中动态竞选出的主节点可保证 Zookeeper集群中生成的工作任务均可正确地实现持久化存储。
[43]在一种示例性的工作任务写入方案中：该节点在抢占在对存储设备的独占写权限后， 可挂载存储设备。而存储设备中可采用日志文件的方式来支持工作任务的存储。基于此, 该节点可将生成的工作任务写入存储设备中的日志文件中， 以实现对工作任务的持久化 存储。 当然， 这仅是示例性的， 本实施例中还可采用其它工作任务写入方案， 保证工作 任务能够持久化存储至存储设备中即可， 在此不做更多示例。
[44]进一步可选地， 在该节点作为主节点期间， 还可监测尚未快照的工作任务的数量。 若监测到尚未快照的工作任务的数量超过预设数量阈值，则为尚未快照的工作任务生成 快照文件，并将快照文件写入存储设备；还可将尚未快照的工作任务从存储设备中删除。 后续在监测到尚未快照的工作任务的数量再次超过预设数量阈值时，可继续生成新的快 照文件并写入存储设备中。 这样， 从存储设备的视角来看， 其上将存储有不断产生的快 照文件， 而占用存储资源较多的工作任务则可不断地迭代删除， 以腾出存储设备上的存 储资源， 这可有效提高对存储设备中的存储资源利用率。
[45]另外， 本实施例中， 该节点还可以将生成的工作任务进行暂存， 例如， 可存储在自 身的内存或缓存中。 这可在为后续的工作任务应用环节提供实施基础， 从而保证该节点 中可无障碍且快速地完成工作任务的应用。
[46]继续参考图 3, 在步骤 302中， 该节点还可将生成的工作任务广播至 Zookeeper集 群中的从节点。 一种示例性的广播方案可以是： 该节点可为每个从节点分配一个单独的 队列， 然后将工作任务放到队列中去， 以使从节点从队列中取出工作任务进行存储。 其 中， 若该节点在作为主节点期间生成了多个工作任务， 则可按照生成工作任务的先后顺 序， 依次将工作任务放入队列中， 可选地， 可按照先进先出 ( First in First out, FIFO ) 的发送策略进行发送。
[47]需要说明的是，本实施例中，从节点不再需要对接收到的工作任务进行持久化存储。 但是， 考虑到从节点在后续的工作任务应用环节中需要使用到工作任务， 因此， 本实施 例中， 从节点可对接收到的工作任务进行暂存， 这里的暂存可理解为易失性存储， 例如 存储在自身的内存或缓存中。
[48]如前文提及的， 在步骤 300中， 若该节点未抢占到针对存储设备的独占写权限， 则 将作为 Zookeeper集群中的从节点。 以下将对该节点作为从节点期间的通信逻辑进行说 明。
[49]该节点在作为从节点期间， 可在接收到 Zookeeper集群中的主节点所广播的工作任 务后， 不再需要对工作任务进行持久化存储。 当然， 该节点在作为从节点期间， 可对接 收到的工作任务进行暂存， 以作为工作任务应用的依据。 例如， 该节点可将接收到的工 作任务存储在本地 RAM中， RAM是随机存取存储器 ( Random Access Memory , RAM ), 通常用作操作系统或其他正在运行中的程序的临时数据存储介质，可用来暂时存储程序、 数据和中间结果， 断电后 RAM中存储的数据就会消失， 且无法恢复。
[50]可知， 本实施例中， 该节点在作为从节点期间， 无需对主节点发送的工作任务进行 持久化存储， 这有效不仅降低了存储成本， 而且还有效省去了该节点作为从节点期间的 持久化工作， 使得 Zookeeper集群的性能够得到有效提升。
[51]综上， 本实施例中， 可为 Zookeeper集群整体配置一存储设备， Zookeeper集群中的 各个节点可在主节点竞选环节， 对该存储设备的独占写权限进行抢占， 成功抢占到该独 占写权限的节点即可成为 Zookeeper集群中的主节点。 抢占到独占写权限的节点在作为 主节点期间， 可将其生成的工作任务写入存储设备， 并将其生成的工作任务广播至 Zookeeper 集群中的从节点， 而从节点在接收到工作任务后无需再进行非易失性存储， 不再需要占用持久化存储资源。 这样， 不再需要为 Zookeeper集群中的各个节点分别配 置持久化存储资源， 而是为 Zookeeper集群配置可分时复用的存储设备即可， Zookeeper 集群中动态竞选出的主节点可保证 Zookeeper集群中工作任务能够正确持久化到该存储 设备中 , 从而可在保证 Zookeeper集群正常工作的前提下， 有效降低存储成本。
[52]在上述或下述实施例中， 存储设备可以是共享磁盘阵列， 也可以是网络附属存储器 NAS 或者支持共享的云盘，本实施例不对此进行限定。以下对几种示例性的存储设备进 行简单介绍。
[53]共享磁盘阵列： 将多个计算机连接到同一磁盘阵列上， 实现多台计算机共享存储设 备中的数据。
[54]网络附属存储 ( Network Attached Storage , NAS ) : 一种连接在网络上， 具备资料 存储功能的装置。 其以数据为中心， 将存储设备与服务器彻底分离， 可实现集中管理数 据。 在使用 NAS作为存储设备时， Zookeeper集群节点间共享心跳需要通过文件锁来保 持心跳获取的正确性 o
[55]共享云盘： 一种基于云计算技术的数据存储和共享平台。 可支持使用 NVMe ( Non-Volatile Memory Express )协议， 对节点的挂载权限进行灵活修改。
[56]优选地， 本实施例中可选用共享云盘作为存储设备， 不仅可以实现在云端进行数据 存储， 还能有效避免新的节点向存储设备发起访问时， 旧的节点尚未完全卸载的问题, 提高了各节点之间对存储设备的访问权限进行切换的流畅性，进而可有效提高通信及存 储的效率。
[57]进一步地， 图 4为本申请一示例性实施例提供的一种存储设备的内部结构示意图 参考图 4, 本实施例中的存储设备中可包含工作任务存储区， 该工作任务存储区可以采 用单机文件系统。 单机文件系统是指只允许单机读写的文件系统， 这与本实施例中的独 占写权限相呼应。针对存储设备的独占写权限在此可理解为是针对存储设备中的工作任 务存储区的独占写权限。
[58]本实施例中， 基于存储设备的写权限所具有的独占性， 使得同一时刻下只能有一个 节点对存储设备执行写操作， 这避免了多节点同时写入而出现的数据错乱， 可保证节点 向存储设备写入数据的准确性， 进而保证了 Zookeeper集群所存储的数据的准确性。
[59]继续参考图 4, 在一种可选的改造方案中： 还可在存储设备中设置共享读写区， 这 样， 存储设备中可包含工作任务存储区和共享读写区。 其中， Zookeeper 集群中的每个 节点对共享读写区都具备读写权限。
[60]在该可选的改造方案中， 进一步提出： 可利用共享读写区支持主节点竞选环节。
[61]发明人在研究过程中发现， 按照本实施例提供的通信方案对主节点竞选环节进行改 造后， 主节点竞选环节中包含了两个阶段： 节点身份自我认知阶段和独占写权限抢占阶 段。在该可选的改造方案中，即是利用共享读写区来对节点身份自我认知阶段进行优化。 具体地， 可利用该共享读写区来存储 Zookeeper集群各节点的心跳信息。 其中， 心跳信 息中可包括但不限于节点的身份信息、 节点与其他设备的连接情况等。 基于此， 继续以 作为技术方案说 明示例的节点来说， 可在该节点启动后， 从该共享读写区中读取 Zookeeper 集群各节点的心跳信息。 其中， 该节点的启动， 可能是开机启动也可能是通 信过程中因故障或人为手动控制等而所发生的重启。
[62]对该节点来说， 在读取到心跳信息后可能会出现两种不同的情况， 下面对这两种情 况进行简单介绍。
[63] —种情况下， 若该节点从共享读写区中读取到主节点对应的心跳信息， 则确定自身 成为从节点。 在确定出自身身份后， 该节点可继续向共享读写区写入自身的心跳信息。
[64]这种情况下， 若读取到的心跳信息中包含主节点对应的心跳信息， 则可确定出 Zookeeper 集群中已存在主节点， 即自动将自身确定为从节点。 并将包含自身从节点身 份的心跳信息写入存储设备的共享读写区中， 以供 Zookeeper集群中的其他节点后续参 考。
[65]另一种情况下， 若未读到主节点对应的心跳信息， 则确定 Zookeeper集群处于主节 点竞选环节。 而且， 该节点将自我认知为主节点， 并执行抢占针对存储设备的独占写权 限的操作。
[66]其中， 若未读取到主节点对应的心跳信息， 则该节点将认知 Zookeeper集群中缺失 主节点， 而自身应成为主节点。 发明人在研究过程中发现， 基于心跳信息， Zookeeper 集群中可能会出现多个节点认知自身应成为主节点， 因此， 在节点身份自我认知阶段可 能出现脑裂现象。
[67]呼应于前述的独占写权限抢占阶段， 在这种情况下， Zookeeper 集群各个自身认知 为主节点的节点都会去抢占对存储设备的独占写权限， 而仅有抢占成功的节点， 将称为 主节点， 而抢占失败的节点， 则将称为从节点。 这样， 独占写权限抢占阶段可有效解决 节点身份自我认知阶段中可能出现的脑裂问题。
[68]在一种可选的抢占实现方式中， 可使用 PR ( Persistent Reservation )锁机制进行独占 写权限的抢占。 PR ( Persistent Reservation )锁机制是一种用于管理共享存储资源的重要 机制， PR锁是一种逻辑锁， 用于控制节点对存储设备的访问。 PR锁在节点和存储设备 之间建立了一种独占关系， 当一个节点获取到 PR锁后， 其它节点将无法再对该资源进 行写操作。 在该抢占实现方式中， Zookeeper 集群各个自身认知为主节点的节点都会尝 试向存储设备中的工作任务存储区添加 PR锁， 而仅有一个节点可成功添加 PR锁。 成 功添加 PR锁的节点， 即抢占到对工作任务存储区的独占写权限， 而自动成为主节点。 这样， 通过 PR锁机制， 可保证 Zookeeper集群中仅有一个节点能够抢占到对工作任务 存储区的独占写权限， 进而保证 Zookeeper集群中主节点的唯一性， 进而有效避免脑裂 问题的发生， 并进一步保证 Zookeeper集群的正常运行。
[69]综上， 本实施例中， 在主节点竞选环节中， Zookeeper集群中的各节点之间不再需 要进行复杂的交互， 而是通过存储设备中共享读写区内存储的心跳信息， 即可支持各节 点完成自我身份认知， 可有效提升 Zookeeper集群中的各节点的自我身份认知效率。 而 且， 结合在主节点竞选环节中增设的独占写权限抢占阶段， 可有效避免可能出现脑裂问 题。
[70]在上述或下述实施例中， Zookeeper 集群中的节点在通信过程中可能会发生故障。 如前文对技术概念 的解释部分， 可知， 可基于原子广播协议 ( ZooKeeper Automic Broadcast, ZAB )来支持 ZooKeeper集群中的崩溃恢复。
[71]但是发明人在研究过程中发现，本实施例改造存储方式之后，按照传统的 ZAB协议 已经无法支持 ZooKeeper集群中的崩溃恢复。 为此， 本实施例中进一步提出， 对 ZAB 协议进行改造， 以保证 ZooKeeper集群能在改造后的存储方式下正常实现崩溃恢复。
[72]下面对 “该节点作为主节点期间” 和 “该节点作为从节点期间” 两种情况分别进行 崩溃恢复逻辑的说明。
[73]第一种情况， 该节点在其作为主节点期间： 若该节点在其作为主节点的期间自身发 生故障， 则该节点对存储设备的独占写权限也会失效。 而且， 该节点发生故障将导致 Zookeeper集群中缺失主节点， 进而触发 Zookeeper集群重新进入主节点竞选环节。 关 于主节点竞选环节可参考前文描述， 在此不做重复赘述。
[74]这种情况下， 若该节点在作为主节点期间自身发生故障， Zookeeper集群会自动选 出新的主节点， 以保证 Zookeeper集群中始终有主节点存在， 避免出现无法生成工作任 务或无法将工作任务写入存储设备的情况， 可保证集群的正常运行。
[75]相应地， 在其作为主节点期间， Zookeeper集群中的从节点也可能会发生故障。 从 节点故障后可自动重启或由工作人员手动重启。 若 Zookeeper集群中的目标从节点发生 重启， 则该节点可响应于目标从节点在重启后发送的暂停请求， 控制存储设备暂停响应 关于工作任务的写操作。 该节点后续还可响应于目标从节点发送的恢复请求， 控制存储 设备恢复响应关于工作任务的写操作。 其中， 目标从节点是 Zookeeper集群中的任意一 个从节点， 目标从节点可通过挂载存储设备进行节点恢复。
[76]在该节点控制存储设备暂停响应关于工作任务的写操作的过程中， 其仍然持有针对 存储设备的独占写权限， 而并不需要断开存储设备的挂载。 只需暂停自身关于工作任务 的生成过程以及向存储设备写入工作任务的过程即可， 以保证存储设备在目标从节点恢 复期间不会新增工作任务。 在目标从节点完成节点恢复后， 该节点可恢复自身对于工作 任务的生成以及对存储设备执行的工作任务的写操作。
[77]应当理解的是， 这种情况下， 该节点和目标从节点都挂载存储设备， 目标从节点也 拥有了对存储设备的读权限， 可从存储设备中读取恢复所需的数据（如前文提及的快照 文件等）。 但是存储设备的独占写权限始终由作为主节点的该节点所占有， 并未发生独 占写权限的转移。
[78]据此， 本实施例中， 在集群中的从节点发生故障时， 可在不改变存储设备写权限分 配的情况下， 基于存储设备对从节点进行数据恢复， 并在完成从节点的数据恢复后， 立 即恢复集群的正常运行， 避免了节点故障对集群整体功能的影响。
[79]第二种情况， 该节点在其作为从节点的期间发生故障： 若该节点在其作为从节点的 期间发生故障， 则该节点可主动 /被动地重启， 并在重启后向 Zookeeper集群中的主节点 发送暂停请求， 以使主节点暂停关于工作任务的写操作。 之后， 可挂载存储设备， 并从 存储设备中读取恢 复所需的数据， 以完成节点恢复。 并可在完成节点恢复后， 向 Zookeeper集群中的主节点发送恢复请求， 以恢复主节点的正常运行。
[80]在该节点作为从节点进彳亍节点恢复的过程中， 可挂载存储设备， 但是该节点只能获 取到存储设备的读权限， 而无法向存储设备执行写操作。 完成挂载后， 可从存储设备中 读取最新的快照文件， 可基于快照文件中所记载的设备状态、 数据结构及上下文信息等 数据， 进行节点恢复。 在完成节点恢复后， 向主节点发送恢复请求， 以恢复 Zookeeper 集群的正常运行。 也即是， 集群中任一节点重启后， 都可从存储设备获取到恢复所需的 数据， 以使自身最快速的更新集群的最新状态， 使得重启的节点可以尽快与集群中其它 节点的状态保持一致， 以保证集群中各节点之间数据的一致性。
[81]综上， 本实施例中， Zookeeper集群中的主节点在通信过程中发生故障的情况下， 可使 Zookeeper集群重新进入主节点竞选环节， 以在主节点竞选环节为 Zookeeper集群 选出新的主节点， 来接替故障主节点的工作， 使得 Zookeeper集群能够保持正常运行。 Zookeeper 集群中的从节点在通信过程中发生故障的情况下， 可挂载存储设备， 并从存 储设备中读取恢复所需的数据； 并且， 存储设备不会在从节点恢复期间新增工作任务， 使得从节点能够最快速的恢复到集群的最新状态。 这样， 无论是集群中哪种身份的节点 发生故障，都能启动相应的解决方案，来恢复 Zookeeper集群的正常运行，实现 Zookeeper 集群的高可用性。
[82]图 5a为本申请一示例性实施例提供的一种应用场景的示意图。 图 5b为本申请一示 例性实施例提供的另一种应用场景的示意图。 参考图 5a, Zookeeper集群中包括 3个节 点： 节点 1、 节点 2和节点 3。 Zookeeper集群中配置有一个支持共享的云盘， 该共享云 盘中设置有工作任务存储区和共享读写区， Zookeeper 集群中的共享读写区可支持任一 节点进行与心跳信息相关的读写操作， 但工作任务存储区则采用单机文件系统， 仅支持 单个节点进彳亍独占写操作。 基于此， 在该应用场景中， Zookeeper集群中的通信逻辑大 致可包括：
[83] k Zookeeper集群中的 3个节点启动， 各个节点从存储设备的共享读写区中获取其 它节点的心跳信息。 若基于心跳信息进行自我身份认知后， 节点 1抢占到对共享云盘中 工作任务存储区的独占写权限的抢占 , 则节点 1成为主节点， 节点 2和节点 3则成为从 节点。 节点 1挂载共享云盘， 并持有对工作任务存储区的独占写权限； [84] 2,节点 1响应于接收到的事务请求 "请求将节点内存中变量 A的值由 0修改为 1”， 生成能够反映事务请求所需处理逻辑的工作任务： ｛将设备状态 A修改为 1｝；
[85] 3.节点 1将生成的工作任务存储在自身内存中，并将该工作任务写入共享云盘的工 作任务存储区；
[86] 4, 节点 1 向节点 2和节点 3广播该工作任务， 节点 2和节点 3接收到工作任务后 可存储至自身内存中， 不需要进行持久化存储；
[87] 5. 节点 2和节点 3在暂存工作任务后所返回的确认 ACK符， 节点 1统计接收到的 确认 ACK符的数量；
[88] 6. 节点 1统计出接收到的确认 ACK符的数量大于 2, 超过 Zookeeper集群中节点 数量的一半， 则确定可对工作任务进行应用， 从而将设备状态 A修改为 1；
[89] 7, 节点 1向节点 2和节点 3发送针对前述工作任务的 Commit（提交）消息， 节点 2和节点 3响应于 Commit消息， 分别对该工作任务进行应用， 也即是， 各自将设备状 态 A修改为 1。 至此， 节点 1、 节点 2和节点 3针对设备状态 A的取值保持了一致性；
[90] 8、参考图 5b,节点 1在通信过程中发生故障后，其对存储设备的独占写权限失效； 共享读写区中不再有主节点的心跳信息这会触发 Zookeeper集群重新进入主节点竞选环 节。 若在主节点竞选环节成功抢占到存储设备的独占写权限的是节点 2, 则节点 2将成 为 Zookeeper集群中新的主节点。
[91] 9. 继续参考图 5b, 节点 2成为主节点后， 若节点 3在通信过程中发生故障且被重 启。 则节点 3可在重启后向节点 2发送暂停请求， 以使节点 2暂停关于工作任务的写操 作。 之后， 节点 3可挂载存储设备， 并从存储设备中读取恢复所需的数据， 以完成节点 恢复。 在完成节点恢复后， 节点 3向节点 2发送恢复请求， 节点 2可恢复关于工作任务 的写操作。 节点 3解除挂载存储设备。
[92]综上可知， 在该示例性的应用场景中， 为 Zookeeper集群整体配置了单一的共享云 盘， 并在共享云盘中设置了工作任务存储区和共享读写区。基于共享读写区中所存储的 心跳信息和对工作任务存储区的独占写权限的抢占结果， 可唯一地竞选出 Zookeeper集 群的主节点， 这可避免 Zookeeper集群中脑裂现象的发生。 而且， 尽管 Zookeeper集群 中的主节点可能发生动态切换， 且并未为 Zookeeper集群中的从节点配置持久化存储资 源，但是动态变化的主节点均可保证将所生成的工作任务正确地写入工作任务存储区中, 进而保证为 Zookeeper集群中工作任务的正确持久化， 这可有效降低 Zookeeper集群中 的存储成本。 并且， 虽然并未为从节点配置持久化存储资源， 但是在从节点发生故障而 重启的情况下， 可允许从节点挂载至共享云盘， 以支持从节点进行节点恢复， 这使得， 在使用单一共享云盘的情况下， 依然能够保证 Zookeeper集群中的崩溃恢复， 从而有效 保证各节点之间的数据一致性进而保障集群的高可用性。
[93]需要说明的是， 上述实施例所提供方法的各步骤的执行主体均可以是同一设备， 或 者， 该方法也由不同设备作为执行主体。 比如， 步骤 300至步骤 302的执行主体可以为 设备 A; 又比如， 步骤 300和步骤 301的执行主体可以为设备 A, 步骤 302的执行主体 可以为设备 B; 等等。
[94]另外， 在上述实施例及附图中的描述的一些流程中， 包含了按照特定顺序出现的多 个操作， 但是应该清楚了解， 这些操作可以不按照其在本文中出现的顺序来执行或并行 执行， 操作的序号如 301、 302等， 仅仅是用于区分开各个不同的操作， 序号本身不代 表任何的执行顺序。 另夕卜， 这些流程可以包括更多或更少的操作， 并且这些操作可以按 顺序执行或并行执行。 需要说明的是， 本文中的 “第一” 、 “第二” 等描述， 是用于区 分不同的消息、 设备、 模块等， 不代表先后顺序， 也不限定 “第一” 和 “第二” 是不同 的类型。
[95]本申请实施例还提供一种计算机程序产品， 包括计算机程序。 当计算机程序被处理 器执行时可实现上述通信方法中的步骤。 需要说明的是， 该计算机程序的技术方案与上 述的通信方法的技术方案属于同一构思，计算机程序的技术方案未详细描述的细节内容, 均可以参见上述通信方法的技术方案的描述。
[96]图 6为本申请又一示例性实施例提供的一种计算设备的结构示意图。 该计算设备可 以是分布式集群中的任一节点， 分布式集群整体配置有一存储设备。 如图 6所示， 该计 算设备包括： 存储器 64、 处理器 65以及通信组件 66。
[97]处理器 65, 与存储器 64耦合， 用于执行存储器 64中的计算机程序， 以用于： 若该 节点在主节点竞选环节抢占到针对存储设备的独占写权限， 则确定自身成为主节点； 在 作为主节点期间， 将所生成的工作任务写入存储设备， 以利用存储设备为分布式集群存 储工作任务； 通过通信组件 66, 将所生成的工作任务广播至分布式集群中的从节点。
[98]在一可选实施例中， 若该节点在作为主节点期间发生故障， 则该节点对存储设备的 独占写权限失效。
[99]在一可选实施例中，处理器 65还用于： 在该节点作为主节点期间，若分布式集群中 的目标从节点发生重启， 则响应于目标从节点在重启后发送的暂停请求， 控制存储设备 暂停响应关于工作任务的写操作； 响应于目标从节点在完成节点恢复后发送的恢复请求, 控制存储设备恢复响应关于工作任务的写操作； 其中， 目标从节点通过挂载存储设备进 行节点恢复。
[100]在一可选实施例中， 处理器 65还用于： 若该节点作为从节点且发生重启， 则向分 布式集群中的主节点发送暂停请求； 挂载存储设备； 根据存储设备中存储的工作任务， 进行节点恢复； 在完成节点恢复后， 向分布式集群中的主节点发送恢复请求。
[101]在一可选实施例中， 处理器 65还用于： 若节点作为从节点， 则在接收到分布式集 群中的主节点广播的工作任务后， 对工作任务进行易失性存储， 以作为工作任务应用的 依据。
[102]在一可选实施例中， 存储设备中包含工作任务存储区， 工作任务存储区设置为单 机文件系统， 处理器 65在抢占针对存储设备的独占写权限时， 还用于： 抢占针对存储 设备中的工作任务存储区的独占写权限。
[103]在一可选实施例中， 存储设备还包括共享读写区， 分布式集群中的节点对共享读 写区均具备读写权限， 处理器 65还用于： 在节点启动后， 从共享读写区中读取分布式 集群中其它节点的心跳信息； 若未读到主节点对应的心跳信息， 则确定分布式集群处于 主节点竞选环节； 执行抢占针对存储设备的独占写权限的操作， 以确定自身是否成为主 节点。
[104]在一可选实施例中， 处理器 65还用于： 若从共享读写区中读取到主节点对应的心 跳信息， 则确定自身成为从节点； 在确定出自身身份后， 向共享读写区写入自身的心跳 信息。
[105]在一可选实施例中， 处理器 65还用于： 在该节点作为主节点期间， 若监测到尚未 快照的工作任务超过预设数量阈值， 则为尚未快照的工作任务生成快照文件； 将快照文 件写入存储设备； 将尚未快照的工作任务从存储设备中删除。
[106]在一可选实施例中， 存储设备采用共享磁盘阵列、 网络存储器 NAS或支持共享的 云盘。
[107]进一步，如图 6所示，该计算设备还包括： 显示器 67和电源组件 68等其它组件。 图 6中仅示意性给出部分组件， 并不意味着计算设备只包括图 6所示组件。
[108]值得说明的是， 上述关于计算设备各实施例中的技术细节， 可参考前述的通信方 法各实施例中对计算设备的动作的相关描述， 为节省篇幅， 在此不再赘述， 但这不应造 成本申请保护范围的损失。
[109]相应地， 本申请实施例还提供一种存储有计算机程序的计算机可读存储介质， 计 算机程序被执行时能够实现上述方法实施例中可由计算设备执行的各步骤。
[110]上述图 6 中的存储器， 用于存储计算机程序， 并可被配置为存储其它各种数据以 支持在计算平台上的操作。这些数据的示例包括用于在计算平台上操作的任何应用程序 或方法的指令， 联系人数据， 电话簿数据， 消息， 图片， 视频等。 存储器可以由任何类 型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器（ SRAM） , 电可擦除可编程只读存储器（EEPROM） , 可擦除可编程只读存储器（EPROM） , 可 编程只读存储器（PROM） , 只读存储器（ROM） , 磁存储器， 快闪存储器， 磁盘或光 盘。
[111]上述图 6 中的通信组件被配置为便于通信组件所在设备和其他设备之间有线或无 线方式的通信。 通信组件所在设备可以接入基于通信标准的无线网络， 如 WiFi, 2G、 3G、 4G/LTE、 5G等移动通信网络， 或它们的组合。 在一个示例性实施例中， 通信组件 经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实 施例中， 所述通信组件还包括近场通信（NFC）模块， 以促进短程通信。 例如， 在 NFC 模块可基于射频识别 （RFID）技术， 红外数据协会（ IrDA）技术， 超宽带（ UWB）技 术， 蓝牙（BT）技术和其他技术来实现。
[112] _h述图 6 中的显示器包括屏幕， 其屏幕可以包括液晶显示器（LCD）和触摸面板 （TP） . 如果屏幕包括触摸面板， 屏幕可以被实现为触摸屏， 以接收来自用户的输入信 号。 触摸面板包括一个或多个触摸传感器以感测触摸、 滑动和触摸面板上的手势。 所述 触摸传感器可以不仅感测触摸或滑动动作的边界， 而且还检测与所述触摸或滑动操作相 关的持续时间和压力。
[113]上述图 6 中的电源组件， 为电源组件所在设备的各种组件提供电力。 电源组件可 以包括电源管理系统， 一个或多个电源， 及其他与为电源组件所在设备生成、 管理和分 配电力相关联的组件。
[114]本领域内的技术人员应明白， 本申请的实施例可提供为方法、 系统、 或计算机程 序产品。 因此， 本申请可采用完全硬件实施例、 完全软件实施例、 或结合软件和硬件方 面的实施例的形式。 而且， 本申请可采用在一个或多个其中包含有计算机可用程序代码 的计算机可用存储介质（包括但不限于磁盘存储器、 CD-ROM, 光学存储器等）上实施 的计算机程序产品的形式。
[115]本申请是参照根据本申请实施例的方法、 设备（系统） 、 和计算机程序产品的流 程图和 /或方框图来描述的。应理解可由计算机程序指令实现流程图和 /或方框图中的 每一流程和/或方框、 以及流程图和 /或方框图中的流程和/或方框的结合。 可提供这 些计算机程序指令到通用计算机、 专用计算机、嵌入式处理机或其他可编程数据处理设 备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行 的指令产生用于实现在流程图一个流程或多个流程和 /或方框图一个方框或多个方框 中指定的功能的装置。
[116]这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定 方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指 令装置的制造品，该指令装置实现在流程图一个流程或多个流程和 /或方框图一个方框 或多个方框中指定的功能。
[117]这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上， 使得在计 算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机 或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和 /或方 框图一个方框或多个方框中指定的功能的步骤。
[118]在一个典型的配置中， 计算设备包括一个或多个处理器 （CPU）、 输入/输出接口、 网络接口和内存 „
[119]内存可能包括计算机可读介质中的非永久性存储器， 随机存取存储器 （RAM）和 / 或非易失性内存等形式， 如只读存储器（ROM） 或闪存（flash RAM） o 内存是计算机可读 介质的示例。
[120]计算机可读介质包括永久性和非永久性、 可移动和非可移动媒体可以由任何方法 或技术来实现信息存储。 信息可以是计算机可读指令、 数据结构、 程序的模块或其他数 据。 计算机的存储介质的例子包括， 但不限于相变内存 （PRAM）、 静态随机存取存储器 （SRAM）、 动态随机存取存储器 （DRAM）、 其他类型的随机存取存储器 （RAM）、 只读存 储器 （ROM）、 电可擦除可编程只读存储器 （EEPROM）、 快闪记忆体或其他内存技术、 只读光盘只读存储器 （CD-ROM）、数字多功能光盘（DVD） 或其他光学存储、磁盒式磁 带， 磁带磁盘存储或其他磁性存储设备或任何其他非传输介质， 可用于存储可以被计算 设备访问的信息 。 按照本文中的界定， 计算机可读介质不包括暂存电脑可读媒体 (transitory media) , 如调制的数据信号和载波。
[121]还需要说明的是， 术语 “包括” 、 “包含” 或者其任何其他变体意在涵盖非排他 性的包含， 从而使得包括一系列要素的过程、 方法、 商品或者设备不仅包括那些要素， 而且还包括没有明确列出的其他要素， 或者是还包括为这种过程、 方法、 商品或者设备 所固有的要素。 在没有更多限制的情况下， 由语句 “包括一个 ..... ” 限定的要素， 并不 排除在包括所述要素的过程、 方法、 商品或者设备中还存在另外的相同要素。
[122]以上所述仅为本申请的实施例而已， 并不用于限制本申请。 对于本领域技术人员 来说， 本申请可以有各种更改和变化。 凡在本申请的精神和原理之内所作的任何修改、 等同替换、 改进等， 均应包含在本申请的权利要求范围之内。

Claims

权利要求书
1、 一种通信方法， 适用于分布式集群中的任一节点， 所述分布式集群整体配置有 一存储设备， 所述方法包括： 若所述节点在主节点竞选环节抢占到针对所述存储设备的独占写权限，则确定自身 成为主节点； 在作为主节点期间， 将所生成的工作任务写入所述存储设备， 以利用所述存储设备 为所述分布式集群存储工作任务； 将所生成的工作任务广播至所述分布式集群中的从节点。
2、 根据权利要求 1所述的方法， 其中， 若所述节点在作为主节点期间发生故障， 则所述节点对所述存储设备的独占写权限失效。
3、 根据权利要求 1所述的方法， 还包括： 在所述节点作为主节点期间， 若所述分布式集群中的目标从节点发生重启， 则响应 于所述目标从节点在重启后发送的暂停请求，控制所述存储设备暂停响应关于工作任务 的写操作； 响应于所述目标从节点在完成节点恢复后发送的恢复请求，控制所述存储设备恢复 响应关于工作任务的写操作； 其中， 所述目标从节点通过挂载所述存储设备进行节点恢复。
4、 根据权利要求 3所述的方法， 还包括： 若所述节点作为从节点且发生重启，则向所述分布式集群中的主节点发送暂停请求; 挂载所述存储设备； 根据所述存储设备中存储的工作任务， 进行节点恢复； 在完成节点恢复后， 向所述分布式集群中的主节点发送恢复请求。
5、 根据权利要求 1所述的方法， 还包括： 若所述节点作为从节点，则在接收到所述分布式集群中的主节点广播的工作任务后 , 对所述工作任务进行易失性存储， 以作为工作任务应用的依据。
6、 根据权利要求 1所述的方法， 其中， 所述存储设备中包含工作任务存储区， 所 述工作任务存储区设置为单机文件系统， 抢占针对所述存储设备的独占写权限， 包括： 抢占针对所述存储设备中的工作任务存储区的独占写权限。
7、 根据权利要求 6所述的方法， 其中， 所述存储设备还包括共享读写区， 所述分 布式集群中的节点对所述共享读写区均具备读写权限， 所述方法还包括： 在所述节点启动后，从所述共享读写区中读取所述分布式集群中其它节点的心跳信 若未读到主节点对应的心跳信息， 则确定所述分布式集群处于主节点竞选环节； 执行所述抢占针对所述存储设备的独占写权限的操作， 以确定自身是否成为主节点。
8、 根据权利要求 7所述的方法， 还包括： 若从所述共享读写区中读取到主节点对应的心跳信息， 则确定自身成为从节点； 在确定出自身身份后， 向所述共享读写区写入自身的心跳信息。
9、 根据权利要求 1所述的方法， 还包括： 在所述节点作为主节点期间， 若监测到尚未快照的工作任务超过预设数量阈值， 则 为尚未快照的工作任务生成快照文件； 将所述快照文件写入所述存储设备； 将所述尚未快照的工作任务从所述存储设备中删除。
10、 一种计算设备， 包括存储器、 处理器和通信组件； 所述存储器用于存储一条或多条计算机指令； 所述处理器与所述存储器和所述通信组件耦合，用于执行所述一条或多条计算机指 令， 以用于执行权利要求 1-9任一项所述的通信方法。
11、 一种存储计算机程序的计算机可读存储介质， 其中， 当所述计算机程序被一个 或多个处理器执行时， 致使所述一个或多个处理器执行权利要求 1-9任一项所述的通信 方法。
12、一种计算机程序产品，包括计算机程序，其中， 当计算机程序被处理器执行时， 致使所述处理器执行权利要求 1-9任一项所述的通信方法。
PCT/IB2025/050353 2024-02-27 2025-01-13 一种通信方法、设备、存储介质及计算机程序产品 Pending WO2025181569A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202410217412.4A CN120567865A (zh) 2024-02-27 2024-02-27 一种通信方法、设备、存储介质及计算机程序产品
CN202410217412.4 2024-02-27

Publications (1)

Publication Number Publication Date
WO2025181569A1 true WO2025181569A1 (zh) 2025-09-04

Family

ID=96831711

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2025/050353 Pending WO2025181569A1 (zh) 2024-02-27 2025-01-13 一种通信方法、设备、存储介质及计算机程序产品

Country Status (2)

Country Link
CN (1) CN120567865A (zh)
WO (1) WO2025181569A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN120934993A (zh) * 2025-10-15 2025-11-11 广州爱浦路网络技术有限公司 一种基于共享存储与心跳检测的网元高可用方法和系统

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105426439A (zh) * 2015-11-05 2016-03-23 腾讯科技（深圳）有限公司 一种元数据的处理方法和装置
CN108462537A (zh) * 2018-01-09 2018-08-28 烽火通信科技股份有限公司 一种一主多从通信的实现方法
CN110727508A (zh) * 2019-10-24 2020-01-24 无锡京和信息技术有限公司 一种任务调度系统和调度方法
CN112860787A (zh) * 2019-11-27 2021-05-28 上海哔哩哔哩科技有限公司 分布式主从系统中主节点的切换方法、主节点设备和存储介质
CN115202917A (zh) * 2022-07-05 2022-10-18 浪潮云信息技术股份公司 一种用于虚拟化平台下的分布式集群容错恢复方法及系统
CN116107814A (zh) * 2023-04-04 2023-05-12 阿里云计算有限公司 数据库容灾方法、设备、系统及存储介质
CN117290448A (zh) * 2023-10-01 2023-12-26 上海驿氪信息科技有限公司 一种多租户模式SaaS服务分布式配置同步共享的系统及方法

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105426439A (zh) * 2015-11-05 2016-03-23 腾讯科技（深圳）有限公司 一种元数据的处理方法和装置
CN108462537A (zh) * 2018-01-09 2018-08-28 烽火通信科技股份有限公司 一种一主多从通信的实现方法
CN110727508A (zh) * 2019-10-24 2020-01-24 无锡京和信息技术有限公司 一种任务调度系统和调度方法
CN112860787A (zh) * 2019-11-27 2021-05-28 上海哔哩哔哩科技有限公司 分布式主从系统中主节点的切换方法、主节点设备和存储介质
CN115202917A (zh) * 2022-07-05 2022-10-18 浪潮云信息技术股份公司 一种用于虚拟化平台下的分布式集群容错恢复方法及系统
CN116107814A (zh) * 2023-04-04 2023-05-12 阿里云计算有限公司 数据库容灾方法、设备、系统及存储介质
CN117290448A (zh) * 2023-10-01 2023-12-26 上海驿氪信息科技有限公司 一种多租户模式SaaS服务分布式配置同步共享的系统及方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN120934993A (zh) * 2025-10-15 2025-11-11 广州爱浦路网络技术有限公司 一种基于共享存储与心跳检测的网元高可用方法和系统
CN120934993B (zh) * 2025-10-15 2026-02-03 广州爱浦路网络技术有限公司 一种基于共享存储与心跳检测的网元高可用方法和系统

Also Published As

Publication number Publication date
CN120567865A (zh) 2025-08-29

Similar Documents

Publication Publication Date Title
US9928003B2 (en) Management of writable snapshots in a network storage device
EP4083786A1 (en) Cloud operating system management method and apparatus, server, management system, and medium
US10140303B1 (en) Application aware snapshots
US9727429B1 (en) Method and system for immediate recovery of replicated virtual machines
US9411646B2 (en) Booting secondary processors in multicore system using kernel images stored in private memory segments
US8473692B2 (en) Operating system image management
EP3039844B1 (en) System and method for supporting partition level journaling for synchronizing data in a distributed data grid
US10831741B2 (en) Log-shipping data replication with early log record fetching
CN110019514B (zh) 数据同步方法、装置以及电子设备
WO2014059804A1 (zh) 数据同步方法及系统
WO2015096500A1 (zh) 一种业务迁移方法、装置和一种容灾系统
WO2015081470A1 (zh) 数据处理设备和数据处理的方法
CN103870570A (zh) 一种基于远程日志备份的HBase数据可用性及持久性的方法
US20240329843A1 (en) Methods and systems to improve resumption time of input/output (i/o) operations based on prefetching of configuration data and early abort of conflicting workflows during a non-disruptive automatic unplanned failover from a primary copy of data at a primary storage system to a mirror copy of the data at a cross-site secondary storage system
US10620871B1 (en) Storage scheme for a distributed storage system
JP2009080692A (ja) 仮想計算機システム及び同システムにおけるサービス引き継ぎ制御方法
WO2018010501A1 (zh) 全局事务标识gtid的同步方法、装置及系统、存储介质
JP5217966B2 (ja) ストレージシステムのアップデート処理プログラム、アップデート処理方法及びストレージシステム
CN109450676B (zh) 一种交换机升级方法及装置、电子设备、计算机可读介质
JP2019204216A (ja) データ管理方法およびデータ管理システム
WO2020025049A1 (zh) 数据同步的方法、装置、数据库主机及存储介质
CN107451172A (zh) 用于版本管理系统的数据同步方法及设备
CN114281600A (zh) 一种容灾备份和容灾恢复方法、装置、设备及存储介质
CN110633046A (zh) 一种分布式系统的存储方法、装置、存储设备及存储介质
US11442959B2 (en) System and method of time-based snapshot synchronization

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 25761754

Country of ref document: EP

Kind code of ref document: A1