Distributed lock management method and apparatus

Abstract

Provided in the present description are a distributed lock management method and an apparatus. The method is applied to any target replica node in a database corresponding to a target lock, and comprises: sending lock request information to a distributed lock service, so that any target lock service node of the distributed lock service obtains the lock request information, and when it is determined that the target replica node can obtain the target lock, sending lock confirmation information to the target replica node; if lock confirmation information sent by lock service nodes accounting for a proportion of the total number of lock service nodes in the distributed lock service that is not less than a preset proportion threshold is obtained, determining that the target replica node obtains the target lock; and if lock confirmation information sent by lock service nodes accounting for a proportion of the total number of the lock service nodes in the distributed lock service that is not less than the preset proportion threshold is not obtained, determining that the target replica node does not obtain the target lock.

Description

Distributed lock management methods and devices Technical Field

[0001] This specification relates to one or more embodiments in the field of database technology, and more particularly to a method and apparatus for managing distributed locks. Background Technology

[0002] In database systems, distributed architectures are widely used to meet the requirements of high availability, scalability, and fault tolerance. A typical distributed database system horizontally shards data and distributes it across multiple physical nodes. These nodes collaborate via a network to provide a unified data service. In such systems, each data shard typically maintains multiple replicas to ensure data redundancy and service continuity. For each shard, the system designates one replica as the primary / leader, responsible for handling client read and write requests and synchronizing data changes to the other secondary / follower replicas.

[0003] The master-slave replication architecture is also a high-availability solution, typically used in centralized database systems (single-machine database systems). In this type of database system, multiple database instances are included and data is synchronized, but all database instances store the full amount of data. The master database handles read and write requests and asynchronously or semi-synchronously replicates data changes to one or more slave databases; the slave databases generally do not accept user writes and are only used for failover or to distribute read load.

[0004] In the aforementioned high-availability database systems, to ensure that only one node has write access to the same data unit (such as a data shard or a database instance) at any given time, a coordination mechanism is typically introduced to manage the role status of each node, such as a locking mechanism. A locking mechanism involves candidate replicas or candidate database instances competing to acquire a mutex lock associated with a specific data unit; the successful acquirer is designated as the primary replica or primary database. A distributed locking mechanism, on the other hand, is a mechanism that provides highly reliable locking services in a distributed manner.

[0005] In related technologies, clusters used to provide distributed lock services typically operate in a master-slave mode—that is, a master node is elected from among multiple lock service nodes within the cluster, and the master node centrally handles all lock acquisition, renewal, and release operations. However, this approach is highly dependent on the stability and performance of the master node of the distributed lock service. Once the master node experiences performance fluctuations or crashes due to network partitions, resource overload, or hardware failures, it will lead to delays, failures, or inconsistencies in the allocation of distributed locks, which in turn will cause confusion in data shard replicas or database instance roles (such as abnormal states like multi-master writes or no-master writes), severely affecting the service availability, data consistency, and overall performance of the database system. Summary of the Invention

[0006] 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.

[0007] To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions:

[0008] 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 target replica node of a database corresponding to a target lock, the method comprising:

[0009] Send lock request information to the distributed lock service so that any target lock service node of the distributed lock service can obtain the lock request information, and if it is determined that the target replica node can obtain the target lock, send lock confirmation information to the target replica node;

[0010] If a lock confirmation message is received from a lock service node whose proportion of the total number of lock service nodes in the distributed lock service is not less than a preset proportion threshold, then the target replica node is determined to have obtained the target lock.

[0011] If no lock confirmation information is received from a lock service node whose proportion of the total number of lock service nodes in the distributed lock service is not less than a preset threshold, then it is determined that the target replica node has not acquired the target lock.

[0012] 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 target lock service node of a distributed lock service, the method comprising:

[0013] Retrieve the lock request message sent by any target replica node corresponding to the target lock from the database;

[0014] Determine whether the target replica node can acquire the target lock;

[0015] If it is determined that the target replica node can acquire the target lock, a lock confirmation message is sent to the target replica node. This ensures that if the target replica node receives lock confirmation messages from lock service nodes whose proportion of the total number of lock service nodes in the distributed lock service is not less than a preset threshold, the target replica node is determined to have acquired the target lock. Conversely, if it does not receive lock confirmation messages from lock service nodes whose proportion of the total number of lock service nodes in the distributed lock service is not less than the preset threshold, the target replica node is determined to have not acquired the target lock.

[0016] According to a third aspect of one or more embodiments of this specification, a distributed lock management device is provided, applied to any target replica node of a database corresponding to a target lock, the device comprising:

