Method and apparatus for processing distributed locks

Abstract

The present disclosure provides a method and apparatus for processing a distributed lock. The method includes: in response to receiving a transaction request sent by a transaction center, starting a branch transaction and starting a local transaction for database operations of a distributed service node in the branch transaction; performing first-phase business processing in the local transaction, and during the execution of the first-phase business processing, locking shared resources involved in the first-phase business processing; in response to triggering second-phase business processing, after the second-phase business processing is completed, releasing the lock of the shared resources, and committing the transaction for releasing the lock of the shared resources and the transaction of the second-phase business processing together to ensure that the release of the lock is consistent with the state of the second-phase business processing. Thus, by locking the shared resources in the first phase, it can be ensured that in concurrent transactions, the balance of the same account will not be modified by multiple transactions simultaneously, guaranteeing data consistency and avoiding financial problems caused by inaccurate balances.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technologies, and in particular, to a method and apparatus for processing distributed locks. Background Art

[0002] In the distributed transaction scenario of the TCC (Try-Confirm-Cancel) mode, a two-phase asynchronous execution scheme is currently adopted. In the first phase (Try phase) of TCC, the system will attempt to execute business operations and reserve necessary resources (such as freezing the amount). However, before the second phase (Confirm or Cancel phase) is completed, the status of these reserved resources is uncertain. This is because the Try phase is only a part of the distributed transaction, which is mainly responsible for checking business conditions, performing preliminary operations, and reserving resources. However, until the Confirm or Cancel phase is executed, the entire transaction is considered complete. Between these two phases, the status of the transaction is incomplete, so the reserved resources are also in an uncertain state. If other concurrent transactions occur during this period and rely on the queried balance to trigger subsequent business processes, then due to the uncertainty of the reserved resource status, these concurrent transactions may make decisions based on inaccurate balance information. This may further lead to data inconsistency, such as problems like over-allocation, under-collection, and incorrect entrusted loan details in the fund pool, affecting the stability and reliability of the entire system. Summary of the Invention

[0003] The present disclosure provides a method and apparatus for processing distributed locks to at least solve one of the technical problems in the related art to a certain extent. The technical solutions of the present disclosure are as follows:

[0004] According to a first aspect of an embodiment of the present disclosure, a method for processing a distributed lock is provided, including: in response to receiving a transaction request sent by a transaction center, starting a branch transaction and starting a local transaction for database operations of the distributed service node in the branch transaction; performing first-phase business processing in the local transaction, and during the execution of the first-phase business processing, locking shared resources involved in the first-phase business processing; in response to triggering second-phase business processing, after the second-phase business processing is completed, releasing the lock of the shared resource, and submitting the transaction for releasing the lock of the shared resource and the transaction of the second-phase business processing together to ensure that the release of the lock is consistent with the status of the second-phase business processing.

[0005] According to a second aspect of the embodiments of the present disclosure, there is provided a processing apparatus for a distributed lock, including: a first processing module, configured to, in response to receiving a transaction request sent by a transaction center, initiate a branch transaction and initiate a local transaction for database operations of the distributed service node in the branch transaction; a second processing module, configured to perform a one-phase business process in the local transaction, and during the execution of the one-phase business process, lock a shared resource involved in the one-phase business process; a first lock release module, configured to, in response to triggering a two-phase business process, after the two-phase business process is completed, release the lock of the shared resource, and commit the transaction of releasing the lock of the shared resource and the transaction of the two-phase business process together to ensure that the release of the lock is consistent with the state of the two-phase business process.

[0006] According to a third aspect of the embodiments of the present disclosure, there is provided an electronic device, including: a processor; a memory for storing executable instructions of the processor; wherein the processor is configured to execute the instructions to implement the method for processing a distributed lock as described in the first aspect of the embodiments of the present disclosure.

[0007] According to a fourth aspect of the embodiments of the present disclosure, there is provided a computer-readable storage medium, when instructions in the computer-readable storage medium are executed by a processor of an electronic device, enabling the electronic device to execute the method for processing a distributed lock as described in the first aspect of the embodiments of the present disclosure.

[0008] According to a fifth aspect of the embodiments of the present disclosure, there is provided a computer program product, including: a computer program, which when executed by a processor implements the method for processing a distributed lock as described in the first aspect of the embodiments of the present disclosure.

[0009] The technical solutions provided by the embodiments of the present disclosure at least bring the following beneficial effects:

[0010] In this technical solution, in response to receiving a transaction request sent by a transaction center, a branch transaction is started and a local transaction is started for database operations of a distributed service node in the branch transaction; in the local transaction, a one-phase business process is executed, and during the execution of the one-phase business process, locks are added to shared resources involved in the one-phase business process; in response to triggering a two-phase business process, after the two-phase business process is completed, the locks of the shared resources are released, and the transaction for releasing the locks of the shared resources and the transaction of the two-phase business process are submitted together to ensure that the release of the locks is consistent with the status of the two-phase business process. Thus, by adding locks to shared resources in the one-phase, it can be ensured that in concurrent transactions, the balance of the same account will not be modified by multiple transactions simultaneously, ensuring data consistency and avoiding financial problems caused by inaccurate balances; among them, during the locking process, the present disclosure can support the re-entrancy of the locks through implementation logic, enabling multiple borrowing and lending operations under the same transaction to be executed smoothly without blocking each other, meeting the requirements of multi-borrowing and multi-lending scenarios; in addition, in the present disclosure, the distributed service node only focuses on adding locks to shared resources involved in the one-phase business process during the execution of the one-phase business process, without paying attention to the release of the locks. The release of the locks depends on the global transaction manager to trigger the two-phase business process and uniformly release the locks after the two-phase business process is completed. Among them, the locking in the one-phase and the release of the locks in the two-phase are not in the same thread, simplifying the management and maintenance of the locks; furthermore, in the present disclosure, by releasing the locks after the two-phase business process is completed and submitting the transaction for releasing the locks and the transaction of the two-phase business process together, it can effectively ensure that the release of the locks is consistent with the status of the two-phase business process.

[0011] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and do not limit the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The accompanying drawings here are incorporated into the specification and constitute a part of this specification, showing embodiments consistent with the present disclosure, and are used together with the specification to explain the principles of the present disclosure, and do not constitute an improper limitation of the present disclosure.

[0013] Figure 1 is a schematic flowchart of a method for processing a distributed lock shown in the first embodiment of the present disclosure;

[0014] Figure 2 is a schematic flowchart of a method for processing a distributed lock shown in the second embodiment of the present disclosure;

[0015] Figure 3 is a schematic flowchart of a locking process shown in the third embodiment of the present disclosure;

[0016] Figure 4It is a schematic flowchart of the method for processing a distributed lock shown in the fourth embodiment of the present disclosure;

[0017] Figure 5 It is a schematic flowchart of the method for processing a distributed lock shown in the fifth embodiment of the present disclosure;

[0018] Figure 6 It is a schematic diagram of the principle of processing a distributed lock provided by the sixth embodiment of the present disclosure;

[0019] Figure 7 It is a schematic diagram of the scenario of processing a distributed lock provided by the seventh embodiment of the present disclosure;

[0020] Figure 8 It is a schematic structural diagram of the device for processing a distributed lock shown in the eighth embodiment of the present disclosure;

[0021] Figure 9 It is a schematic structural diagram of an electronic device shown in an exemplary embodiment of the present disclosure. Detailed implementation manners

[0022] In order to enable those of ordinary skill in the art to better understand the technical solutions of the present disclosure, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0023] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily need to be used to describe a specific order or sequence. It should be understood that such used data can be interchanged under appropriate circumstances so that the embodiments of the present disclosure described herein can be implemented in an order different from those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present disclosure. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

