Method and device for managing distributed cluster, lock service cluster and distributed cluster
By sending lock request messages to the lock service cluster from each data node in the distributed cluster and managing locks according to confirmation messages and priorities, the instability of lock management caused by master node fluctuations is solved, and the stability and high reliability of distributed lock management are achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING OCEANBASE TECHNOLOGY CO LTD
- Filing Date
- 2024-12-26
- Publication Date
- 2026-07-10
Smart Images

Figure CN119357210B_ABST
Abstract
Description
Technical Field
[0001] This specification relates to the field of database technology in one or more embodiments, and particularly to a method and apparatus for managing a distributed cluster, a lock service cluster, and a distributed cluster. Background Technology
[0002] A distributed database architecture is a database system distributed across multiple physical locations. It disperses data across multiple nodes, coordinating and accessing it via network connections. Its main advantages are high availability, scalability, and fault tolerance. For example, a distributed cluster can be formed by setting up a primary and a secondary database. The primary database provides write services and synchronizes data updates to the secondary database. Alternatively, multiple replicas can be set up within a database (e.g., a primary or secondary database) to form a distributed cluster. The primary replica provides services and synchronizes data updates to the other replicas. In the database field, distributed locks are often used to manage the roles of data nodes within these different types of distributed clusters, such as selecting a primary database or a primary replica within the distributed cluster.
[0003] However, in related technologies, lock service clusters used to manage distributed locks often select a master node from multiple lock service nodes, and this master node then manages the roles of data nodes within the distributed cluster. This approach relies on the performance stability of the master node; that is, if the master node experiences performance fluctuations or even crashes, the management of distributed locks within the distributed cluster will become chaotic or even erroneous, thereby affecting the data service performance of the distributed cluster. Summary of the Invention
[0004] In view of the above, this specification provides a data system, a data management method and apparatus, an electronic device and a storage medium through one or more embodiments.
[0005] To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions:
[0006] According to a first aspect of one or more embodiments of this specification, a method for managing a distributed lock is proposed, applied to any data node in a distributed cluster, the method comprising:
[0007] Send a lock request message to each lock service node in the lock service cluster, wherein the lock service node is used to send a lock confirmation message to one of the at least one data node based on the lock request message received from at least one data node;
[0008] If a lock confirmation message is received from at least a preset proportion of lock service nodes within the lock service cluster, the locking process is successful within the distributed cluster. If no lock confirmation message is received from at least a preset proportion of lock service nodes within the lock service cluster, the locking process fails within the distributed cluster.
[0009] In one possible embodiment of this specification, the lock request message includes the node identifier and priority of the data node;
[0010] The lock service node is used to send a lock confirmation message to the highest priority data node among the at least one data node after receiving a lock request message from at least one data node.
[0011] In one possible embodiment of this specification, sending the lock request message to each lock service node in the lock service cluster includes:
[0012] If the current time is the first time elapsed since the last time a lock request message was sent, then a lock request message is sent to each lock service node in the lock service cluster.
[0013] In one possible embodiment of this specification, the lock service node is configured to send a lock confirmation message to the incumbent node if it receives a lock request message from the incumbent node before the lease of the incumbent node expires, wherein the incumbent node is the data node currently holding the lock, and the lease duration is longer than the first duration.
[0014] In one possible embodiment of this specification, the lock request message includes the node identifier and priority of the data node;
[0015] The lock service node is used to update the record of the received lock request message after receiving the lock request message, or to update the record of the lock request message of the same data node based on the received lock request message;
[0016] The lock service node is used to delete lock request messages in the recorded lock request messages that have not been updated for a duration of a second duration, where the second duration is longer than the first duration;
[0017] The lock service node is used to send a lock confirmation message to the data node corresponding to the highest priority lock request message in the recorded lock request messages if it does not receive a lock request message from the incumbent node before the lease of the incumbent node expires. The incumbent node is the data node currently holding the lock, and the lease duration is longer than the first duration.
[0018] In one possible embodiment of this specification, the distributed cluster includes a first database and a second database, wherein the database that successfully acquires a lock within the distributed cluster acquires the identity of the primary database, and the database that fails to acquire a lock within the distributed cluster acquires the identity of the backup database; or...
[0019] The distributed cluster includes multiple replicas, wherein the replica that successfully acquires a lock within the distributed cluster acquires the role of the primary replica, and the replica that fails to acquire a lock within the distributed cluster acquires the role of a regular replica.
[0020] In one possible embodiment of this specification, sending the lock request message to each lock service node in the lock service cluster includes:
[0021] The lock request message is sent to one lock service node in the lock service cluster, so that the lock service node receiving the lock request message forwards the lock request message to each of the remaining lock service nodes; or...
[0022] Send the lock request message to each lock service node in the lock service cluster.
[0023] According to a second aspect of one or more embodiments of this specification, a method for managing a distributed lock is proposed, applied to any lock service node in a lock service cluster, the method comprising:
[0024] Receive lock request messages from at least one data node in the distributed cluster;
[0025] Based on the lock request message received from at least one data node, a lock confirmation message is sent to one of the at least one data node;
[0026] The data node is configured to: successfully acquire a lock in the distributed cluster if it receives a lock confirmation message from at least a preset proportion of lock service nodes within the lock service cluster; and fail to acquire a lock in the distributed cluster if it does not receive a lock confirmation message from at least a preset proportion of lock service nodes within the lock service cluster.
[0027] According to a third aspect of one or more embodiments of this specification, a distributed lock management device is provided, applied to any data node in a distributed cluster, the device comprising:
[0028] The application module is used to send a lock application message to each lock service node in the lock service cluster, wherein the lock service node is used to send a lock confirmation message to one of the at least one data node based on the lock application message received from at least one data node.
[0029] The locking module is configured to successfully lock within the distributed cluster if it receives a lock confirmation message from at least a preset proportion of lock service nodes within the lock service cluster; otherwise, it fails to lock within the distributed cluster if it does not receive a lock confirmation message from at least a preset proportion of lock service nodes within the lock service cluster.
[0030] According to a fourth aspect of one or more embodiments of this specification, a distributed lock management device is provided, applied to any lock service node in a lock service cluster, the device comprising:
[0031] The receiving module is used to receive lock request messages sent by at least one data node in the distributed cluster;
[0032] The voting module is used to send a lock confirmation message to one of the at least one data node based on the lock request message received from at least one data node.
[0033] If a data node receives a lock confirmation message from at least a preset proportion of lock service nodes within the lock service cluster, the locking process is successful within the distributed cluster. If the data node does not receive a lock confirmation message from at least a preset proportion of lock service nodes within the lock service cluster, the locking process fails within the distributed cluster.
[0034] According to a fifth aspect of one or more embodiments of this specification, a lock service cluster is provided, the lock service cluster comprising a plurality of lock service nodes;
[0035] The lock service node is configured to send a lock confirmation message to one of the at least one data node based on a lock request message received from at least one data node.
[0036] According to a sixth aspect of one or more embodiments of this specification, a distributed cluster is provided, the distributed cluster comprising a plurality of data nodes, the data nodes being used for:
[0037] Send a lock request message to each lock service node in the lock service cluster.
[0038] If a lock confirmation message is received from lock service nodes in the lock service cluster at a rate not less than a preset proportion, then the locking is successful in the distributed cluster.
[0039] If no lock confirmation message is received from at least a preset proportion of lock service nodes within the lock service cluster, locking will fail within the distributed cluster.
[0040] According to a seventh aspect of one or more embodiments of this specification, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the method described in the first or second aspect.
[0041] According to an eighth aspect of one or more embodiments of this specification, an electronic device is provided, comprising:
[0042] processor;
[0043] Memory used to store processor-executable instructions;
[0044] The processor implements the method as described in the first or second aspect by running the executable instructions.
[0045] According to a ninth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in the first or second aspect.
[0046] The technical solutions provided in the embodiments of this specification may include the following beneficial effects:
[0047] The distributed lock management method provided in this specification allows each data node in the distributed cluster to send a lock request message to each lock service node in the lock service cluster. Upon receiving lock confirmation messages from at least a preset proportion of lock service nodes in the lock service cluster, the lock is successfully acquired. Compared to related technologies where the master node in the lock service cluster manages the distributed lock, this method ensures that each lock service node in the lock service cluster participates in the management of the distributed lock within the distributed cluster. Furthermore, as long as a certain proportion of lock service nodes are in normal condition, normal distributed lock management can be maintained, improving the stability of distributed lock management and avoiding the technical problem of distributed lock management being affected by the master node's state. Attached Figure Description
[0048] Figure 1 This is a schematic diagram of a distributed cluster provided in an exemplary embodiment.
[0049] Figure 2 This is a flowchart of a distributed lock management method applied to any data node, provided in an exemplary embodiment.
[0050] Figure 3 This is a schematic diagram of the renewal of a distributed lock provided in an exemplary embodiment.
[0051] Figure 4 This is a schematic diagram of the transfer of a distributed lock provided in an exemplary embodiment.
[0052] Figure 5This is a flowchart of a distributed lock management method applied to any lock service node, provided in an exemplary embodiment.
[0053] Figure 6 This is a schematic diagram of the structure of a device provided in an exemplary embodiment.
[0054] Figure 7 This is a block diagram of a distributed lock management device applied to any data node, provided in an exemplary embodiment.
[0055] Figure 8 This is a block diagram of a distributed lock management device applied to any data node, provided in an exemplary embodiment. Detailed Implementation
[0056] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.
[0057] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.
[0058] First, some of the concepts involved in this instruction manual will be explained.
[0059] Distributed locks: A distributed lock is a mechanism that provides highly reliable lock services in a distributed manner. It ensures that a single applicant has exclusive access to the lock service, so as to avoid anomalies caused by multiple users using or modifying certain resources at the same time.
[0060] Primary replica: In a distributed system, a single data shard typically contains multiple replicas, of which only one replica provides modification services for that shard, and is called the primary replica.
[0061] Lease: The validity period of a lock for the holder, including the start time and duration (or end time).
[0062] Based on the aforementioned technical problems in the background art, at least one embodiment of this specification provides a distributed lock management method. This method enables each lock service node in the lock service cluster to participate in the distributed lock management of the distributed cluster, thereby improving the stability of distributed lock management and avoiding the problem of poor stability caused by the influence of the master node in the lock service cluster in related technologies.
[0063] The purpose of this method is to manage distributed locks within a distributed cluster. A distributed cluster consists of multiple data nodes. For example, please refer to the appendix. Figure 1 The distributed cluster comprises two data nodes: a first database and a second database. The database that successfully acquires a lock within the distributed cluster becomes the primary database, while the database that fails to acquire a lock becomes the backup database. It should be understood that the first and second databases can be single-machine databases or a database cluster (see appendix). Figure 1 Both the first and second databases in the database (which are database clusters) can be located in different geographical locations, such as different provinces, thereby improving the security of data backup. For example, the distributed cluster includes multiple replicas (each replica is a data node), where the replica that successfully acquires a lock within the distributed cluster acquires the primary replica role, and the replica that fails to acquire a lock acquires the ordinary replica role. It should be understood that multiple replicas can be multiple replicas of a specific data shard, for example, a shard in the aforementioned... Figure 1 If each database instance of the first database in the cluster has a replica, then these replicas form a distributed cluster.
[0064] This method is based on a lock service cluster to perform distributed lock management on a distributed cluster. The lock service cluster can include multiple lock service nodes. The lock service cluster can perform distributed lock management on different distributed clusters simultaneously.
[0065] The method will now be described in detail from the perspectives of data nodes within a distributed cluster and lock service nodes within a lock service cluster.
[0066] Please refer to the appendix. Figure 2 The example illustrates the process of a distributed lock management method applied to any data node in a distributed cluster, including steps S201 to S202.
[0067] In step S201, a lock request message is sent to each lock service node in the lock service cluster, wherein the lock service node is used to send a lock confirmation message to one of the at least one data node after receiving a lock request message sent by at least one data node.
[0068] For example, a lock request message can be sent to each lock service node in the lock service cluster in the following manner: the lock request message is sent to one lock service node in the lock service cluster so that the lock service node that receives the lock request message forwards the lock request message to each of the remaining lock service nodes; or, the lock request message is sent to each lock service node in the lock service cluster.
[0069] For example, the lock request message includes the node identifier and priority of the data node; for instance, each data node in the distributed cluster is pre-assigned a priority, such as according to geographical location. The lock service node is used to send a lock confirmation message to the data node with the highest priority among the at least one data node after receiving a lock request message from at least one data node.
[0070] This example allows the highest-priority data node to hold the distributed lock, which not only makes distributed lock management more orderly but also improves the data service quality of the distributed cluster by enabling the highest-priority data node to provide write services. For instance, if the data nodes in the main data center have the highest priority and the data nodes in the backup data center have the lowest priority, the main data center can provide better data service performance by leveraging its advantages in various aspects.
[0071] In step S202, if a lock confirmation message is received from at least a preset proportion of lock service nodes within the lock service cluster, the locking in the distributed cluster is successful; otherwise, the locking in the distributed cluster fails.
[0072] The preset ratio can be 50% or the same.
[0073] For example, if the distributed cluster includes a first database and a second database, then the database that successfully acquires a lock within the distributed cluster acquires the identity of the primary database, and the database that fails to acquire a lock within the distributed cluster acquires the identity of the backup database.
[0074] For example, if the distributed cluster includes multiple replicas, the replica that successfully acquires a lock in the distributed cluster obtains the primary replica role, and the replica that fails to acquire a lock in the distributed cluster obtains the ordinary replica role.
[0075] The distributed lock management method provided in this specification allows each data node in the distributed cluster to send a lock request message to each lock service node in the lock service cluster. Upon receiving lock confirmation messages from at least a preset proportion of lock service nodes in the lock service cluster, the lock is successfully acquired. Compared to related technologies where the master node in the lock service cluster manages the distributed lock, this method ensures that each lock service node in the lock service cluster participates in the management of the distributed lock within the distributed cluster. Furthermore, as long as a certain proportion of lock service nodes are in normal condition, normal distributed lock management can be maintained, improving the stability of distributed lock management and avoiding the technical problem of distributed lock management being affected by the master node's state.
[0076] It should be understood that when a distributed cluster first requests a distributed lock, the lock service node may wait for a certain period of time to receive all lock request messages issued within the distributed cluster, and then randomly or according to priority select the data node to which the lock request message belongs to send a lock confirmation message. For example, a distributed cluster consisting of the first database and the second database may request a distributed lock for the first time during system initialization or when the system as a whole recovers from a failure.
[0077] Distributed locks can have leases, meaning that each distributed lock has an expiration date, which can prevent distributed cluster failures and downtime caused by the failure of the partition node holding the distributed lock.
[0078] Based on the lease design of distributed locks, in some embodiments of this disclosure, the above objectives can be achieved by periodic detection, that is, periodically detecting whether the data node holding the distributed lock in the distributed cluster is in a normal state, and promptly transferring the distributed lock to other data nodes when the data node holding the distributed lock is in an abnormal state, so as to ensure the performance stability of the distributed cluster.
[0079] In this embodiment, step S201 can be executed as follows: if the time elapsed since the last lock request message was sent is a first time elapsed, then a lock request message is sent to each lock service node in the lock service cluster. That is, lock request messages are periodically sent to each lock service node in the lock service cluster at intervals of the first time elapsed.
[0080] Furthermore, when the distributed cluster first requests a distributed lock, the lock service node can wait for twice the first time to receive all lock request messages issued within the distributed cluster, and then randomly or according to priority select the data node to which the lock request message belongs to send a lock confirmation message.
[0081] In this embodiment, the lock request message may include the node identifier and priority of the data node; the lock service node is used to update the recorded lock request messages of the same data node after receiving the lock request message, or based on the received lock request messages; the lock service node is used to delete lock request messages in the recorded lock request messages that have not been updated for a second duration, where the second duration is longer than the first duration. That is, the lock service node can record the lock request message sent by a data node after receiving it. If it receives another lock request message from the same data node within the second duration, it replaces the previously recorded lock request message with the newly received lock request message (in fact, if the content of the two request messages is the same, the timer result of the recorded lock request message can be directly reset to zero); if it does not receive another lock request message from the same data node within the second duration, it deletes the recorded lock request message.
[0082] Furthermore, if the lock service node receives a lock request message from the incumbent node before the lease of the incumbent node expires, it can send a lock confirmation message to the incumbent node, wherein the incumbent node is the data node currently holding the lock, and the lease duration is longer than the first duration.
[0083] Furthermore, the lock service node is configured to send a lock confirmation message to the data node corresponding to the highest priority lock request message in the recorded lock request messages if it does not receive a lock request message from the incumbent node before the lease of the incumbent node expires. The incumbent node is the data node currently holding the lock. Preferably, the lease duration is longer than the second duration.
[0084] The effects of this embodiment will now be illustrated with a more specific example.
[0085] The first duration is 5 seconds, the second duration is 6 seconds, and the lease duration is 10 seconds.
[0086] The distributed cluster consists of a first database and a second database. After the initial request for a distributed lock begins, both the first and second databases periodically send lock request messages to each lock service node in the lock service cluster at 5-second intervals. Each lock service node sends a lock confirmation message to the first database after waiting for 10 seconds, at which point the first database successfully acquires the lock and becomes the master database.
[0087] Please refer to the appendix. Figure 3 When the first database is normal, after the lease lasts for 5 seconds, the lock service node receives the lock request message sent by the first database and the lock request message sent by the second database, and then sends a lock confirmation message to the first database, thereby maintaining the first database's continuous lock holding.
[0088] Please refer to the appendix. Figure 4 When the first database malfunctions, the lock service node does not receive a lock request message from the first database after the lease lasts for 5 seconds, but it does receive a lock request message from the second database. At this time, the lock service node does not send a lock confirmation message. After the lease lasts for 6 seconds, the lock service node deletes the lock request message from the first database from the records of the lock request messages from the first database and the lock request messages from the second database. After the lease expires after 10 seconds, the lock service node sends a lock confirmation message to the second database to which the unique lock request message it recorded belongs, thereby enabling the distributed lock to be transferred from the first database to the second database in a timely manner.
[0089] This embodiment achieves the stability and security of distributed locks by setting data nodes to periodically send lock request messages, locking service nodes to record lock request messages and clean up expired lock request messages, and prioritizing voting for incumbent nodes. Stability means keeping the distributed lock in a partition node as much as possible without changing it, and security means being able to transfer the distributed lock to a normal partition node in a timely manner when the incumbent node is abnormal, thereby improving the service stability of the distributed cluster.
[0090] Please refer to the appendix. Figure 5 It exemplarily illustrates the process of a distributed lock management method applied to any lock service node within a lock service cluster, including steps S501 to S502.
[0091] In step S501, a lock request message is received from at least one data node in the distributed cluster;
[0092] In step S502, a lock confirmation message is sent to one of the at least one data node;
[0093] The data node is configured to: successfully acquire a lock in the distributed cluster if it receives a lock confirmation message from at least a preset proportion of lock service nodes within the lock service cluster; and fail to acquire a lock in the distributed cluster if it does not receive a lock confirmation message from at least a preset proportion of lock service nodes within the lock service cluster.
[0094] For example, the lock request message includes the node identifier and priority of the data node; step S502 can be performed in the following manner:
[0095] Send a lock confirmation message to the highest priority data node among the at least one data nodes.
[0096] For example, the data node periodically sends lock request messages to each lock service node in the lock service cluster at a first time interval; step S502 can be performed in the following manner:
[0097] If a lock request message is received from the in-place node before its lease expires, the in-place node sends a lock confirmation message, wherein the in-place node is the data node currently holding the lock, and the lease duration is longer than the first duration.
[0098] For example, the method further includes:
[0099] If a lock request message is received, record the received lock request message or update the recorded lock request messages for the same data node based on the received lock request message;
[0100] The lock request message for the deleted record was not updated with a lock request message whose duration has reached the second duration, wherein the second duration is longer than the first duration;
[0101] Step S502 can be performed in the following manner:
[0102] If the in-place node does not receive a lock request message from the in-place node before its lease expires, it sends a lock confirmation message to the data node corresponding to the lock request message with the highest priority among the recorded lock request messages. The in-place node is the data node currently holding the lock, and the lease duration is longer than the first duration.
[0103] Further details regarding the above steps and embodiments have been fully and thoroughly described in the method on the data node side, and will not be repeated here.
[0104] At least one embodiment of this specification also provides a lock service cluster, which includes multiple lock service nodes;
[0105] The lock service node is configured to send a lock confirmation message to one of the at least one data node after receiving a lock request message from at least one data node.
[0106] For example, the lock service node is configured to send a lock confirmation message to the highest priority data node among the at least one data node after receiving a lock request message from at least one data node.
[0107] For example, the lock request message includes the node identifier and priority of the data node;
[0108] Each data node in the distributed cluster periodically sends a lock request message to each lock service node in the lock service cluster at a first time interval.
[0109] The lock service node is used to update the record of the received lock request message after receiving the lock request message, or to update the record of the lock request message of the same data node based on the received lock request message;
[0110] The lock service node is used to delete lock request messages in the recorded lock request messages that have not been updated for a duration of a second duration, where the second duration is longer than the first duration;
[0111] The lock service node is configured to send a lock confirmation message to the incumbent node if it receives a lock request message from the incumbent node before the lease of the incumbent node expires, and to send a lock confirmation message to the data node corresponding to the lock request message with the highest priority among the recorded lock request messages if it does not receive a lock request message from the incumbent node before the lease of the incumbent node expires. The incumbent node is the data node currently holding the lock, and the duration of the lease is longer than the first duration.
[0112] Further details regarding the above embodiments have been fully and thoroughly described in the method on the data node side, and will not be repeated here.
[0113] At least one embodiment of this specification also provides a distributed cluster, the distributed cluster comprising multiple data nodes, the data nodes being used for:
[0114] Send a lock request message to each lock service node in the lock service cluster.
[0115] If a lock confirmation message is received from lock service nodes in the lock service cluster at a rate not less than a preset proportion, then the locking is successful in the distributed cluster.
[0116] If no lock confirmation message is received from at least a preset proportion of lock service nodes within the lock service cluster, locking will fail within the distributed cluster.
[0117] For example, the data node is used to periodically send lock request messages to each lock service node in the lock service cluster at a first time interval.
[0118] Further details regarding the above embodiments have been fully and thoroughly described in the method on the data node side, and will not be repeated here.
[0119] Figure 6 This is a schematic structural diagram of a device provided in an exemplary embodiment. Please refer to... Figure 6At the hardware level, the device includes a processor 602, an internal bus 604, a network interface 606, memory 608, and non-volatile memory 610, and may also include other hardware required for tasks. One or more embodiments of this specification can be implemented in software, such as the processor 602 reading the corresponding computer program from the non-volatile memory 610 into memory 608 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.
[0120] Please refer to Figure 7 Distributed lock management devices can be applied to, for example, Figure 6 The data node running on the device shown is used to implement the technical solution described in this specification. This data node is any partition node within a distributed cluster, and the management device for the distributed lock may include:
[0121] The application module 701 is used to send a lock application message to each lock service node in the lock service cluster, wherein the lock service node is used to send a lock confirmation message to one of the at least one data node after receiving a lock application message sent by at least one data node.
[0122] The locking module 702 is configured to successfully lock within the distributed cluster if it receives a lock confirmation message from at least a preset proportion of lock service nodes within the lock service cluster; otherwise, it fails to lock within the distributed cluster if it does not receive a lock confirmation message from at least a preset proportion of lock service nodes within the lock service cluster.
[0123] In one possible embodiment of this specification, the lock request message includes the node identifier and priority of the data node;
[0124] The lock service node is used to send a lock confirmation message to the highest priority data node among the at least one data node after receiving a lock request message from at least one data node.
[0125] In one possible embodiment of this specification, the application module is used for:
[0126] If the current time is the first time elapsed since the last time a lock request message was sent, then a lock request message is sent to each lock service node in the lock service cluster.
[0127] In one possible embodiment of this specification, the lock service node is configured to send a lock confirmation message to the incumbent node if it receives a lock request message from the incumbent node before the lease of the incumbent node expires, wherein the incumbent node is the data node currently holding the lock, and the lease duration is longer than the first duration.
[0128] In one possible embodiment of this specification, the lock request message includes the node identifier and priority of the data node;
[0129] The lock service node is used to update the record of the received lock request message after receiving the lock request message, or to update the record of the lock request message of the same data node based on the received lock request message;
[0130] The lock service node is used to delete lock request messages in the recorded lock request messages that have not been updated for a duration of a second duration, where the second duration is longer than the first duration;
[0131] The lock service node is used to send a lock confirmation message to the data node corresponding to the highest priority lock request message in the recorded lock request messages if it does not receive a lock request message from the incumbent node before the lease of the incumbent node expires. The incumbent node is the data node currently holding the lock, and the lease duration is longer than the first duration.
[0132] In one possible embodiment of this specification, the distributed cluster includes a first database and a second database, wherein the database that successfully acquires a lock within the distributed cluster acquires the identity of the primary database, and the database that fails to acquire a lock within the distributed cluster acquires the identity of the backup database; or...
[0133] The distributed cluster includes multiple replicas, wherein the replica that successfully acquires a lock within the distributed cluster acquires the role of the primary replica, and the replica that fails to acquire a lock within the distributed cluster acquires the role of a regular replica.
[0134] In one possible embodiment of this specification, the application module is used for:
[0135] The lock request message is sent to one lock service node in the lock service cluster, so that the lock service node receiving the lock request message forwards the lock request message to each of the remaining lock service nodes; or...
[0136] Send the lock request message to each lock service node in the lock service cluster.
[0137] Please refer to Figure 8 Distributed lock management devices can be applied to, for example, Figure 6The device shown operates a lock service node to implement the technical solution described in this specification. This lock service node can be any lock service node within a lock service cluster, and the management device for this distributed lock may include:
[0138] The receiving module 801 is used to receive lock request messages sent by at least one data node in the distributed cluster;
[0139] Voting module 802 is used to send a lock confirmation message to one of the at least one data nodes;
[0140] If a data node receives a lock confirmation message from at least a preset proportion of lock service nodes within the lock service cluster, the locking process is successful within the distributed cluster. If the data node does not receive a lock confirmation message from at least a preset proportion of lock service nodes within the lock service cluster, the locking process fails within the distributed cluster.
[0141] In one possible embodiment of this specification, the lock request message includes the node identifier and priority of the data node;
[0142] The voting module is used for:
[0143] Send a lock confirmation message to the highest priority data node among the at least one data nodes.
[0144] In one possible embodiment of this specification, the data node periodically sends lock request messages to each lock service node in the lock service cluster at a first time interval;
[0145] The voting module is used for:
[0146] If a lock request message is received from the in-place node before its lease expires, the in-place node sends a lock confirmation message, wherein the in-place node is the data node currently holding the lock, and the lease duration is longer than the first duration.
[0147] In one possible embodiment of this specification, the apparatus further includes a message management module for:
[0148] If a lock request message is received, record the received lock request message or update the recorded lock request messages for the same data node based on the received lock request message;
[0149] The lock request message for the deleted record was not updated with a lock request message whose duration has reached the second duration, wherein the second duration is longer than the first duration;
[0150] The voting module is used for:
[0151] If the in-place node does not receive a lock request message from the in-place node before its lease expires, it sends a lock confirmation message to the data node corresponding to the lock request message with the highest priority among the recorded lock request messages. The in-place node is the data node currently holding the lock, and the lease duration is longer than the first duration.
[0152] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.
[0153] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0154] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.
[0155] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.
[0156] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0157] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.
[0158] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this specification. The singular forms “a,” “described,” and “the” used in one or more embodiments of this specification and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items.
[0159] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals shall be provided for users to choose to authorize or refuse.
[0160] It should be understood that although the terms first, second, third, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of one or more embodiments of this specification, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "in response to a determination," or "when," or "in the event of a determination."
[0161] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the protection scope of one or more embodiments of this specification.
Claims
1. A method for managing a distributed lock, applied to any data node in a distributed cluster, the distributed cluster comprising multiple data nodes, the method comprising: Send a lock request message to each lock service node in the lock service cluster, wherein the lock request message includes the node identifier and priority of the data node, and the lock service node is used to send a lock confirmation message to the data node with the highest priority among the at least one data node according to the lock request message sent by the at least one data node. If a lock confirmation message is received from at least a preset proportion of lock service nodes within the lock service cluster, the locking in the distributed cluster is successful; otherwise, the locking in the distributed cluster fails. When the data node is a database, the database that successfully acquires the lock within the distributed cluster becomes the primary database, and the database that fails to acquire the lock within the distributed cluster becomes the backup database; or... When the data node is a replica, the replica that successfully acquires a lock within the distributed cluster acquires the primary replica role, and the replica that fails to acquire a lock within the distributed cluster acquires the ordinary replica role.
2. The distributed lock management method according to claim 1, wherein sending a lock request message to each lock service node in the lock service cluster includes: If the current time is the first time elapsed since the last time a lock request message was sent, then a lock request message is sent to each lock service node in the lock service cluster.
3. The distributed lock management method according to claim 2, wherein the lock service node is configured to send a lock confirmation message to the incumbent node when it receives a lock request message from the incumbent node before the lease of the incumbent node expires, wherein, The in-place node is the data node currently holding the lock, and the lease duration is longer than the first duration.
4. The distributed lock management method according to claim 2; The lock service node is used to update the record of the received lock request message after receiving the lock request message, or to update the record of the lock request message of the same data node based on the received lock request message; The lock service node is used to delete lock request messages in the recorded lock request messages that have not been updated for a duration of a second duration, where the second duration is longer than the first duration; The lock service node is used to send a lock confirmation message to the data node corresponding to the highest priority lock request message in the recorded lock request messages if it has not received a lock request message from the incumbent node before the lease of the incumbent node expires. The in-place node is the data node currently holding the lock, and the lease duration is longer than the first duration.
5. The distributed lock management method according to claim 1, wherein sending a lock request message to each lock service node in the lock service cluster includes: The lock request message is sent to one lock service node in the lock service cluster, so that the lock service node receiving the lock request message forwards the lock request message to each of the remaining lock service nodes; or... Send the lock request message to each lock service node in the lock service cluster.
6. A distributed lock management method, applied to any lock service node in a lock service cluster, the method comprising: Receive a lock request message sent by at least one data node in a distributed cluster, wherein the distributed cluster includes multiple data nodes, and the lock request message includes the node identifier and priority of the data node; Based on the lock request message received from at least one data node, a lock confirmation message is sent to the data node with the highest priority among the at least one data nodes; The data node is configured to: successfully acquire a lock in the distributed cluster if it receives a lock confirmation message from at least a preset proportion of lock service nodes in the lock service cluster; and fail to acquire a lock in the distributed cluster if it does not receive a lock confirmation message from at least a preset proportion of lock service nodes in the lock service cluster. When the data node is a database, the database that successfully acquires the lock within the distributed cluster becomes the primary database, and the database that fails to acquire the lock within the distributed cluster becomes the backup database; or... When the data node is a replica, the replica that successfully acquires a lock within the distributed cluster acquires the primary replica role, and the replica that fails to acquire a lock within the distributed cluster acquires the ordinary replica role.
7. The distributed lock management method according to claim 6, wherein the data node periodically sends lock request messages to each lock service node of the lock service cluster at a first time interval; Sending a lock confirmation message to one of the at least one data node includes: If a lock request message is received from the in-place node before its lease expires, the in-place node sends a lock confirmation message, wherein the in-place node is the data node currently holding the lock, and the lease duration is longer than the first duration.
8. The distributed lock management method according to claim 7, further comprising: If a lock request message is received, record the received lock request message or update the recorded lock request messages for the same data node based on the received lock request message; The lock request message for the deleted record was not updated with a lock request message whose duration has reached the second duration, wherein the second duration is longer than the first duration; Sending a lock confirmation message to one of the at least one data node includes: If the in-place node does not receive a lock request message from the in-place node before its lease expires, it sends a lock confirmation message to the data node corresponding to the lock request message with the highest priority among the recorded lock request messages. The in-place node is the data node currently holding the lock, and the lease duration is longer than the first duration.
9. A distributed lock management device, applied to any data node of a distributed cluster, the distributed cluster comprising multiple data nodes, the device comprising: The application module is used to send a lock application message to each lock service node in the lock service cluster. The lock application message includes the node identifier and priority of the data node. The lock service node is used to send a lock confirmation message to the data node with the highest priority among the at least one data node based on the lock application message received from the at least one data node. The locking module is used to successfully lock in the distributed cluster if it receives a lock confirmation message from lock service nodes in the lock service cluster at a rate not less than a preset proportion, and to fail to lock in the distributed cluster if it does not receive a lock confirmation message from lock service nodes in the lock service cluster at a rate not less than a preset proportion. When the data node is a database, the database that successfully acquires the lock within the distributed cluster becomes the primary database, and the database that fails to acquire the lock within the distributed cluster becomes the backup database; or... When the data node is a replica, the replica that successfully acquires a lock within the distributed cluster acquires the primary replica role, and the replica that fails to acquire a lock within the distributed cluster acquires the ordinary replica role.
10. A distributed lock management device, applied to any lock service node in a lock service cluster, the device comprising: A receiving module is configured to receive a lock request message sent by at least one data node in a distributed cluster, wherein the distributed cluster includes multiple data nodes, and the lock request message includes the node identifier and priority of the data node. The voting module is used to send a lock confirmation message to the highest priority data node among the at least one data node based on the lock request message received from at least one data node. If a data node receives a lock confirmation message from a lock service node in the lock service cluster at a rate not less than a preset proportion, the locking in the distributed cluster is successful; if it does not receive a lock confirmation message from a lock service node in the lock service cluster at a rate not less than a preset proportion, the locking in the distributed cluster fails. When the data node is a database, the database that successfully acquires the lock within the distributed cluster becomes the primary database, and the database that fails to acquire the lock within the distributed cluster becomes the backup database; or... When the data node is a replica, the replica that successfully acquires a lock within the distributed cluster acquires the primary replica role, and the replica that fails to acquire a lock within the distributed cluster acquires the ordinary replica role.
11. The distributed lock management device according to claim 10, wherein the data node periodically sends lock request messages to each lock service node of the lock service cluster at a first time interval; The voting module is used for: If the incumbent node receives a lock request message from the incumbent node before its lease expires, the incumbent node sends a lock confirmation message, wherein... The in-place node is the data node currently holding the lock, and the lease duration is longer than the first duration.
12. The distributed lock management device according to claim 11, the device further comprising a message management module, used for: If a lock request message is received, record the received lock request message or update the recorded lock request messages for the same data node based on the received lock request message; The lock request messages for deleting records were not updated with lock request messages that had reached the second duration. The second duration is longer than the first duration; The voting module is used for: If the in-place node does not receive a lock request message from the in-place node before its lease expires, it sends a lock confirmation message to the data node corresponding to the lock request message with the highest priority among the recorded lock request messages. The in-place node is the data node currently holding the lock, and the lease duration is longer than the first duration.
13. A lock service cluster, the lock service cluster comprising multiple lock service nodes; in, The lock service node is used to send a lock confirmation message to the highest priority data node among the at least one data nodes, based on the lock request message received from at least one data node. The data node is a data node in a distributed cluster, and the distributed cluster includes multiple data nodes; When the data node is a database, the database that successfully acquires the lock within the distributed cluster becomes the primary database, and the database that fails to acquire the lock within the distributed cluster becomes the backup database; or... When the data node is a replica, the replica that successfully acquires a lock within the distributed cluster acquires the primary replica role, and the replica that fails to acquire a lock within the distributed cluster acquires the ordinary replica role.
14. The lock service cluster according to claim 13, Each data node in the distributed cluster periodically sends lock request messages to each lock service node in the lock service cluster at a first time interval; The lock service node is used to update the record of the received lock request message after receiving the lock request message, or to update the record of the lock request message of the same data node based on the received lock request message; The lock service node is used to delete lock request messages in the recorded lock request messages that have not been updated for a duration of a second duration, where the second duration is longer than the first duration; The lock service node is configured to send a lock confirmation message to the incumbent node if it receives a lock request message from the incumbent node before the incumbent node's lease expires; and to send a lock confirmation message to the data node corresponding to the highest priority lock request message in the recorded lock request messages if it does not receive a lock request message from the incumbent node before the incumbent node's lease expires. The in-place node is the data node currently holding the lock, and the lease duration is longer than the first duration.
15. A distributed cluster, the distributed cluster comprising multiple data nodes, the data nodes being used for: Send a lock request message to each lock service node in the lock service cluster. If a lock confirmation message is received from lock service nodes within the lock service cluster at a rate not less than a preset proportion, then the locking is successful within the distributed cluster. If no lock confirmation message is received from lock service nodes in the lock service cluster at a rate not less than a preset proportion, locking will fail in the distributed cluster. When the data node is a database, the database that successfully acquires the lock within the distributed cluster becomes the primary database, and the database that fails to acquire the lock within the distributed cluster becomes the backup database; or... When the data node is a replica, the replica that successfully acquires a lock within the distributed cluster acquires the primary replica role, and the replica that fails to acquire a lock within the distributed cluster acquires the ordinary replica role.
16. The distributed cluster according to claim 15, wherein the data node is configured to periodically send lock request messages to each lock service node of the lock service cluster at a first time interval.
17. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 8.
18. An electronic device comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1 to 8 by executing the executable instructions.
19. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1 to 8.