[0017] The application module is used to send lock application information to the distributed lock service so that any target lock service node of the distributed lock service can obtain the lock application information, and send lock confirmation information to the target replica node if it is determined that the target replica node can obtain the target lock.

[0018] The locking module is configured to determine that the target replica node has acquired the target lock if it receives lock confirmation information from a lock service node whose proportion of the total number of lock service nodes in the distributed lock service is not less than a preset threshold; otherwise, it determines that the target replica node has not acquired the target lock if it does not receive lock confirmation information from a lock service node whose proportion of the total number of lock service nodes in the distributed lock service is not less than a preset threshold.

[0019] According to a fourth aspect of one or more embodiments of this specification, a distributed lock management device is provided, applied to any target lock service node of a distributed lock service, the device comprising:

[0020] The acquisition module is used to acquire lock request messages sent by any target replica node corresponding to the target lock in the database;

[0021] The voting module is used to determine whether the target replica node can acquire the target lock. If it is determined that the target replica node can acquire the target lock, a lock confirmation message is sent to the target replica node. This ensures that if the target replica node receives lock confirmation messages from lock service nodes whose proportion of the total number of lock service nodes in the distributed lock service is not less than a preset threshold, the target replica node acquires the target lock. If it does not receive lock confirmation messages from lock service nodes whose proportion of the total number of lock service nodes in the distributed lock service is not less than the preset threshold, the target replica node does not acquire the target lock.

[0022] According to a fifth 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.

[0023] According to a sixth aspect of one or more embodiments of this specification, an electronic device is provided, comprising:

[0024] processor;

[0025] Memory used to store processor-executable instructions;

[0026] The processor implements the method as described in the first or second aspect by running the executable instructions.

[0027] According to a seventh 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.

[0028] Any target replica node in the database corresponding to the target lock can send a lock request to the distributed lock service that manages the target lock. This allows any target lock service node of the distributed lock service to obtain the lock request and, if it is determined that the target replica node can acquire the target lock, send a lock confirmation message to the target replica node. Furthermore, if the target replica node receives lock confirmation messages from lock service nodes that represent a proportion of at least a certain threshold of the total number of lock service nodes in the distributed lock service, it determines that the target replica node has acquired the target lock. If it does not receive lock confirmation messages from lock service nodes that represent a proportion of at least that threshold of the total number of lock service nodes in the distributed lock service, it determines that the target replica node has not acquired the target lock.

[0029] Using the above method, it is no longer necessary for the master node in the distributed lock service to manage the distributed lock. Instead, each lock service node in the distributed lock service can participate in the management of the distributed lock within the distributed cluster. As long as a certain proportion of the lock service nodes are in normal condition, the normal management of the distributed lock can be maintained, which improves the stability of distributed lock management and avoids the problem of poor stability caused by the master node in the distributed lock service running in master-slave mode. Attached Figure Description

[0030] Figure 1 is a flowchart of a distributed lock management method applied to any data node, provided by an exemplary embodiment.

[0031] Figure 2 is a schematic diagram of the renewal of a distributed lock provided in an exemplary embodiment.

[0032] Figure 3 is a schematic diagram of the transfer of a distributed lock provided in an exemplary embodiment.

[0033] Figure 4 is a flowchart of a distributed lock management method applied to any lock service node, provided by an exemplary embodiment.

[0034] Figure 5 is a schematic diagram of the structure of a device provided in an exemplary embodiment.

[0035] Figure 6 is a block diagram of a distributed lock management device applied to any data node, provided in an exemplary embodiment.

[0036] Figure 7 is a block diagram of a distributed lock management device applied to any data node, provided in an exemplary embodiment. Detailed Implementation

[0037] 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.

[0038] 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.

[0039] First, some of the concepts involved in this instruction manual will be explained.

[0040] 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.

[0041] 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.

[0042] Lease: The validity period of a lock for the holder, including the start time and duration (or end time).

[0043] In related technologies, clusters used to provide distributed lock services typically operate in a master-slave mode—that is, a master node is elected from among multiple lock service nodes within the cluster, and the master node centrally handles all lock acquisition, renewal, and release operations. However, this approach is highly dependent on the stability and performance of the master node of the distributed lock service. Once the master node experiences performance fluctuations or crashes due to network partitions, resource overload, or hardware failures, it will lead to delays, failures, or inconsistencies in the allocation of distributed locks, which in turn will cause confusion in data shard replicas or database instance roles (such as abnormal states like multi-master writes or no-master writes), severely affecting the service availability, data consistency, and overall performance of the database system.

[0044] Based on the above-mentioned technical problems, at least one embodiment of this specification provides a distributed lock management method. This method enables each lock service node in the distributed lock service 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 distributed lock service running in master-slave mode.