[0024] It should be noted that in the technical solutions of the present disclosure, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information and other processing are all carried out on the premise of obtaining the consent of the user, and all comply with the provisions of relevant laws and regulations and do not violate public order and good customs.

[0025] In order to ensure that transactions related to the fund pool can be processed in parallel and reduce the scope of accounts affected by transactions, the present disclosure proposes a method and device for processing a distributed lock. In the first stage, a lock is added to the shared resource, and the re-entrancy of the lock is supported during the locking process. After the business processing in the second stage is completed, the lock is released uniformly, which not only ensures data consistency but also meets the requirements of the multi-borrow and multi-lend scenario, and simplifies the management and maintenance of the lock.

[0026] The following describes a method and apparatus for processing a distributed lock according to an embodiment of the present disclosure with reference to the accompanying drawings.

[0027] Figure 1 It is a flowchart of a method for processing a distributed lock shown in the first embodiment of the present disclosure.

[0028] It should be noted that the method for processing a distributed lock according to an embodiment of the present disclosure is applied to a distributed service node.

[0029] As shown in Figure 1 the method for processing the distributed lock includes the following steps:

[0030] Step 101, in response to receiving a transaction request sent by a transaction center, start a branch transaction and start a local transaction for database operations of the distributed service node in the branch transaction.

[0031] Among them, the transaction center is used to initiate a distributed transaction that needs to be executed across multiple distributed service nodes. As a possible implementation, the transaction center can send a transaction request to multiple distributed service nodes to trigger the initiation of the distributed transaction.

[0032] Since the distributed transaction needs to be executed across multiple distributed service nodes, in order to ensure the atomicity, consistency, isolation, and durability of transaction execution on different distributed service nodes, as a possible implementation, each distributed service node can, in response to receiving a transaction request sent by the transaction center, start one or more branch transactions to manage its own operations in the entire distributed transaction. Thus, the entire distributed transaction is decomposed into multiple branch transactions, and each branch transaction is responsible for executing part of the operations within the corresponding distributed service node.

[0033] For example, assume that the request content of the transaction request is to transfer X yuan from account A to account B. Then, the operations of the service node of account A in the entire distributed transaction are: check whether the balance of account A is sufficient, and if so, reserve (or freeze) X yuan; the operations of the service node of account B in the entire distributed transaction are: prepare to receive X yuan, but do not immediately increase the balance and wait for confirmation.

[0034] For example, assume that the request content of the transaction request is that a user submits an order to purchase product Y. Then, the operations of the inventory service node in the entire distributed transaction are: check the inventory quantity of product Y, and if sufficient, reserve a certain quantity of inventory; the operations of the order service node in the entire distributed transaction are: create an order record and set the order status to "pending payment"; the operations of the payment service node (if immediate payment is involved) in the entire distributed transaction are: wait for the user to complete the payment operation and verify the payment result.

[0035] As an example, the distributed service node can use the API (Application Programming Interface) provided by a distributed transaction framework (such as Seata (Simple Extensible Autonomous Transaction Architecture), Atomikos, etc.) to initiate a branch transaction.

[0036] It should be noted that, in order to clearly track the status and progress of each participant in the distributed transaction, in the embodiments of the present disclosure, the distributed service node can also register the main stream water of the branch transaction, that is, record the main stream water information of the branch transaction (such as the transaction identifier (transaction ID) of the branch transaction, the service node identifier (service node ID) of the distributed service node, the operation type, the time stamp, etc.), so that in case of a failure, by reading the record of the main stream water of the branch transaction, the execution status of the transaction can be restored to ensure the reliability and stability of the distributed transaction.

[0037] As an example, the distributed service node can use a logging framework (such as Log4j, SLF4J, etc.) to record the main stream water information of the branch transaction, or write the main stream water information of the branch transaction into a transaction log table.

[0038] As a possible implementation, after initiating a branch transaction, the distributed service node can initiate one or more local transactions in each branch transaction to execute specific business logic. Among them, the local transaction is at the database or resource manager level and is used to ensure the consistency of data within a single service node.

[0039] As an example, the distributed service node can use the transaction management mechanism provided by the database (such as the beginTransaction of JDBC (Java Database Connectivity)) to initiate a local transaction.

[0040] It can be understood that during the execution of the local transaction, multiple operations or sub-steps may be generated. In order to facilitate more detailed tracking of the execution process of the transaction, in the embodiments of the present disclosure, the distributed service node can also register the sub-stream water of the branch transaction, that is, during the execution of the local transaction, record the detailed information of each operation or sub-step as the sub-stream water of the branch transaction. Thus, the execution situation of the transaction can be recorded at a finer granularity.

[0041] Step 102, perform the first-phase business processing in the local transaction, and during the execution of the first-phase business processing, lock the shared resources involved in the first-phase business processing.

[0042] As a possible implementation, after starting a local transaction, the distributed service node can execute specific business logic in each local transaction. For example, querying the database, updating data, etc.

[0043] It should be noted that, as a possible implementation, to ensure data consistency, during the execution of the first-phase business processing, the distributed service node can lock the shared resources involved in the first-phase business processing to prevent concurrent changes to the shared resources by other transactions or operations. Thus, by locking the shared resources in the first phase, it can be ensured that in concurrent transactions, the balance of the same account will not be modified simultaneously by multiple transactions, guaranteeing data consistency and avoiding financial problems caused by inaccurate balances.

[0044] For example, in the e-commerce business scenario, when a user places an order to purchase a product, it is necessary to first check whether the product inventory is sufficient. If it is sufficient, the inventory is deducted and an order is created. In this process, the inventory is a shared resource that needs to be locked to prevent concurrent changes. Optionally, Redis (Remote Dictionary Server) technology can be used for locking. For example, the SET key value NX PX milliseconds command can be used to attempt to lock. Here, key is the identifier of the lock, value is the unique identifier of the party requesting the lock (such as UUID (Universally Unique Identifier)), which is used to verify the ownership of the lock when unlocking, and milliseconds is the expiration time of the lock. If the command execution is successful, it means the lock has been successfully obtained, and subsequent business processing (such as inventory deduction) can be safely carried out. If the command execution fails (indicating that the shared resource has been locked with an incompatible lock), it can be chosen to retry after waiting for a period of time, or other strategies (such as polling, backoff algorithms, etc.) can be used to avoid frequent lock contention.

[0045] Step 103: In response to triggering the second-phase business processing, after the second-phase business processing is completed, release the lock of the shared resource, and commit the transaction for releasing the lock of the shared resource together with the transaction of the second-phase business processing to ensure that the release of the lock is consistent with the status of the second-phase business processing.

[0046] Among them, the locking of the shared resource and the release of the lock of the shared resource when triggering the second-phase business processing are not in the same thread.

[0047] In the TCC mode, if the locking in the first phase is improper, deadlocks may occur. For example, suppose there are two distributed service nodes: distributed service node A and distributed service node B, and two shared resources: shared resource R1 and shared resource R2. Distributed service node A needs shared resource R1 and shared resource R2 to complete its transaction, and distributed service node B also needs these two shared resources, but their request orders are opposite, that is:

[0048] Operations of distributed service node A:

[0049] First phase: While distributed service node A locks shared resource R1, distributed service node B locks shared resource R2. After that, when distributed service node A attempts to lock shared resource R2 for operation, shared resource R2 has been locked by distributed service node B. At this time, distributed service node A will hold the lock on shared resource R1 and wait for shared resource R2 to become available.

[0050] Operations of distributed service node B:

[0051] First phase: While distributed service node A locks shared resource R1, distributed service node B locks shared resource R2. After that, when distributed service node B attempts to lock shared resource R1 for operation, shared resource R1 has been locked by distributed service node A. At this time, distributed service node B will hold the lock on shared resource R2 and wait for shared resource R1 to become available.

[0052] Since both distributed service node A and distributed service node B hold the locks on the shared resources that the other party needs and are waiting for the other party to release the locks on the shared resources they hold, a deadlock is formed.

[0053] To avoid deadlocks and improve resource utilization, as a possible implementation, the distributed service node can, in response to triggering the second-phase business processing, release the lock on the shared resource after the second-phase business processing is completed, so that the shared resource can be used by other subsequent transactions.

[0054] In the present disclosure, the distributed service node only focuses on locking the shared resources involved in the first-phase business processing during the execution of the first-phase business processing, and does not need to concern about the release of the lock. The release of the lock depends on the global transaction manager to trigger the second-phase business processing. Thus, the distributed service node, in response to triggering the second-phase business processing, uniformly releases the lock after the second-phase business processing is completed. Among them, the locking in the first phase and the release of the lock in the second phase are not in the same thread, which simplifies the management and maintenance work of the lock.

[0055] Among them, the two-phase business processing includes confirming the execution of business processing and canceling the execution of business processing. The two-phase business processing executed by the distributed service node is determined by the global transaction manager based on the one-phase business processing results of multiple distributed service nodes involved in the distributed transaction corresponding to the distributed service node;

[0056] When the one-phase business processing results of all distributed service nodes involved in the distributed transaction corresponding to the distributed service node are all successful, the global transaction manager triggers the confirmation of the execution of business processing to each distributed service node involved in the distributed transaction corresponding to the distributed service node;

[0057] When the one-phase business processing result of any distributed service node involved in the distributed transaction corresponding to the distributed service node is a failure, the global transaction manager triggers the cancellation of the execution of business processing to each distributed service node involved in the distributed transaction corresponding to the distributed service node.

[0058] It should be noted that when the one-phase business processing ends normally, the two-phase business processing will be triggered. As a possible implementation, the distributed service node can release the lock of the shared resource after the two-phase business processing is completed, and commit the transaction of releasing the lock of the shared resource together with the transaction of the two-phase business processing to ensure that the release of the lock is consistent with the status of the two-phase business processing.

[0059] In summary, on the one hand, the release of the lock of the shared resource will be executed after the two-phase business processing is completed. On the other hand, the release of the lock of the shared resource does not use an independent transaction, but commits the transaction of releasing the lock of the shared resource together with the transaction of the two-phase business processing. Therefore, when the transaction of releasing the lock fails to be committed, it will cause an abnormal business process, and it can ensure that the release of the lock is consistent with the status of the two-phase business processing.

[0060] The method for processing the distributed lock according to the embodiment of the present disclosure includes: in response to receiving a transaction request sent by the transaction center, starting a branch transaction and starting a local transaction for the database operation of the distributed service node in the branch transaction; executing one-phase business processing in the local transaction, and during the execution of the one-phase business processing, locking the shared resources involved in the one-phase business processing; in response to triggering the two-phase business processing, after the two-phase business processing is completed, releasing the lock of the shared resource, and committing the transaction of releasing the lock of the shared resource together with the transaction of the two-phase business processing to ensure that the release of the lock is consistent with the status of the two-phase business processing. Thus, by locking the shared resources in the first phase, it can be ensured that in concurrent transactions, the balance of the same account will not be modified by multiple transactions at the same time, ensuring data consistency and avoiding financial problems caused by inaccurate balances.

[0061] To clearly illustrate how the shared resources involved in the one - phase business process are locked during the execution of the above - mentioned embodiments, the present disclosure proposes another method for processing distributed locks.

[0062] Figure 2 It is a schematic flowchart of the method for processing distributed locks shown in the second embodiment of the present disclosure.

[0063] As Figure 2 shown, the method for processing distributed locks includes the following steps:

[0064] Step 201, in response to receiving a transaction request sent by the transaction center, start a branch transaction and start a local transaction for the database operation of the distributed service node in the branch transaction.

[0065] Step 202, execute the one - phase business process in the local transaction.

[0066] Step 203, during the execution of the one - phase business process, call the lock - adding interface provided by the distributed lock service to send a lock - adding request to the distributed lock service, so that the distributed lock service locks the shared resource according to the resource identifier of the shared resource, the transaction identifier of the branch transaction, the lock type, and the lock - adding time carried in the lock - adding request, and sends a corresponding lock - adding identifier to the distributed service node based on the lock - adding result.

[0067] Among them, the lock - adding request is used to request to lock the shared resource, and information such as the resource identifier of the shared resource, the transaction identifier of the branch transaction, the lock type, and the lock - adding time can be carried in the lock - adding request. For example, the lock type includes write lock, read lock, etc.

[0068] For the convenience of maintaining and developing the business system, as a possible implementation, the distributed service node can complete the locking of the shared resource by interacting with the distributed lock service.

[0069] In the embodiments of the present disclosure, the distributed service node can call the lock - adding interface provided by the distributed lock service to send a lock - adding request to the distributed lock service during the execution of the one - phase business process, so that the distributed lock service locks the shared resource according to the resource identifier of the shared resource, the transaction identifier of the branch transaction, the lock type, and the lock - adding time carried in the lock - adding request, and sends a corresponding lock - adding identifier to the distributed service node based on the lock - adding result.

[0070] In a possible implementation, the lock - adding identifier includes a lock - adding success identifier and a lock - adding failure identifier. When the distributed lock service locks the shared resource according to the resource identifier of the shared resource, the transaction identifier of the branch transaction, the lock type, and the lock - adding time carried in the lock - adding request, it can specifically execute according to the steps as Figure 3 shown:

[0071] Step 2031, the distributed lock service determines whether there is a first lock record in the lock record table whose resource identifier is the same as the resource identifier carried in the lock request.

[0072] In the embodiments of the present disclosure, after receiving the lock request, the distributed lock service can perform a primary key (resource identifier) conflict check, that is, check whether the resource identifier of each lock record in the lock record table is consistent with the resource identifier carried in the lock request. If they are consistent, the corresponding lock record is the first lock record, that is, the lock record where the shared resource already exists.

[0073] Among them, if there is a first lock record, the number of first lock records can be one or more, and the embodiments of the present disclosure do not limit this.

[0074] Step 2032, if there is no first lock record, the distributed lock service adds a second lock record of the branch transaction for the shared resource in the lock record table, and sends a lock success flag to the distributed service node.

[0075] If the primary key does not conflict, that is, there is no first lock record in the lock record table, it means that the shared resource is not locked. At this time, the distributed service node can lock the shared resource. Therefore, the distributed lock service can add a lock record (the second lock record of the branch transaction for the shared resource) in the lock record table to record the locking information of the distributed service node for the shared resource (such as the resource identifier of the shared resource, the transaction identifier of the branch transaction, the lock type, the lock time, etc.).

[0076] In addition, after adding the second lock record, the distributed lock service can also send a lock success flag to the distributed service node to inform the distributed service node that the lock is successful.

[0077] Step 2033, if there is a first lock record, the distributed lock service determines whether the lock type in the first lock record is compatible with the lock type carried in the lock request.

[0078] If the primary key conflicts, that is, there is a first lock record in the lock record table, it means that the shared resource is already locked. At this time, the distributed service node can determine whether the lock type in the first lock record is compatible with the lock type carried in the lock request.