[0045] The purpose of this method is to manage distributed locks in highly available database systems. Highly available database systems typically include distributed database systems and centralized database systems with a master-slave architecture.

[0046] Typical distributed database systems horizontally shard data and distribute it across multiple physical nodes. These nodes collaborate via a network to provide a unified data service. In such systems, each data shard typically maintains multiple replicas to ensure data redundancy and service continuity. For each shard, the system designates one replica as the primary replica, responsible for handling client read and write requests and synchronizing data changes to the remaining secondary replicas.

[0047] The master-slave architecture is also a high-availability solution, typically used in centralized database systems. In this type of system, multiple database instances are used to synchronize data, but all instances store all data. The master database handles read and write requests and asynchronously or semi-synchronously replicates data changes to one or more slave databases. The slave databases generally do not accept user writes and are only used for failover or to distribute read load.

[0048] In the aforementioned high-availability database systems, to ensure that only one node has write access to the same data unit (such as a data shard or a database instance) at any given time, a coordination mechanism is typically introduced to manage the role status of each node, such as a locking mechanism. A locking mechanism involves candidate replicas or candidate database instances competing to acquire a mutex lock associated with a specific data unit; the successful acquirer is designated as the primary replica or primary database. A distributed locking mechanism, on the other hand, is a mechanism that provides highly reliable locking services in a distributed manner.

[0049] This method performs distributed lock management for the database system based on a distributed lock service. The distributed lock service can include multiple lock service nodes. The same distributed lock service can perform distributed lock management for different database systems simultaneously.

[0050] The method will now be described in detail from the perspectives of the replica node in the database system and the lock service node in the distributed lock service. It should be noted that a replica node in this application can refer to the physical or logical node where a data shard replica resides in a distributed database system, or it can refer to the physical or logical node where a database instance resides in a centralized database system.

[0051] Please refer to Figure 1, which exemplarily illustrates the flow of a distributed lock management method applied to a database for any replica node (referred to as the target replica node) corresponding to a certain lock (referred to as the target lock), including steps S101 to S103.

[0052] For example, the database mentioned above can be a centralized database. In this case, the target lock mentioned above can be a lock corresponding to the database, and the target replica node mentioned above can be the physical node or logical node where the replica of the database (primary or standby database) is located.

[0053] Alternatively, the aforementioned database can be a distributed database. In this case, the data stored in the distributed database can be divided into at least one data shard, the aforementioned target lock can be a lock corresponding to any one of these at least one data shards (referred to as the target data shard), and the aforementioned target replica node can be the physical node or logical node where the replica (primary replica or secondary replica) of the target data shard resides.

[0054] In other words, each replica in a distributed database, or each database instance in a centralized database, can act as a lock requester and initiate a lock request to the distributed lock service. Specifically, it can send lock request information to the distributed lock service through its physical or logical node. Multiple lock requesters may initiate lock requests in parallel. For example, when the primary replica corresponding to a certain lock suddenly fails, multiple backup replicas corresponding to that lock may request the lock in order to become the primary replica.

[0055] In step S101, a lock request information is sent to the distributed lock service so that any target lock service node of the distributed lock service can obtain the lock request information. If it is determined that the target replica node can obtain the target lock, a lock confirmation information is sent to the target replica node.

[0056] In this embodiment, the target replica node can send lock request information to the distributed lock service used to manage the target lock in order to request the use of the target lock from the distributed lock service.

[0057] Accordingly, any lock service node of the aforementioned distributed lock service (referred to as the target lock service node) can obtain the lock request information sent by the target replica node. Based on the content of the lock request information sent by the target replica node, it can determine whether the target replica node can acquire the target lock. If it is determined that the target replica node can acquire the target lock, it sends lock confirmation information to the target replica node. That is, each lock service node of the distributed lock service can obtain the lock request information sent by each replica node that needs to use the target lock. Based on the content of the lock request information sent by these replica nodes, it can determine which replica node among these replica nodes can acquire the target lock, i.e., determine which replica node among these replica nodes can be assigned the target lock.

[0058] For example, the target replica node can send lock request information to the distributed lock service point in the following ways: sending the lock request information to a lock service node of the distributed lock service used for information relay, which then forwards the received lock request information to each of the remaining lock service nodes of the distributed lock service; or, sending the lock request information to each lock service node of the distributed lock service. Both methods enable each lock service node of the distributed lock service to obtain the lock request information sent by the target replica node.

[0059] Similarly, if the target lock service node needs to send lock confirmation information to the target replica node, it can send the lock confirmation information directly to the target replica node, or it can send the lock confirmation information to the lock service node used for information relay in the distributed lock service, which will then forward the received lock confirmation information to the target replica node.

[0060] For example, the lock request information sent by the target replica node may include the priority of the target replica node. This priority may correspond to the target lock, indicating whether the target replica node has priority in acquiring the target lock. In practical applications, a corresponding priority can be set for the replica node based on its location (specifically, the physical node storing the target replica node), its unique identifier, etc.; alternatively, a random number can be used to represent the priority of the replica node, so that the replica nodes acquiring the lock are randomly distributed.

[0061] The target lock service node can determine whether a target replica node can acquire the target lock based on the priority of the target replica node. For example, the target lock service node can determine whether the highest-priority replica node among the replica nodes that have sent lock request information to request the use of the target lock can acquire the target lock.

[0062] In this scenario, the highest-priority replica node can hold the distributed lock. This not only makes distributed lock management more orderly but also improves the data service quality of the database system by allowing the highest-priority replica node to provide write services. For example, if the replica node in the main data center has the highest priority, while the replica node in the backup data center has a lower priority, the distributed lock can be acquired by the replica node in the main data center, thus leveraging the advantages of the main data center to provide better data service performance.

[0063] In step S102, if a lock confirmation message is received from a lock service node whose proportion of the total number of lock service nodes in the distributed lock service is not less than a preset proportion threshold, then the target replica node is determined to have obtained the target lock.

[0064] In step S103, if no lock confirmation information is received from a lock service node whose proportion of the total number of lock service nodes in the distributed lock service is not less than a preset proportion threshold, then it is determined that the target replica node has not obtained the target lock.

[0065] The aforementioned percentage threshold can be preset to 50%, or it can be set to other percentage values ​​according to actual conditions and needs. This manual does not impose any special restrictions on this.

[0066] In this embodiment, the target replica node can determine that it has acquired the target lock if it receives lock confirmation information from a lock service node whose proportion of the total number of lock service nodes in the distributed lock service is not less than the aforementioned threshold. For example, assuming there are 5 lock service nodes in the distributed lock service, and 3 of them send lock confirmation information to the target replica node, then since 3 > 2.5 (5 * 50%), the target replica node can determine that the replica it carries corresponding to the target lock has acquired the target lock. Furthermore, the replica carried by the target replica node corresponding to the target lock can become the primary replica, responsible for handling client read and write requests and synchronizing data changes to the remaining secondary replicas.

[0067] The target replica node can determine that it has not acquired the target lock if it does not receive lock confirmation information from a lock service node whose proportion of the total number of lock service nodes in the distributed lock service is not less than the aforementioned threshold. Therefore, the target replica node can act as a slave replica node, with the current master replica node, which holds the target lock, synchronizing data changes.

[0068] The distributed lock management method provided in the embodiments of this specification allows any target replica node in the database corresponding to the target lock to send lock request information to the distributed lock service managing the target lock. This enables any target lock service node of the distributed lock service to obtain the lock request information. If it is determined that the target replica node can obtain the target lock, lock confirmation information is sent to the target replica node. Furthermore, if the target replica node obtains lock confirmation information from lock service nodes that constitute a proportion of the total number of lock service nodes in the distributed lock service not less than a specific threshold, it determines that the target replica node has obtained the target lock. If it does not obtain lock confirmation information from lock service nodes that constitute a proportion of the total number of lock service nodes in the distributed lock service not less than the threshold, it determines that the target replica node has not obtained the target lock.

[0069] Using the above method, it is no longer necessary for the master node in the distributed lock service to manage the distributed lock. Instead, each lock service node in the distributed lock service can participate in the management of the distributed lock within the distributed cluster. As long as a certain proportion of the lock service nodes are in normal condition, the normal management of the distributed lock can be maintained, which improves the stability of distributed lock management and avoids the problem of poor stability caused by the master node in the distributed lock service running in master-slave mode.

[0070] In one possible embodiment of this specification, in order to avoid lock request failure due to abnormal data transmission, the target replica node may periodically send lock request messages to the distributed lock service at preset time intervals.

[0071] Accordingly, the distributed lock service can wait for a certain period of time to receive lock request information sent by multiple replica nodes that need to apply for the target lock, and then randomly or according to the priority of the replica nodes to determine the replica node that can obtain the target lock, and send lock confirmation information to the determined replica node that can obtain the target lock.

[0072] Locks assigned to replicas or database instances can have corresponding leases, which indicate the lock's validity period. For a replica or database instance, if its lock lease has not expired, the lock is valid, and the replica or database instance can continue to act as the primary replica or primary database. If its lock lease has expired, the lock is invalid, and the replica or database instance will no longer act as the primary replica or primary database; instead, it needs to re-acquire the lock. This can, to some extent, prevent database system failures and downtime caused by the failure of the replica node holding the lock.