[0079] As an example, the lock types include write locks, read locks, and exclusive locks. The compatibility of these three locks is as follows: Read locks are compatible with read locks (a read lock allows the holder to read data and also allows other read lock holders to read data in parallel), write locks are not compatible with write locks (a write lock allows the holder to write data but does not allow other write lock holders to write data in parallel), write locks are compatible with read locks (a write lock allows the holder to write data and also allows other read lock holders to read data in parallel), and exclusive locks are not compatible with any other locks (an exclusive lock only allows the holder to perform operations and does not allow the holders of any other locks to perform operations).

[0080] Step 2034, if they are not compatible, the distributed lock service determines whether the first lock record is an expired record based on the lock acquisition time in the first lock record.

[0081] If the lock type in the first lock record is not compatible with the lock type carried in the lock acquisition request (for example, there is already a write lock, and the current request is also a write lock), at this time, to avoid the lock record remaining in the lock record table due to the inability to release the lock, the distributed service node can then determine whether the first lock record is an expired record. As a possible implementation, the distributed service node can determine whether the first lock record is an expired record based on the lock acquisition time in the first lock record. For example, if the current time is not within the range of the lock acquisition time in the first lock record, it can be determined that the first lock record is an expired record, otherwise, it is not.

[0082] As an example, when the process crashes after the first-phase lock acquisition is successful, this will cause the lock to be unable to be released, and thus the lock record will remain in the lock record table all the time.

[0083] It should be noted that only when the lock record remains in the lock record table due to the inability to release the lock will the situation of deleting the expired record occur during lock acquisition.

[0084] Step 2035, if it is an expired record, the distributed lock service first deletes the first lock record in the lock record table, then adds a second lock record to the lock record table, and sends a lock acquisition success flag to the distributed service node.

[0085] If the first lock record is an expired record, it means that the shared resource is not locked and used by other transactions. At this time, the shared resource can be locked. Therefore, the distributed lock service can first delete the first lock record in the lock record table, then add a second lock record to the lock record table, and send a lock acquisition success flag to the distributed service node to inform the distributed service node that the lock acquisition is successful.

[0086] It should be noted that, in order to prevent the situation where although the lock record is an expired record, the shared resource is still being used by the target transaction indicated by the transaction identifier recorded in the lock record. As a possible implementation, before deleting the first lock record in the lock record table, the distributed lock service can query the status of the target transaction indicated by the transaction identifier recorded in the first lock record, and delete the first lock record in the lock record table when the status of the target transaction is empty. Wherein, the empty status of the target transaction indicates that the target transaction is not being executed.

[0087] Step 2036, if it is not an expired record, the distributed lock service determines that the lock addition fails and sends a lock addition failure identifier to the distributed service node.

[0088] If the first lock record is not an expired record, it means that the shared resource is being locked and used by other transactions. At this time, the shared resource cannot be locked. Therefore, the distributed lock service can determine that the lock addition fails and send a lock addition failure identifier to the distributed service node to inform the distributed service node that the lock addition fails.

[0089] Step 2037, if it is compatible, the distributed lock service determines whether the transaction identifier in the first lock record is the same as the transaction identifier carried in the lock addition request.

[0090] If the lock type in the first lock record is compatible with the lock type carried in the lock addition request. For example, there is already a read lock, and the current request is also a read lock. At this time, since read locks are compatible with each other, the shared resource can be locked. Therefore, the distributed lock service can determine whether the lock requested by the lock addition request is a reentrant lock by determining whether the transaction identifier in the first lock record is the same as the transaction identifier carried in the lock addition request.

[0091] Step 2038, if they are the same, the distributed lock service determines that the lock requested by the lock addition request is a reentrant lock, and determines whether it is necessary to update the lock addition time in the first lock record according to the lock addition time carried in the lock addition request. In response to updating the lock addition time in the first lock record, or if there is no need to update the lock addition time in the first lock record, a lock addition success identifier is sent to the distributed service node.

[0092] If the transaction identifier in the first lock record is the same as the transaction identifier carried in the lock acquisition request, it can be determined that the lock requested by the lock acquisition request is a reentrant lock. At this time, the lock acquisition time of the lock requested by the lock acquisition request may be inconsistent with the lock acquisition time in the first lock record. Therefore, the distributed lock service needs the lock acquisition time carried in the lock acquisition request to determine whether to update the lock acquisition time in the first lock record. For example, when the lock acquisition time in the first lock record does not include the lock acquisition time carried in the lock acquisition request, the lock acquisition time in the first lock record needs to be updated; otherwise, it is not necessary to update. Furthermore, the distributed lock service can send a lock acquisition success flag to the distributed service node after updating the lock acquisition time in the first lock record or when it is not necessary to update the lock acquisition time in the first lock record, to inform the distributed service node that the lock acquisition is successful.

[0093] Step 2039, if they are not the same, the distributed lock service determines that the lock requested by the lock acquisition request is not a reentrant lock, and determines whether the first lock record is an expired record according to the lock acquisition time in the first lock record.

[0094] If the transaction identifier of the first lock record is not the same as the transaction identifier carried in the lock acquisition request, it can be determined that the lock requested by the lock acquisition request is not a reentrant lock. At this time, to avoid the lock record remaining in the lock record table due to the inability to release the lock, the distributed service node can then determine whether the first lock record is an expired record. As a possible implementation, the distributed service node can determine whether the first lock record is an expired record based on the lock acquisition time in the first lock record. For example, if the current time is not within the range of the lock acquisition time in the first lock record, it can be determined that the first lock record is an expired record; otherwise, vice versa.

[0095] Step 2040, if it is an expired record, the distributed lock service first deletes the first lock record in the lock record table, then adds a second lock record to the lock record table, and sends a lock acquisition success flag to the distributed service node.

[0096] It should be noted that the execution process of this step can refer to step 2035 and will not be elaborated here.

[0097] Step 2041, if it is not an expired record, the distributed lock service adds a second lock record to the lock record table and sends a lock acquisition success flag to the distributed service node.

[0098] If the first lock record is not an expired record, it means that the shared resource is being locked and used by other transactions. However, since the lock type in the first lock record is compatible with the lock type carried in the lock acquisition request, the shared resource can still be locked at this time. Therefore, the distributed lock service can add a second lock record to the lock record table and send a lock acquisition success flag to the distributed service node to inform the distributed service node that the lock acquisition is successful.

[0099] In summary, during the locking process, the re - entry of the lock can be supported through the implementation logic, enabling multiple lending operations under the same transaction to be executed smoothly without mutual blocking, and meeting the requirements of the multi - borrowing and multi - lending scenario. Moreover, during the locking process, it is also possible to avoid the situation where the lock record cannot be released, resulting in the lock record remaining in the lock record table all the time and preventing subsequent locking, by determining whether the existing lock record has expired.

[0100] Step 204: Receive the lock acquisition identifier sent by the distributed lock service. In response to successful lock acquisition, continue with the first - phase business processing. Or, in response to failed lock acquisition, wait for a set duration and then re - lock the shared resource.

[0101] In the embodiments of the present disclosure, the distributed service node can obtain the lock acquisition result by receiving the lock acquisition identifier sent by the distributed lock service. Thus, in the case of successful lock acquisition, continue with the first - phase business processing. Or, in the case of failed lock acquisition, wait for a set duration and then re - lock the shared resource. Here, the set duration can be any duration.

[0102] Step 205: In response to triggering the second - phase business processing, after the second - phase business processing is completed, release the lock of the shared resource, and commit the transaction of releasing the lock of the shared resource together with the transaction of the second - phase business processing to ensure that the release of the lock is consistent with the state of the second - phase business processing.

[0103] It should be noted that the execution processes of steps 201 to 202 and step 205 can be implemented in any of the ways in the respective embodiments of the present disclosure. The embodiments of the present disclosure do not make any limitations in this regard and will not elaborate further.