[0073] For example, the target lock service node can determine that the target replica node can obtain the target lock if the target replica node holds the target lock and the lease of the target lock has not expired.

[0074] For example, the lock request information sent by the target replica node may include the priority of the target replica node.

[0075] In this scenario, the target lock service node can record the lock request information sent by the target replica node. Specifically, when the target lock service node first receives the lock request information sent by the target replica node, it can store the received lock request information. Subsequently, when the target lock service node receives the lock request information sent by the target replica node again, it can update the stored lock request information with the received lock request information (if the lock request information received in the two instances is the same, the validity period of the recorded lock request information can be directly reset to zero).

[0076] It should be noted that, to avoid duplicate processing of lock request information, a validity period can be set for the lock request information. Specifically, the lock request information of the target replica node recorded by the target lock service node can be determined to be invalid if the duration for which the target lock service node has not received the lock request information sent by the target replica node exceeds a preset duration threshold (i.e., the validity period of the lock request information). Furthermore, after sending lock confirmation information to a replica node, the target lock service node can also determine that the recorded lock request information of that replica node is invalid. In practical applications, when the target lock service node determines that the recorded lock request information of a replica node is invalid, it can delete the lock request information of that replica node.

[0077] Accordingly, the target lock service node can determine whether the target replica node can obtain the target lock based on its priority, provided that the lock application information of the target replica node is valid and the lease of the target lock has expired.

[0078] The effects of this embodiment will now be illustrated with a more specific example.

[0079] Assuming the above time interval is 5 seconds, that is, the target replica node sends a lock request message to the distributed lock service every 5 seconds; the above duration threshold is 6 seconds, that is, the validity duration of the lock request information recorded by the target lock service node is 6 seconds; and the validity duration of the lease of the target lock is 8 seconds.

[0080] Assume a distributed database includes a first replica and a second replica, each corresponding to the same lock. The physical or logical node housing the first replica is called the first replica node, and the physical or logical node housing the second replica is called the second replica node. The first and second replica nodes can periodically send lock request information to each lock service node in the distributed lock service at 5-second intervals. If each lock service node in the distributed lock service sends a lock confirmation message to the first replica node, then the first replica node successfully acquires the lock and becomes the primary replica.

[0081] Referring to Figure 2, after the lease of the lock held by the first replica lasts for 5 seconds, if both the first replica (first replica node) and the second replica (second replica node) are functioning normally, each lock service node in the distributed lock service can again receive lock request information sent by the first replica node and the second replica node. At this time, since the lease of the lock held by the first replica has not expired after 5 seconds, each lock service node in the distributed lock service can send lock confirmation information to the first replica node, thus allowing the first replica to continue holding the lock. In practical applications, the lease of the lock held by the first replica can be restarted to extend the lease of the lock held by the first replica.

[0082] Referring to Figure 3, if the first replica (first replica node) malfunctions after 5 seconds of the lock lease held by the first replica, and the second replica (second replica node) is normal, then each lock service node in the distributed lock service will not receive the lock request information sent by the first replica node again, but can receive the lock request information sent by the second replica node again. At this time, the lock lease held by the first replica has lasted for 5 seconds and has not expired, but since the previously received lock request information from the first replica node has been determined to be invalid, each lock service node in the distributed lock service will not send lock confirmation information to the first replica node, and the lease of the lock held by the first replica will not be extended. After 8 seconds of the lock lease held by the first replica, the lease expires; after another 2 seconds, each lock service node in the distributed lock service still will not receive the lock request information sent by the first replica node, but can receive the lock request information sent by the second replica node. At this point, since the lease of the lock held by the first replica has expired and the lock request information of the first replica node recorded is invalid, each lock service node in the distributed lock service can send lock confirmation information to the second replica node, thereby enabling the second replica to successfully acquire the lock and become the primary replica.

[0083] The above methods achieve both stability and security of the distributed lock. Stability means keeping the distributed lock in one partition node as much as possible without changing it, while security means being able to transfer the distributed lock to a normal partition node in a timely manner when the in-place node fails, thereby improving the service stability of the distributed cluster.

[0084] Please refer to Figure 4, which exemplarily illustrates the flow of a distributed lock management method applied to any lock service node (which may be referred to as the target lock service node) of a distributed lock service, including steps S401 to S403.

[0085] In step S401, a lock request message sent by any target replica node corresponding to the target lock is obtained from the database.

[0086] In step S402, it is determined whether the target replica node can acquire the target lock.