[0104] The method for processing the distributed lock in the embodiments of the present disclosure is as follows: During the execution of the first - phase business processing, call the lock acquisition interface provided by the distributed lock service to send a lock acquisition request to the distributed lock service, so that the distributed lock service locks the shared resource according to the resource identifier of the shared resource, the transaction identifier of the branch transaction, the lock type, and the lock acquisition time carried in the lock acquisition request, and based on the lock acquisition result, send the corresponding lock acquisition identifier to the distributed service node; receive the lock acquisition identifier sent by the distributed service node and continue with the first - phase business processing. Thus, by introducing the distributed lock service, the lock acquisition logic is separated from the business logic, reducing the coupling degree between system components. Moreover, through the unified interface provided by the distributed lock service, it is convenient to centrally manage and maintain the lock resources. In addition, for high - concurrency business scenarios, the demand for high concurrency can also be met by increasing the number of nodes of the distributed lock service.

[0105] To clearly illustrate how the lock of the shared resource is released in the above - mentioned embodiments, the present disclosure proposes another method for processing the distributed lock.

[0106] Figure 4 It is a schematic flowchart of the processing method of the distributed lock shown in the fourth embodiment of the present disclosure.

[0107] As Figure 4 shown, the processing method of the distributed lock includes the following steps:

[0108] Step 401, in response to receiving a transaction request sent by the transaction center, start a branch transaction and start a local transaction for the database operation of the distributed service node in the branch transaction.

[0109] Step 402, perform first-phase business processing in the local transaction, and during the execution of the first-phase business processing, lock the shared resources involved in the first-phase business processing.

[0110] Step 403, in response to triggering second-phase business processing, after the second-phase business processing is completed, send a lock release request to the distributed lock service, so that the distributed lock service deletes the lock record of the branch transaction on the shared resource in the lock record table according to the resource identifier of the shared resource and the transaction identifier of the branch transaction carried in the lock release request, and sends a lock release identifier to the distributed service node.

[0111] Among them, the lock release identifier is used to indicate that the lock of the branch transaction on the shared resource has been released.

[0112] To simplify the management and maintenance of the lock, as a possible implementation, the distributed service node can release the lock uniformly after the second-phase business processing is completed.

[0113] In the embodiment of the present disclosure, the distributed service node can send a lock release request to the distributed lock service after the second-phase business processing is completed, so that the distributed lock service deletes the lock record of the branch transaction on the shared resource in the lock record table according to the resource identifier of the shared resource and the transaction identifier of the branch transaction carried in the lock release request, and sends a lock release identifier to the distributed service node to inform the distributed service node that the lock has been successfully released.

[0114] Step 404, receive the lock release identifier sent by the distributed lock service.

[0115] In the embodiment of the present disclosure, if the distributed service node receives the lock release identifier sent by the distributed lock service, it can determine that the lock has been successfully released.

[0116] Step 405, commit the transaction of releasing the lock of the shared resource together with the transaction of the second-phase business processing to ensure that the release of the lock is consistent with the state of the second-phase business processing.

[0117] It should be noted that the execution processes of steps 401 to 402 and step 405 can be implemented in any of the ways in the various embodiments of the present disclosure. The embodiments of the present disclosure do not limit this and will not elaborate further.

[0118] In the method for processing a distributed lock according to an embodiment of the present disclosure, in response to triggering two-phase service processing, after the two-phase service processing is completed, a lock release request is sent to a distributed lock service, so that the distributed lock service deletes the lock record of the branch transaction on the shared resource in the lock record table according to the resource identifier of the shared resource and the transaction identifier of the branch transaction carried in the lock release request, and sends a lock release identifier to the distributed service node; wherein, the lock release identifier is used to indicate that the lock of the branch transaction on the shared resource has been released; receiving the lock release identifier sent by the distributed lock service. Thus, the distributed service node only focuses on locking the shared resources involved in the first-phase service processing during the execution process of the first-phase service processing, and does not need to pay attention to the release of the lock. The release of the lock depends on the global transaction manager to trigger the two-phase service processing and uniformly release the lock after the two-phase service processing is completed. Among them, the lock addition in the first phase and the lock release in the second phase are not in the same thread, which simplifies the management and maintenance of the lock.

[0119] It should be noted that in the present disclosure, the distributed service node can also perform a local transaction rollback in the case where an exception occurs in the first-phase service processing after the locking of the shared resource is completed. The following Figure 5 illustrates this process.

[0120] Figure 5 is a schematic flowchart of the method for processing a distributed lock shown in the fifth embodiment of the present disclosure.

[0121] As Figure 5 shown, the method for processing the distributed lock includes the following steps:

[0122] Step 501, in response to receiving a transaction request sent by a transaction center, start a branch transaction and start a local transaction for database operations of the distributed service node in the branch transaction.

[0123] Step 502, perform first-phase service processing in the local transaction, and during the execution process of the first-phase service processing, lock the shared resources involved in the first-phase service processing.

[0124] Step 503, in response to an exception occurring in the first-phase service processing after the locking of the shared resource is completed, perform a local transaction rollback, and after the local transaction rollback is completed, release the lock of the shared resource.

[0125] Among them, the locking of the shared resource and the release of the lock of the shared resource when triggering the local transaction rollback are in the same thread.

[0126] In an embodiment of the present disclosure, if an exception occurs during business processing after locking a shared resource in the first phase, resulting in the transaction being unable to continue normal execution, a local transaction rollback will be performed, and the local transaction manager will call the post-transaction rollback processing to release the lock of the shared resource after the transaction rollback.

[0127] It should be noted that after the local transaction rollback, the distributed service node can also execute the first-phase business processing again, and during the process of the first-phase business processing again, lock the shared resources involved in the first-phase business processing. Thus, the release of the lock of the shared resource when triggering the local transaction rollback will not affect the release of the lock of the shared resource when triggering the second-phase business processing.

[0128] It should be noted that the release of the lock of the shared resource when triggering the local transaction rollback is an independent transaction and can be independently committed; the release of the lock of the shared resource when triggering the second-phase business processing is a non-independent transaction and needs to be committed together with the transaction of the second-phase business processing. The release of the lock of the shared resource when triggering the local transaction rollback is to call the post-transaction rollback processing to release the lock after the local transaction rollback; the release of the lock of the shared resource when triggering the second-phase business processing is to call the post-branch transaction processing to release the lock after the second-phase business processing and before the transaction is committed.

[0129] Step 504, in response to triggering the second-phase business processing, after the second-phase business processing is completed, release the lock of the shared resource, and commit the transaction of the release of the lock of the shared resource together with the transaction of the second-phase business processing to ensure that the release of the lock is consistent with the state of the second-phase business processing.

[0130] It should be noted that the execution processes of steps 501 to 502 and step 504 can be implemented in any one of the embodiments of the present disclosure respectively. The embodiments of the present disclosure do not make any limitations in this regard and will not be elaborated further.

[0131] The distributed lock processing method of the embodiments of the present disclosure, by responding to an exception occurring during the first-phase business processing after locking a shared resource, performing a local transaction rollback, and releasing the lock of the shared resource after the local transaction rollback is completed. Thus, if an exception occurs during business processing after locking a shared resource in the first phase, data consistency can be ensured through transaction rollback, and deadlocks can be avoided by releasing the lock of the shared resource.

[0132] Based on any embodiment of the present disclosure, as Figure 6 shown, the distributed lock processing method of the embodiments of the present disclosure can also be implemented based on the following steps:

[0133] 1. Receive a transaction request sent by the transaction center