[0087] In step S403, if it is determined that the target replica node can acquire the target lock, a lock confirmation message is sent to the target replica node. This ensures that if the target replica node receives lock confirmation messages from lock service nodes whose proportion of the total number of lock service nodes in the distributed lock service is not less than a preset threshold, the target replica node acquires the target lock. Conversely, if it does not receive lock confirmation messages from lock service nodes whose proportion of the total number of lock service nodes in the distributed lock service is not less than the preset threshold, the target replica node does not acquire the target lock.

[0088] For example, the lock request information includes the priority of the target replica node;

[0089] Step S402 can be performed in the following manner:

[0090] Based on the priority of the target replica node, it is determined whether the target replica node can acquire the target lock.

[0091] For example, the target replica node periodically sends lock request information to the distributed lock service at preset time intervals;

[0092] Step S402 can be performed in the following manner:

[0093] Determine whether the target replica node holds the target lock, and determine whether the lease of the target lock has expired;

[0094] If the target replica node holds the target lock and the lease of the target lock has not expired, then it is determined that the target replica node can acquire the target lock.

[0095] For example, the lock request information includes the priority of the target replica node;

[0096] The method further includes:

[0097] Record the lock request messages sent by the target replica node;

[0098] Determine whether the duration for which the lock request information sent by the target replica node has not been obtained is greater than a preset duration threshold. If so, determine that the lock request message sent by the target replica node is invalid.

[0099] Step S402 can be performed in the following manner:

[0100] Determine whether the lock request information of the target replica node is valid, and determine whether the lease of the target lock has expired;

[0101] If the lock request information of the target replica node is valid and the lease of the target lock has expired, then based on the priority of the target replica node, it is determined whether the target replica node can obtain the target lock.

[0102] For example, the database is a centralized database, the target lock is a lock corresponding to the database, and the target replica node is a replica node of the database; or,

[0103] The database is a distributed database, and the data stored in the distributed database is divided into at least one data shard. The target lock is a lock corresponding to any target data shard in the at least one data shard, and the target replica node is a replica node of the target data shard.

[0104] Further details regarding the embodiment of the lock service node shown in Figure 4 above have been described in detail in the embodiment of the replica node shown in Figure 1, and will not be repeated here.

[0105] Figure 5 is a schematic structural diagram of a device provided in an exemplary embodiment. Referring to Figure 5, at the hardware level, the device includes a processor 502, an internal bus 504, a network interface 506, a memory 508, and a non-volatile memory 510, and may also include other hardware required for tasks. One or more embodiments of this specification can be implemented in software, for example, the processor 502 reads the corresponding computer program from the non-volatile memory 510 into the memory 508 and then runs 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.

[0106] Please refer to Figure 6. The distributed lock management device can be applied to the replica nodes running on the device shown in Figure 5 to implement the technical solution of this specification. The replica node is any target replica node of the database corresponding to the target lock. The distributed lock management device may include:

[0107] The application module 601 is used to send lock application information to the distributed lock service so that any target lock service node of the distributed lock service can obtain the lock application information, and send lock confirmation information to the target replica node if it is determined that the target replica node can obtain the target lock.

[0108] The locking module 602 is configured to determine that the target replica node has acquired the target lock if it receives lock confirmation information from a lock service node whose proportion of the total number of lock service nodes in the distributed lock service is not less than a preset proportion threshold; otherwise, it determines that the target replica node has not acquired the target lock if it does not receive lock confirmation information from a lock service node whose proportion of the total number of lock service nodes in the distributed lock service is not less than a preset proportion threshold.

[0109] In one possible embodiment of this specification, the lock request information includes the priority of the target replica node; the target lock service node determines whether the target replica node can obtain the target lock based on the priority of the target replica node.

[0110] In one possible embodiment of this specification, the application module is used for:

[0111] Lock request information is periodically sent to the distributed lock service at preset time intervals.

[0112] In one possible embodiment of this specification, the target lock service node determines that the target replica node can obtain the target lock if the target replica node holds the target lock and the lease of the target lock has not expired.

[0113] In one possible embodiment of this specification, the target lock service node records the lock request information sent by the target replica node; the lock request information of the target replica node is determined to be invalid when the target lock service node fails to obtain the lock request information sent by the target replica node for a duration exceeding a preset duration threshold; when the lock request information of the target replica node is valid and the lease of the target lock has expired, the target lock service node determines whether the target replica node can obtain the target lock based on the priority of the target replica node.

[0114] In one possible embodiment of this specification, the database is a centralized database, the target lock is a lock corresponding to the database, and the target replica node is a replica node of the database; or,

[0115] The database is a distributed database, and the data stored in the distributed database is divided into at least one data shard. The target lock is a lock corresponding to any target data shard in the at least one data shard, and the target replica node is a replica node of the target data shard.