[0134] This is the starting point of a distributed transaction, usually initiated by a certain service (such as an order service), which requests to start a distributed transaction that needs to be executed across multiple distributed service nodes.

[0135] 2. Start branch transactions

[0136] When a distributed service node receives a transaction request sent by the transaction center, it will start one or more branch transactions based on the information carried in the transaction request.

[0137] 3. Register the main stream of branch transactions

[0138] The distributed service node will also record the main stream information of the started branch transactions, including the transaction identifier (transaction ID) of the branch transaction, the service node identifier (service node ID) of the distributed service node, the operation type, the timestamp, etc., for subsequent tracking and recovery.

[0139] 4. Start local transactions

[0140] To ensure data consistency within a single service node, the distributed service node will start one or more local transactions in the branch transaction to execute specific business logic.

[0141] 5. Register the sub-stream of branch transactions

[0142] Similar to registering the main stream of branch transactions, the distributed service node will also record the execution status of the transaction at a finer granularity as the sub-stream of the branch transaction, such as the execution result of SQL (Structured Query Language) statements, etc.

[0143] 6. First-phase business processing

[0144] The distributed service node executes specific business logic, such as querying the database, updating data, etc.

[0145] 7. Lock shared resources by calling the lock interface during business processing

[0146] During the execution of the first-phase business processing, to prevent data inconsistency, the distributed service node will lock the shared resources involved in the first-phase business processing.

[0147] 8. First-phase business processing

[0148] After successful locking, the distributed service node continues to execute specific business logic.

[0149] 9. Modify the status of branch transactions

[0150] The distributed service node will modify the status of the branch transaction according to the first-phase business processing result. For example, if the first-phase business processing result is successful, the status of the branch transaction will be modified to ready to commit; if the first-phase business processing result is failed, the status of the branch transaction will be modified to ready to cancel.

[0151] 10. Local Transaction Manager

[0152] The local transaction manager of the distributed service node will roll back the local transaction when the first-phase business processing is abnormal. Moreover, if the exception occurs after the locking is completed, the local transaction manager will also call the post-transaction rollback processing to release the lock after the local transaction is rolled back. At this time, the lock release is an independent transaction and can be independently committed.

[0153] 11. Transaction Commit

[0154] The distributed service node will perform corresponding transaction commits based on the first-phase business processing results. For example, if the first-phase business processing result is successful, it will feedback success; if the first-phase business processing result is failed, it will feedback failure.

[0155] In summary, the first-phase business processing is completed. Next, the second-phase business processing is as follows:

[0156] It should be noted that Figure 6 the connection engine and the distributed transaction in refer to the overall coordination and management mechanism of the distributed transaction, which can be jointly implemented by the global transaction manager (such as the TM (Transaction Manager) and RM components (Resource Manager) of Seata) and the distributed transaction framework. Moreover, the second-phase business processing can be asynchronously performed by multiple distributed service nodes involved in the distributed transaction corresponding to the distributed service node.

[0157] As Figure 6 shown, in the second phase, the distributed service node can execute the confirm business processing (confim) or the cancel business processing (cancel), and after the second-phase business processing is completed, it will call the post-branch transaction processing to release the lock. At this time, the lock release is not an independent transaction and needs to be committed together with the transaction of the second-phase business processing.

[0158] Among them, whether the distributed service node executes the confirmation business process (confim) or the cancellation business process (cancel) is determined by the global transaction manager according to the first-phase business processing results of multiple distributed service nodes involved in the distributed transaction corresponding to the distributed service node. As a possible implementation, the global transaction manager may trigger the confirmation business process for each distributed service node involved in the distributed transaction corresponding to the distributed service node in response to the successful execution of the first-phase business processing results of each distributed service node involved in the distributed transaction corresponding to the distributed service node. Alternatively, in response to the failure of the first-phase business processing result of any distributed service node involved in the distributed transaction corresponding to the distributed service node, the global transaction manager may trigger the cancellation business process for each distributed service node involved in the distributed transaction corresponding to the distributed service node.

[0159] The release of the lock is uniformly triggered by the distributed transaction in the second phase, and the release of the lock is ensured by the exception handling mechanism of the distributed transaction. If the lock is not released, the distributed transaction has not ended, and at this time, the branch transaction has not ended. When a machine crashes after the first-phase lock addition (actively called by the business) is completed, it is impossible to rely on the release of the lock after the transaction rollback, resulting in the lock not being released. When another transaction performs lock addition, if the lock has expired, the branch transaction status will be queried according to the previous branch transaction flow. If the branch transaction status is empty, the expired record will be deleted. From this, it can be inferred that only when the machine crashes after the successful addition of the lock (independent transaction) in the first phase will the expired record be deleted during lock addition.

[0160] It should be noted that when the first phase ends normally, it will trigger the second phase of the distributed transaction. During the process of releasing the lock through the second phase of the distributed transaction, the following two points can be used to ensure that the release of the lock is consistent with the second-phase business processing status:

[0161] 1) Release the lock after the business processing is completed, that is, the lock will be released only after confim or cancel is executed;

[0162] 2) The second-phase lock release is a non-independent transaction. The transaction of the lock and the transaction of the business are submitted together. When the lock submission fails, it will cause the business processing to be abnormal.

[0163] If the lock addition in the first phase is abnormal during the business call, it will cause the rollback of the local transaction. The local transaction manager will call the post-transaction rollback processing to release the lock after the transaction rollback.

[0164] When a machine crashes after the first-phase lock addition is completed, the global transaction of the distributed transaction initiates a rollback at this time, and the current node will not trigger the second phase, resulting in the lock not being released. At this time, the lock addition interface queries the expired lock record. When there is an expired record, the branch transaction is queried according to the branch transaction ID of the expired record. If it is empty, it will be deleted.

[0165] The scenario application of the above process is as follows Figure 7 as shown Figure 7 In it, Try is the first stage, confim and cancel are the second stage. The locking operation is executed in Try, and the unlocking operation is executed in the transaction rollback handling and / or the branch transaction handling after the transaction rollback.

[0166] Corresponding to the distributed lock processing method provided in the above embodiment, the present disclosure also provides a distributed lock processing device. Since the distributed lock processing device provided in the embodiments of the present disclosure corresponds to the distributed lock processing method provided in the above embodiment, the implementation manners of the distributed lock processing method are also applicable to the distributed lock processing device provided in the embodiments of the present disclosure, and will not be described in detail in the embodiments of the present disclosure.

[0167] Figure 8 It is a schematic structural diagram of the distributed lock processing device shown in the eighth embodiment of the present disclosure.

[0168] As shown Figure 8 in the figure, the distributed lock processing device 800 includes: a first processing module 810, a second processing module 820, and a first lock release module 830.

[0169] Among them, the first processing module 810 is configured to, in response to receiving a transaction request sent by a transaction center, start a branch transaction and start a local transaction for database operations of a distributed service node in the branch transaction; the second processing module 820 is configured to execute first-stage service processing in the local transaction, and during the execution of the first-stage service processing, lock the shared resources involved in the first-stage service processing; the first lock release module 830 is configured to, in response to triggering second-stage service processing, after the second-stage service processing is completed, release the lock of the shared resources, and commit the transaction of releasing the lock of the shared resources and the transaction of the second-stage service processing together to ensure that the release of the lock is consistent with the state of the second-stage service processing.

[0170] As a possible implementation manner of the embodiments of the present disclosure, the second processing module 820 is configured to: during the execution of the first-stage service processing, call the locking interface provided by the distributed lock service to send a locking request to the distributed lock service, so that the distributed lock service locks the shared resources according to the resource identifier of the shared resources, the transaction identifier of the branch transaction, the lock type, and the locking time carried in the locking request, and based on the locking result, send a corresponding locking identifier to the distributed service node; receive the locking identifier sent by the distributed lock service, and in response to successful locking, continue to execute the first-stage service processing, or, in response to locking failure, wait for a set duration and re-lock the shared resources.

[0171] As a possible implementation manner of an embodiment of the present disclosure, the lock indication includes a lock success indication and a lock failure indication; the second processing module 820 is configured to: the distributed lock service determines whether there is a first lock record in the lock record table that is the same as the resource identifier carried in the lock request; if there is no first lock record, the distributed lock service adds a second lock record of the branch transaction for the shared resource in the lock record table and sends a lock success indication to the distributed service node; if there is a first lock record, the distributed lock service determines whether the lock type in the first lock record is compatible with the lock type carried in the lock request; if not, the distributed lock service determines whether the first lock record is an expired record; if it is an expired record, the distributed lock service first deletes the first lock record in the lock record table, then adds a second lock record in the lock record table, and sends a lock success indication to the distributed service node; if it is not an expired record, the distributed lock service determines that the lock addition fails and sends a lock failure indication to the distributed service node; if it is compatible, the distributed lock service determines whether the transaction identifier in the first lock record is the same as the transaction identifier carried in the lock request; if the same, the distributed lock service determines that the lock requested by the lock request is a reentrant lock, and determines whether it is necessary to update the lock time of the first lock record according to the lock time carried in the lock request, so as to, in response to updating the lock time of the first lock record, or without updating the lock time of the first lock record, send a lock success indication to the distributed service node; if not the same, the distributed lock service determines that the lock requested by the lock request is not a reentrant lock, and determines whether the first lock record is an expired record; if it is an expired record, the distributed lock service first deletes the first lock record in the lock record table, then adds a second lock record in the lock record table, and sends a lock success indication to the distributed service node; if it is not an expired record, the distributed lock service adds a second lock record in the lock record table and sends a lock success indication to the distributed service node.

[0172] As a possible implementation manner of an embodiment of the present disclosure, the second processing module 820 is configured to: the distributed lock service queries the status of the target transaction indicated by the transaction identifier recorded in the first lock record, so as to delete the first lock record in the lock record table when the status of the target transaction is empty.

[0173] As a possible implementation manner of an embodiment of the present disclosure, the first lock release module 830 is configured to: in response to triggering two-phase business processing, after the two-phase business processing is completed, send a lock release request to the distributed lock service, so that the distributed lock service deletes the lock record of the branch transaction for the shared resource in the lock record table according to the resource identifier of the shared resource and the transaction identifier of the branch transaction carried in the lock release request, and sends a lock release indication to the distributed service node; wherein, the lock release indication is used to indicate that the lock of the branch transaction for the shared resource has been released; receive the lock release indication sent by the distributed lock service.

[0174] As a possible implementation manner of an embodiment of the present disclosure, the above device further includes: a second lock release module, configured to trigger a local transaction rollback in response to an exception occurring in the subsequent-stage service processing after locking the shared resource, and release the lock of the shared resource after the local transaction rollback is completed.

[0175] As a possible implementation manner of an embodiment of the present disclosure, the locking of the shared resource and the release of the lock of the shared resource when triggering the local transaction rollback are in the same thread.

[0176] As a possible implementation manner of an embodiment of the present disclosure, the locking of the shared resource and the release of the lock of the shared resource when triggering the two-stage service processing are not in the same thread.

[0177] As a possible implementation manner of an embodiment of the present disclosure, the two-stage service processing is determined by the global transaction manager according to the first-stage service processing results of multiple distributed service nodes involved in the distributed transaction corresponding to the distributed service node; wherein, the two-stage service processing includes confirming to execute the service operation and canceling to execute the service operation; the global transaction manager triggers the confirmation to execute the service operation to each distributed service node in response to the first-stage service processing results of all distributed service nodes involved in the distributed transaction corresponding to the distributed service node being all successfully executed; the global transaction manager triggers the cancellation to execute the service operation to each distributed service node in response to the first-stage service processing result of any distributed service node involved in the distributed transaction corresponding to the distributed service node being executed unsuccessfully.

[0178] The distributed lock processing device of the embodiment of the present disclosure, by responding to a transaction request received from the transaction center, starts a branch transaction and starts a local transaction for the database operation of the distributed service node in the branch transaction; executes the first-stage service processing in the local transaction, and during the execution process of the first-stage service processing, locks the shared resources involved in the first-stage service processing; in response to triggering the two-stage service processing, after the two-stage service processing is completed, releases the lock of the shared resource, and commits the transaction of releasing the lock of the shared resource and the transaction of the two-stage service processing together to ensure that the release of the lock is consistent with the state of the two-stage service processing. Thus, by locking the shared resource in the first stage, it can be ensured that in concurrent transactions, the balance of the same account will not be modified by multiple transactions at the same time, ensuring data consistency and avoiding financial problems caused by inaccurate balances.

[0179] In an exemplary embodiment, an electronic device is further proposed.

[0180] Wherein, the electronic device includes:

[0181] a processor;

[0182] A memory for storing processor-executable instructions;

[0183] Wherein, the processor is configured to execute instructions to implement the distributed lock processing method proposed in any of the foregoing embodiments.

[0184] As an example, Figure 9 is a schematic structural diagram of an electronic device 900 shown in an exemplary embodiment of the present disclosure. As Figure 9 shown, the above-mentioned electronic device 900 may further include:

[0185] A memory 910 and a processor 920, a bus 930 connecting different components (including the memory 910 and the processor 920). The memory 910 stores a computer program, and when the processor 920 executes the program, the distributed lock processing method described in the embodiments of the present disclosure is implemented.

[0186] The bus 930 represents one or more of several types of bus structures, including a memory bus or a memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any bus structure in a variety of bus structures. For example, these architectures include, but are not limited to, Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MAC) bus, Enhanced ISA bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

[0187] The electronic device 900 typically includes a variety of electronically readable media. These media can be any available media that can be accessed by the electronic device 900, including volatile and non-volatile media, removable and non-removable media.

[0188] The memory 910 may further include a computer system readable medium in the form of volatile memory, such as random access memory (RAM) 940 and / or cache memory 950. The server 900 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 960 may be used to read and write non-removable, non-volatile magnetic media ( Figure 9 not shown, commonly referred to as a "hard disk drive packager"). Although Figure 9Not shown in the figure, a disk drive wrapper for reading and writing to a removable non-volatile disk (such as a "floppy disk") and an optical disk drive wrapper for reading and writing to a removable non-volatile optical disk (such as a CD-ROM, DVD-ROM or other optical medium) can be provided. In these cases, each drive wrapper can be connected to the bus 930 through one or more data medium interfaces. The memory 910 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present disclosure.

[0189] A program / utility 980 having a set (at least one) of program modules 970 can be stored, for example, in the memory 910. Such program modules 970 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include the implementation of a network environment. The program modules 970 generally perform the functions and / or methods in the embodiments described in the present disclosure.

[0190] The electronic device 900 can also communicate with one or more external devices 990 (such as a keyboard, a pointing device, a display 991, etc.), and can also communicate with one or more devices that enable a user to interact with the electronic device 900, and / or communicate with any device that enables the electronic device 900 to communicate with one or more other computing devices (such as a network card, a modem, etc.). Such communication can be carried out through the input / output (I / O) interface 992. Moreover, the electronic device 900 can also communicate with one or more networks (such as a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) through the network adapter 993. As shown in the figure, the network adapter 993 communicates with other modules of the electronic device 900 through the bus 930. It should be understood that although not shown in the figure, other hardware and / or software modules can be used in combination with the electronic device 900, including but not limited to: microcode, device drive wrappers, redundant processing units, external disk drive wrapper arrays, RAID systems, tape drive wrappers, and data backup storage systems, etc.