[0116] In one possible embodiment of this specification, the application module is used for:

[0117] The lock request information is sent to a lock service node in the distributed lock service that acts as an intermediary for information relay. This lock service node then forwards the received lock request information to every other lock service node in the distributed lock service; or...

[0118] The lock request information is sent to each lock service node of the distributed lock service.

[0119] Please refer to Figure 7. The distributed lock management device can be applied to the lock service node running on the device shown in Figure 5 to implement the technical solution of this specification. This lock service node can be any target lock service node of the distributed lock service. The distributed lock management device may include:

[0120] The receiving module 701 is used to obtain the lock request message sent by any target replica node corresponding to the target lock in the database;

[0121] The voting module 702 is used to determine whether the target replica node can acquire the target lock; if it is determined that the target replica node can acquire the target lock, a lock confirmation message is sent to the target replica node, so that if the target replica node receives lock confirmation messages from lock service nodes whose proportion of the total number of lock service nodes in the distributed lock service is not less than a preset proportion threshold, the target replica node is determined to have acquired the target lock; if it does not receive lock confirmation messages from lock service nodes whose proportion of the total number of lock service nodes in the distributed lock service is not less than the preset proportion threshold, the target replica node is determined not to have acquired the target lock.

[0122] In one possible embodiment of this specification, the lock request information includes the priority of the target replica node;

[0123] The voting module is used for:

[0124] Based on the priority of the target replica node, it is determined whether the target replica node can acquire the target lock.

[0125] In one possible embodiment of this specification, the target replica node periodically sends lock request information to the distributed lock service at preset time intervals;

[0126] The voting module is used for:

[0127] Determine whether the target replica node holds the target lock, and determine whether the lease of the target lock has expired;

[0128] If the target replica node holds the target lock and the lease of the target lock has not expired, then it is determined that the target replica node can acquire the target lock.

[0129] In one possible embodiment of this specification, the device further includes an information management module for:

[0130] Record the lock request messages sent by the target replica node;

[0131] Determine whether the duration for which the lock request information sent by the target replica node has not been obtained is greater than a preset duration threshold. If so, determine that the lock request message sent by the target replica node is invalid.

[0132] The voting module is used for:

[0133] Determine whether the lock request information of the target replica node is valid, and determine whether the lease of the target lock has expired;

[0134] If the lock request information of the target replica node is valid and the lease of the target lock has expired, then based on the priority of the target replica node, it is determined whether the target replica node can obtain the target lock.

[0135] In one possible embodiment of this specification, the database is a centralized database, the target lock is a lock corresponding to the database, and the target replica node is a replica node of the database; or,

[0136] The database is a distributed database, and the data stored in the distributed database is divided into at least one data shard. The target lock is a lock corresponding to any target data shard in the at least one data shard, and the target replica node is a replica node of the target data shard.

[0137] 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.

[0138] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0139] 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.

[0140] 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.

[0141] 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.

[0142] 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.

[0143] 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.

[0144] 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. Furthermore, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0145] 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."

[0146] 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 target replica node of a database corresponding to a target lock, the method comprising: sending lock application information to a distributed lock service, so that any target lock service node of the distributed lock service obtains the lock application information, and sends lock confirmation information to the target replica node if it is determined that the target replica node can obtain the target lock; if lock confirmation information sent by a lock service node accounting for a proportion of the total number of lock service nodes in the distributed lock service is not less than a preset proportion threshold, it is determined that the target replica node obtains the target lock; if lock confirmation information sent by a lock service node accounting for a proportion of the total number of lock service nodes in the distributed lock service is less than a preset proportion threshold, it is determined that the target replica node does not obtain the target lock. 2.The method of claim 1, wherein the lock application information comprises a priority of the target replica node; and the target lock service node determines whether the target replica node can obtain the target lock based on the priority of the target replica node. 3.The method of claim 1, wherein the sending of the lock application information to the distributed lock service comprises: periodically sending the lock application information to the distributed lock service at a preset time interval. 4.The method of claim 3, wherein the target lock service node determines that the target replica node can obtain the target lock if the target replica node holds the target lock and a lease of the target lock has not expired. 5.The method of claim 2, wherein the target lock service node records the lock application information sent by the target replica node; the lock application information of the target replica node is determined to be invalid if a time length during which the target lock service node does not obtain the lock application information sent by the target replica node is greater than a preset time threshold; and the target lock service node determines whether the target replica node can obtain the target lock based on the priority of the target replica node if the lock application information of the target replica node is valid and a lease of the target lock has expired. 6.The method of claim 1, wherein the database is a centralized database, the target lock is a lock corresponding to the database, and the target replica node is a replica node of the database; or the database is a distributed database, data stored in the distributed database is divided into at least one data shard, the target lock is a lock corresponding to any target data shard of the at least one data shard, and the target replica node is a replica node of the target data shard. 7.The method of claim 1, wherein the sending of the lock application information to the distributed lock service so that any target lock service node of the distributed lock service obtains the lock application information comprises: sending the lock application information to a lock service node of the distributed lock service for information relay, and forwarding, by the lock service node, the received lock application information to each of the remaining lock service nodes of the distributed lock service; or sending the lock application information to each of the lock service nodes of the distributed lock service.