[0191] The processor 920 executes various functional applications and data processing by running the programs stored in the memory 910.

[0192] It should be noted that for the implementation process and technical principle of the electronic device in this embodiment, refer to the foregoing explanation of the method for handling distributed locks in the embodiments of the present disclosure, which will not be elaborated here.

[0193] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory including instructions, and the above instructions can be executed by a processor of an electronic device to implement the distributed lock processing method proposed in any of the above embodiments. Optionally, the computer-readable storage medium may be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0194] In an exemplary embodiment, a computer program product is also provided, including a computer program / instructions, characterized in that when the computer program / instructions are executed by a processor, the distributed lock processing method proposed in any of the above embodiments is implemented.

[0195] Those skilled in the art will readily conceive of other embodiments of the present disclosure after considering the specification and practicing the invention disclosed herein. The present disclosure is intended to cover any variations, uses, or adaptations of the present disclosure, which follow the general principles of the present disclosure and include known common general knowledge or conventional technical means in the technical field not disclosed in the present disclosure. The specification and embodiments are only to be regarded as exemplary, and the true scope and spirit of the present disclosure are pointed out by the following claims.

[0196] It should be understood that the present disclosure is not limited to the exact structures already described and shown in the drawings, and various modifications and changes can be made without departing from its scope. The scope of the present disclosure is only limited by the appended claims.

Claims

1. A distributed lock processing method, characterized in that: Applied to distributed service nodes, including: In response to receiving a transaction request sent by a transaction center, opening a branch transaction and opening a local transaction for a database operation of the distributed service node in the branch transaction; Execute a phase of business processing in the local transaction, and during the execution of the phase of business processing, lock the shared resources involved in the phase of business processing; In response to triggering the second-stage business processing, after the second-stage business processing is completed, the lock of the shared resource is released, and the transaction of releasing the lock of the shared resource is submitted together with the transaction of the second-stage business processing to ensure that the lock release is consistent with the state of the second-stage business processing.

2. The method according to claim 1, characterized in that During the execution of the business processing of the first phase, locking the shared resources involved in the business processing of the first phase includes: During the execution of the first-stage business processing, a lock interface provided by a distributed lock service is called to send a lock request to the distributed lock service, so that the distributed lock service locks the shared resource according to the resource identifier of the shared resource, the transaction identifier of the branch transaction, the lock type and the lock time carried in the lock request, and sends a corresponding lock identifier to the distributed service node based on the lock result; A lock identifier sent by the distributed lock service is received, and in response to a successful lock, the first-stage business processing is continued, or in response to a failed lock, a set time period is waited to re-lock the shared resource.

3. The method according to claim 2, characterized in that The lock identifier includes a lock success identifier and a lock failure identifier; the distributed lock service locks the shared resource according to the resource identifier of the shared resource carried in the lock request, the transaction identifier of the branch transaction, the lock type and the lock time, and sends a corresponding lock identifier to the distributed service node based on the lock result, including: The distributed lock service determines whether there is a first lock record in the lock record table with a resource identifier identical to the resource identifier carried in the lock request; If the first lock record does not exist, the distributed lock service adds a second lock record of the branch transaction on the shared resource in the lock record table, and sends the lock success identifier to the distributed service node; If the first lock record exists, the distributed lock service determines whether the lock type in the first lock record is compatible with the lock type carried in the lock request; If they are not compatible, the distributed lock service determines whether the first lock record is an expired record according to the locking time in the first lock record; If it is an expired record, the distributed lock service first deletes the first lock record in the lock record table, then adds the second lock record in the lock record table, and sends the lock success identifier to the distributed service node; If it is not an expired record, the distributed lock service determines that the locking has failed, and sends a locking failure flag to the distributed service node; If compatible, the distributed lock service determines whether the transaction identifier in the first lock record is the same as the transaction identifier carried in the lock request; If they are the same, the distributed lock service determines that the lock requested by the lock request is a reentrant lock, and determines whether it is necessary to update the lock time in the first lock record according to the lock time carried in the lock request, in response to updating the lock time in the first lock record, or, without updating the lock time in the first lock record, sends the lock success identifier to the distributed service node; If they are not the same, the distributed lock service determines that the lock requested by the lock request is not a reentrant lock, and determines whether the first lock record is an expired record according to the lock time in the first lock record; If it is an expired record, the distributed lock service first deletes the first lock record in the lock record table, then adds the second lock record in the lock record table, and sends the lock success identifier to the distributed service node; If it is not an expired record, the distributed lock service adds the second lock record to the lock record table and sends the lock success identifier to the distributed service node.

4. The method according to claim 3, characterized in that Before the distributed lock service deletes the first lock record in the lock record table, the method further includes: The distributed lock service queries the state of the target transaction indicated by the transaction identifier recorded in the first lock record, and deletes the first lock record in the lock record table if the state of the target transaction is empty.

5. The method according to claim 1, characterized in that In response to triggering the second-stage business processing, after the second-stage business processing is completed, releasing the lock of the shared resource includes: In response to triggering the second-stage business processing, after the second-stage business processing is completed, a lock release request is sent to the distributed lock service, so that the distributed lock service deletes the lock record of the branch transaction on the shared resource in the lock record table according to the resource identifier of the shared resource and the transaction identifier of the branch transaction carried in the lock release request, and sends a lock release identifier to the distributed service node; wherein the lock release identifier is used to indicate that the lock of the branch transaction on the shared resource has been released; Receive a lock release identifier sent by the distributed lock service.

6. The method according to claim 1, characterized in that The method further comprises: In response to an exception occurring in the business process of the first phase after the shared resource is locked, a local transaction is rolled back, and after the local transaction is rolled back, the lock of the shared resource is released.

7. The method according to claim 6, characterized in that The locking of the shared resource and the releasing of the lock of the shared resource when triggering the rollback of the local transaction are in the same thread.

8. The method according to any one of claims 1 to 7, characterized in that The locking of the shared resource and the releasing of the lock of the shared resource when triggering the second-stage business processing are not in the same thread.

9. The method according to any one of claims 1 to 7, characterized in that: The two-stage business processing includes confirming the execution of the business processing and canceling the execution of the business processing. The two-stage business processing executed by the distributed service node is determined by the global transaction manager according to the first-stage business processing results of multiple distributed service nodes involved in the distributed transaction corresponding to the distributed service node; In response to the first-stage business processing results of each distributed service node involved in the distributed transaction corresponding to the distributed service node being all successfully executed, the global transaction manager triggers confirmation of business processing execution to each distributed service node involved in the distributed transaction corresponding to the distributed service node; In response to a result of a phase of business processing of any distributed service node involved in the distributed transaction corresponding to the distributed service node being an execution failure, the global transaction manager triggers cancellation of business processing to each distributed service node involved in the distributed transaction corresponding to the distributed service node.

10. A distributed lock processing device, characterized in that: Applied to distributed service nodes, including: A first processing module, configured to, in response to receiving a transaction request sent by a transaction center, start a branch transaction and start a local transaction for a database operation of the distributed service node in the branch transaction; A second processing module is used to execute a phase of business processing in the local transaction, and during the execution of the phase of business processing, lock the shared resources involved in the phase of business processing; The first lock release module is used to respond to triggering the second-stage business processing, release the lock of the shared resource after the second-stage business processing is completed, and submit the transaction of the lock release of the shared resource together with the transaction of the second-stage business processing to ensure that the lock release is consistent with the state of the second-stage business processing.

Images