8. A distributed lock management method applied to any target lock service node of a distributed lock service, the method comprising: acquiring a lock application message sent by any target replica node corresponding to a target lock of a database; determining whether the target replica node can obtain the target lock; if it is determined that the target replica node can obtain the target lock, sending lock confirmation information to the target replica node, so that the target replica node determines that the target replica node obtains the target lock if lock confirmation information sent by a lock service node accounting for a proportion not less than a preset proportion threshold in a total number of lock service nodes of the distributed lock service is acquired, and determines that the target replica node does not obtain the target lock if lock confirmation information sent by a lock service node accounting for a proportion not less than the preset proportion threshold in the total number of lock service nodes of the distributed lock service is not acquired.

9. The distributed lock management method of claim 8, wherein the lock application information comprises a priority of the target replica node; and the determining whether the target replica node can obtain the target lock comprises: determining whether the target replica node can obtain the target lock based on the priority of the target replica node.

10. The distributed lock management method of claim 8, wherein the target replica node periodically sends lock application information to the distributed lock service at a preset time interval; and the determining whether the target replica node can obtain the target lock comprises: determining whether the target replica node holds the target lock and whether a lease of the target lock has expired; and if the target replica node holds the target lock and the lease of the target lock has not expired, determining that the target replica node can obtain the target lock.

11. The distributed lock management method of claim 9, further comprising: recording the acquired lock application message sent by the target replica node; determining whether a time length during which the lock application information sent by the target replica node is not acquired is greater than a preset time length threshold, and if so, determining that the lock application message sent by the target replica node is invalid; and the determining whether the target replica node can obtain the target lock comprises: determining whether the lock application information of the target replica node is valid and whether the lease of the target lock has expired; and if the lock application information of the target replica node is valid and the lease of the target lock has expired, determining whether the target replica node can obtain the target lock based on the priority of the target replica node.

12. The distributed lock management method of claim 8, wherein the database is a centralized database, the target lock is a lock corresponding to the database, and the target replica node is a replica node of the database; or ​ ​ ​ ​ ​ ​ ​ ​ The database is a distributed database, data stored in the distributed database is divided into at least one data shard, the target lock is a lock corresponding to any target data shard in the at least one data shard, and the target replica node is a replica node of the target data shard.

13. A distributed lock management apparatus applied to any target replica node of a database corresponding to a target lock, the apparatus comprising: an application module configured to send lock application information to a distributed lock service, so that any target lock service node of the distributed lock service obtains the lock application information, and send lock confirmation information to the target replica node if it is determined that the target replica node can obtain the target lock; a locking module configured to determine that the target replica node obtains the target lock if lock confirmation information sent by a lock service node accounting for a proportion not less than a preset proportion threshold in a total number of lock service nodes in the distributed lock service is obtained; and determine that the target replica node does not obtain the target lock if lock confirmation information sent by a lock service node accounting for a proportion not less than a preset proportion threshold in a total number of lock service nodes in the distributed lock service is not obtained.

14. A distributed lock management apparatus applied to any target lock service node of a distributed lock service, the apparatus comprising: an acquisition module configured to acquire lock application information sent by any target replica node of a database corresponding to a target lock; a voting module configured to determine whether the target replica node can obtain the target lock; and send lock confirmation information to the target replica node if it is determined that the target replica node can obtain the target lock, so that the target replica node determines that the target replica node obtains the target lock if lock confirmation information sent by a lock service node accounting for a proportion not less than a preset proportion threshold in a total number of lock service nodes in the distributed lock service is obtained, and determines that the target replica node does not obtain the target lock if lock confirmation information sent by a lock service node accounting for a proportion not less than a preset proportion threshold in a total number of lock service nodes in the distributed lock service is not obtained.

15. A computer program product comprising computer programs / instructions, which, when executed by a processor, implement the steps of the method of any one of claims 1 to 12.

16. An electronic device comprising: a processor; a memory for storing processor-executable instructions; wherein the processor implements the method of any one of claims 1 to 12 by running the executable instructions.

17. A computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of the method of any one of claims 1 to 12.

Images