Method and device for realizing read-write lock based on ETCD and storage medium
By creating read-write lockKey and auxiliary key in the ETCD cluster and setting its mode, the complex problem of ETCD read-write lock acquisition scheme is solved, and a simplified lock acquisition process and a wider usage scenario are realized.
Patent Information
- Application Number
- CN202411146410.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-20
- Publication Date
- 2025-02-18
AI Technical Summary
In the prior art, the read and write lock scheme of ETCD is more complicated to obtain read locks and write locks. It is mainly because ETCD is a distributed system and needs to consider communication and synchronization between multiple nodes.
By enabling transactions in the ETCD cluster, create a read-write lock lockKey, and determine whether it is successfully obtained based on the lockKey version number, create an auxiliary key and set its mode to implement read-loop or write-loop operation.
It simplifies the process of acquiring read locks and write locks on the client, expands the usage scenarios and scope of ETCD distributed locks, and fully utilizes the high performance and high reliability of ETCD.
Smart Images
Figure CN119473641A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the technical field of implementing a read-write lock based on ETCD, and specifically, to a method, device, storage medium and electronic device for implementing a read-write lock based on ETCD. Background Art
[0002] When the system is deployed in a cluster or distributed form, if you want to achieve cross-process resource synchronization, you must rely on distributed locks. There are many distributed lock implementation schemes at present, such as distributed locks based on ZK, distributed locks based on Redis, distributed locks based on databases, etc. However, the existing schemes have certain limitations and disadvantages, such as ZK and relational databases have certain performance issues, and Redis has reliability issues. Based on this, a new component ETCD has emerged. ETCD is currently a popular distributed storage component that integrates the high performance of Redis (using KV storage) and draws on the high reliability of ZK. However, unlike ZK, which achieves strong consistency through self-developed ZAB, ETCD achieves consistency through the raft protocol and uses grpc based on HTTP2 to achieve communication, so its performance is better than ZK.
[0003] Currently, the read-write lock solution for etcd has the problem of complex acquisition of read locks and write locks. This is mainly because etcd is a distributed system that needs to consider communication and synchronization between multiple nodes. Summary of the invention
[0004] The main purpose of the present application is to provide a method, device, storage medium and electronic device for implementing a read-write lock based on ETCD, so as to at least solve the problem that the prior art read-write lock solution for ETCD is relatively complicated in acquiring read locks and write locks.
[0005] In order to achieve the above-mentioned purpose, according to one aspect of the present application, a method for implementing a read-write lock based on ETCD is provided, including: when a target client sends a request for a read lock or a write lock to an ETCD cluster in a transaction manner of ETCD, starting an ETCD transaction and creating a read-write lock lockKey; when the read-write lock lockKey is successfully created, determining whether the version number of the read-write lock lockKey is 1, and when it is determined that the version number of the read-write lock lockKey is 1, creating an auxiliary key, wherein the version number of the read-write lock lockKey is 1, indicating that the target client has successfully acquired the read lock or the write lock; setting the mode of the auxiliary key to a target mode to implement a read lock operation or a write lock operation of the target client, wherein the target mode includes a read lock mode and a write lock mode, the target mode corresponding to the read lock request is the read lock mode, and the target mode corresponding to the write lock request is the write lock mode.
[0006] Optionally, after determining whether the version number of the read-write lock lockKey is 1, the method further includes: when it is determined that the version number of the read-write lock lockKey is not 1 and the target client sends a read lock request to the ETCD cluster in the transaction mode of the ETCD, determining whether the lock held by other clients is a read lock according to the auxiliary key, wherein the version number of the read-write lock lockKey is not 1, which is used to characterize that the other clients have created the read-write lock lockKey and obtained the read lock or the write lock; when it is determined that the lock held by the other clients is the read lock, setting the lease of the read lock request of the target client to complete the read lock request of the target client.
[0007] Optionally, after determining whether the lock held by other clients is a read lock based on the auxiliary key, the method further includes: when it is determined that the lock held by the other clients is the write lock, using a Watch mechanism to monitor the target node to monitor whether the other clients have completed the write lock operation, wherein the target node is a node whose version number of the read-write lock lockKey is 1; when monitoring that the other clients have completed the write lock operation, waking up the read lock request of the target client.
[0008] Optionally, after determining whether the version number of the read-write lock lockKey is 1, the method further includes: when it is determined that the version number of the read-write lock lockKey is not 1, and the target client sends a write lock request to the ETCD cluster in the transaction mode of the ETCD, determining whether the write lock request of the target client is a fair lock; when it is determined that the write lock request sent by the target client is a fair lock, adding the write lock request of the target client to a waiting queue, and waiting for read lock operations or write lock operations from other clients in the order of the waiting queue.
[0009] Optionally, after determining whether the write lock request of the target client is a fair lock, the method further includes: when it is determined that the write lock request of the target client is an unfair lock, obtaining the lease of the lock held by the other client; and controlling the target client to obtain the write lock operation by long polling according to the lease.
[0010] Optionally, after implementing the write lock operation of the target client, the method further includes: when it is determined that the target client has completed the write lock operation, determining whether the target client continues to hold the lock; when it is determined whether the target client continues to hold the lock, downgrading the write lock of the target client to a read lock, and changing the write lock mode of the auxiliary key to the read lock mode.
[0011] Optionally, when it is determined that the target client completes the read lock operation, the read-write lock lockKey and the auxiliary key are deleted, and a node change event is sent to other clients listening to the read-write lock lockKey, wherein the node change event is a deletion event.
[0012] According to another aspect of the present application, a device for implementing a read-write lock based on ETCD is provided, comprising: a first creation unit, for starting an ETCD transaction and creating a read-write lock lockKey when receiving a request for a read lock or a write lock from a target client to an ETCD cluster in a transactional manner of ETCD; a second creation unit, for determining whether the version number of the read-write lock lockKey is 1 when the creation of the read-write lock lockKey is successful, and creating an auxiliary key when it is determined that the version number of the read-write lock lockKey is 1, wherein the version number of the read-write lock lockKey is 1, indicating that the target client has successfully acquired the read lock or the write lock; a setting unit, for setting the mode of the auxiliary key to a target mode to implement a read lock operation or a write lock operation of the target client, wherein the target mode includes a read lock mode and a write lock mode, the target mode corresponding to the read lock request is the read lock mode, and the target mode corresponding to the write lock request is the write lock mode.
[0013] According to another aspect of the present application, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes a stored program, wherein when the program is running, the device where the computer-readable storage medium is located is controlled to execute any one of the methods for implementing a read-write lock based on ETCD.
[0014] According to another aspect of the present application, an electronic device is provided, comprising: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and are configured to be executed by the one or more processors, and the one or more programs include a method for executing any one of the methods for implementing a read-write lock based on ETCD.
[0015] By applying the technical solution of the present application, when receiving a request for a read lock or a write lock from a target client to an ETCD cluster in the form of an ETCD transaction, an ETCD transaction is started to create a read-write lock lockKey; when the read-write lock lockKey is successfully created, it is determined whether the version number of the read-write lock lockKey is 1, and when it is determined that the version number of the read-write lock lockKey is 1, an auxiliary key is created, and the version number of the read-write lock lockKey is 1, indicating that the target client has successfully obtained a read lock or a write lock; the mode of the auxiliary key is set to the target mode to implement the read lock operation or the write lock operation of the target client. By utilizing ETCD transactions and double key values to implement the client's read lock request and write lock request, the use scenarios and scope of ETCD distributed locks are expanded, the high performance and high reliability of ETCD distributed locks are more fully utilized, and the existing process of ETCD clients obtaining read locks and write locks is simplified. BRIEF DESCRIPTION OF THE DRAWINGS
[0016] The drawings constituting part of the present application are used to provide a further understanding of the present application. The exemplary embodiments and descriptions of the present application are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:
[0017] Figure 1 A hardware structure block diagram of a mobile terminal for implementing a method for implementing a read-write lock based on ETCD according to an embodiment of the present application is shown;
[0018] Figure 2 A flow chart of a method for implementing a read-write lock based on ETCD according to an embodiment of the present application is shown;
[0019] Figure 3 The system architecture diagram of the ETCD distributed lock provided according to the embodiment of the present application is shown;
[0020] Figure 4 A schematic diagram of a read-write lock lockKey stored in ETCD according to an embodiment of the present application is shown;
[0021] Figure 5 A flowchart of obtaining a read lock based on ETCD according to an embodiment of the present application is shown;
[0022] Figure 6 A flowchart of obtaining a write lock based on ETCD according to an embodiment of the present application is shown;
[0023] Figure 7 The UML class diagram of the client SDK reader-writer lock provided according to the embodiment of the present application is shown;
[0024] Figure 8 A structural block diagram of a device for implementing a read-write lock based on ETCD provided according to an embodiment of the present application is shown. DETAILED DESCRIPTION
[0025] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.
[0026] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.
[0027] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present application described here. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.
[0028] For the convenience of description, some nouns or terms involved in the embodiments of the present application are explained below:
[0029] Distributed lock: Different from the lock within a process, the distributed lock is used in a distributed system or cluster to synchronize resources between different processes.
[0030] Read-write lock: The read-write lock is a combination of a shared lock and an exclusive lock. If a read-write lock is held, when there is only a read request, the read request holds a shared lock; when there is a write request, the write request holds an exclusive lock.
[0031] ETCD: A highly available Key / Value storage system, mainly used for shared configuration and service discovery.
[0032] Watch mechanism: A monitoring mechanism that can monitor a key or node in the system. When the monitored object changes, the system will actively send a node change event notification to the listener. This mechanism reduces the resource consumption caused by polling and avoids the herd effect. It is commonly used for Redis transaction monitoring, ZK node monitoring, and ETCD key monitoring.
[0033] Prefix mechanism: A prefix matching mechanism provided by etcd, which can find all existing key lists through prefixes.
[0034] Revision mechanism: For each key of ETCD, ETCD maintains a global Revision list. Every time a transaction is added, the revision is automatically increased by 1.
[0035] As introduced in the background technology, the existing read-write lock scheme for ETCD in the prior art has the problem that it is relatively complicated to obtain read lock and write lock. In order to solve the problem that the existing read-write lock scheme for ETCD in the prior art has the problem that it is relatively complicated to obtain read lock and write lock, the embodiments of the present application provide a method, device, storage medium and electronic device for implementing a read-write lock based on ETCD.
[0036] The technical solutions in the embodiments of the present invention will be described clearly and completely below in conjunction with the accompanying drawings in the embodiments of the present invention.
[0037] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking running on a mobile terminal as an example, Figure 1 1 is a hardware structure block diagram of a mobile terminal for implementing a method for a read-write lock based on ETCD according to an embodiment of the present invention. Figure 1 As shown, the mobile terminal may include one or more ( Figure 1 Only one is shown in the figure) a processor 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data, wherein the mobile terminal may also include a transmission device 106 and an input / output device 108 for communication functions. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the mobile terminal. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.
[0038] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the method for implementing a read-write lock based on ETCD in the embodiment of the present invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, the above method is implemented. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the above-mentioned network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof. The transmission device 106 is used to receive or send data via a network. The above-mentioned specific network example may include a wireless network provided by a communication provider of the mobile terminal. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.
[0039] In this embodiment, a method for implementing a read-write lock based on ETCD and running on a mobile terminal, a computer terminal or a similar computing device is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.
[0040] Figure 2 Flowchart of a method for implementing a read-write lock based on ETCD according to an embodiment of the present application. Figure 2 As shown, the method comprises the following steps:
[0041] Step S201, when receiving a request from the target client to send a read lock or write lock to the ETCD cluster in the transaction mode of ETCD, start the ETCD transaction and create a read-write lock lockKey;
[0042] Among them, ETCD is a distributed key-value storage system that supports ETCD transaction operations, which can ensure that a set of operations are either all executed successfully or all failed and rolled back. Therefore, the target client (integrated SDK) can use the transaction function of ETCD to ensure the consistency and reliability of data operations. This method will add a read lock in the read-write lock mode, and the SDK will send a request to ETCD in the transaction mode of ETCD, which is similar to the effect of Redis+lua.
[0043] In distributed locks, a unique key is usually used to identify the resource or object to be locked. This key is called the lock key. In addition to the lock key, an auxiliary key is sometimes used to identify the type or type of lock. Read locks and write locks are two different locks used to control read and write operations on resources. Read locks are usually shared locks. Multiple threads can hold read locks at the same time, but cannot hold write locks; write locks are usually exclusive locks. Only one thread can hold a write lock at the same time, and other threads can hold neither read locks nor write locks.
[0044] In distributed locks, resources are locked and unlocked through lock keys, which can support both read locks and write locks. The keys for read locks and write locks are generally lock keys plus a suffix to distinguish them. For example, for read locks, you can use lock key+":read", and for write locks, you can use lock key+":write". In this way, concurrent control of read and write operations on resources can be achieved.
[0045] Step S202: if the read-write lock lockKey is created successfully, determine whether the version number of the read-write lock lockKey is 1. If the version number of the read-write lock lockKey is determined to be 1, create an auxiliary key. The version number of the read-write lock lockKey is 1, indicating that the target client successfully obtains the read lock or write lock.
[0046] Specifically, when the current node successfully creates a lockkey and the version number Revision of this lockkey is the smallest (equal to 1), the read lock or write lock is successfully acquired.
[0047] Step S203, set the mode of the auxiliary key to the target mode to implement the read lock operation or write lock operation of the target client, wherein the target mode includes a read lock mode and a write lock mode, the target mode corresponding to the read lock request is the read lock mode, and the target mode corresponding to the write lock request is the write lock mode.
[0048] Among them, the ETCD pseudo DSL statement is:
[0049] Txn();
[0050] .If(CreateVersion(rwLockKey)=0and revision is minest);
[0051] .Then(OpPut(rwLockKey:mode,read));
[0052] .Else(OpPut(rwLockKey,UUID,other Operate);
[0053] Specifically, when the read lock or write lock is successfully obtained, and the second key (auxiliary key) is set to lock_key:mode in the same transaction, when the client requests a read lock and successfully obtains the read lock, the mode of the auxiliary key is set to read lock mode; when the client requests a write lock and successfully obtains the write lock, the mode of the auxiliary key is set to write lock mode.
[0054] Through this embodiment, when the target client sends a request for a read lock or a write lock to the ETCD cluster in the transaction mode of ETCD, the ETCD transaction is opened to create a read-write lock lockKey; when the read-write lock lockKey is successfully created, it is determined whether the version number of the read-write lock lockKey is 1. When it is determined that the version number of the read-write lock lockKey is 1, an auxiliary key is created, and the version number of the read-write lock lockKey is 1, indicating that the target client has successfully obtained the read lock or the write lock; the mode of the auxiliary key is set to the target mode to implement the read lock operation or the write lock operation of the target client. By using ETCD transactions and double key values to implement the client's read lock request and write lock request, the use scenarios and scope of ETCD distributed locks are expanded, the high performance and high reliability of ETCD distributed locks are more fully utilized, and the existing process of ETCD clients obtaining read locks and write locks is simplified.
[0055] During the specific implementation process, after determining whether the version number of the read-write lock lockKey is 1, the method also includes: when it is determined that the version number of the read-write lock lockKey is not 1, and the target client sends a read lock request to the ETCD cluster in the transaction mode of ETCD, determining whether the locks held by other clients are read locks according to the auxiliary key, wherein the version number of the read-write lock lockKey is not 1, which is used to represent that other clients have created a read-write lock lockKey and obtained a read lock or a write lock; when it is determined that the locks held by other clients are read locks, setting a lease for the read lock request of the target client to complete the read lock request of the target client.
[0056] When this method determines that the version number of the read-write lock lockKey is not 1, it means that other clients have created a read-write lock lockKey. At this time, it is necessary to determine whether the lock held by the other client that currently created this lockKey is a read lock or a write lock based on the auxiliary key; when the lock held is a read lock, it is a shared lock, the current target client can hold the lock, directly set the lease of the current node, and then return to successfully obtain the read lock.
[0057] Specifically, after determining whether the locks held by other clients are read locks based on the auxiliary key, the method also includes: when it is determined that the locks held by other clients are write locks, using the Watch mechanism to monitor the target node to monitor whether other clients have completed the write lock operation, wherein the target node is a node whose version number of the read-write lock lockKey is 1; when monitoring that other clients have completed the write lock operation, waking up the read lock request of the target client.
[0058] This method starts watching the first node (sorting all nodes of the current key in reverse order, the node with the smallest Revision is the first node, that is, the Revision number is 1) when it determines that the version number of the read-write lock lockKey is not 1, and the lock held by other clients that currently created this lockKey is a write lock, a mutually exclusive lock, and then wakes up directly when the locks held by other clients are released. The reason for monitoring the first node instead of the previous node is that in the scenario of more reading and less writing, when the write lock is released, all shared read locks need to be woken up.
[0059] More specifically, after determining whether the version number of the read-write lock lockKey is 1, the method also includes: when it is determined that the version number of the read-write lock lockKey is not 1, and the target client sends a write lock request to the ETCD cluster in an ETCD transaction mode, determining whether the write lock request of the target client is a fair lock; when it is determined that the write lock request sent by the target client is a fair lock, adding the write lock request of the target client to the waiting queue, and waiting for the read lock operation or write lock operation of other clients in the order of the waiting queue.
[0060] When this method determines that the version number of the read-write lock lockKey is not 1, it means that other clients have created a read-write lock lockKey. At this time, it is necessary to determine whether the write lock request of the target client is a fair lock. When it is determined that the write lock request of the target client is a fair lock, it is processed in the order of the requests. Only when the previous node of the target client is executed, the current node will be awakened, which reflects the fairness of first come first served.
[0061] Furthermore, after determining whether the write lock request of the target client is a fair lock, the method also includes: when determining that the write lock request of the target client is an unfair lock, obtaining the lease of the lock held by other clients; and controlling the target client to obtain the write lock operation using long polling according to the lease.
[0062] This method obtains the write lock by jumping the queue when it determines that the version number of the read-write lock lockKey is not 1 and that the write lock request of the target client is an unfair lock. That is, it hopes that the write lock can be obtained as early as possible. If other clients currently have locks, the lease of the lock holder is obtained and spin is started. When it is evaluated that the locks held by other clients are about to expire, long polling is used to try to obtain the write lock until the lock is successfully obtained or times out.
[0063] Furthermore, after implementing the write lock operation of the target client, the method also includes: when it is determined that the target client has completed the write lock operation, determining whether the target client continues to hold the lock; when it is determined whether the target client continues to hold the lock, downgrading the write lock of the target client to a read lock, and changing the write lock mode of the auxiliary key to a read lock mode.
[0064] After the target client completes the write lock operation, if you want to continue holding the lock, you can directly downgrade the write lock to a read lock, change the lock mode of the auxiliary key to a read lock, and publish a put event to wake up the listening node.
[0065] Specifically, after implementing the read lock operation of the target client, the method also includes: when it is determined that the target client has completed the read lock operation, deleting the read-write lock lockKey and the auxiliary key, and sending a node change event to other clients listening to the read-write lock lockKey, wherein the node change event is a deletion event.
[0066] After the target client completes the write lock operation, if the target client does not want to continue holding the lock, this method needs to release the lockKey currently holding the lock, publish a DELETE event to wake up the listening node, and delete the auxiliary key lockKey: mode.
[0067] In addition, after the target client completes the read lock operation, the read lock is released in the form of a Txn transaction. The lockKey:mode node is deleted, and the current / lockKey:rwLock / node is deleted at the same time. Then ETCD will send a node change event (the event sent at this time is DELETE) to all nodes that are watching the node, thereby waking up the Watch node.
[0068] The timings for releasing the read lock or write lock include: 1. completion of the task; 2. target client crashes; 3. the lock lease held by the target client expires.
[0069] In order to enable those skilled in the art to more clearly understand the technical solution of the present application, the implementation process of the method for implementing a read-write lock based on ETCD of the present application will be described in detail below in combination with specific embodiments.
[0070] At present, the use scenarios of distributed locks implemented based on ETCD are relatively simple, supporting only exclusive locks, and not shared locks or read-write locks. However, read-write locks are very common business scenarios in actual business. For example, when a business system uses distributed cache to improve system performance and has high requirements for data consistency, in order to balance performance and data consistency, read-write locks are needed. When there are only read requests, different processes or threads do not need to be mutually exclusive, and they can share the current lock; when there are write requests, other read requests or write requests will be blocked.
[0071] The prior art is related to the use of strings to replace corresponding lock resources based on DLM lock semantics and lock compatibility design. By designing a complete lock solution in Etcd for lock management initialization, lock resource competition processing, lock processing without lock competition, and lock processing of existing locks, rich lock semantics are provided for the Etcd lock solution, making it more convenient for Etcd to manage data storage; at the same time, the DLM complete lock semantic interface can be opened in the user state, and there is no need to call DLM in the kernel state, so the solution is simpler, more effective, and less complex. The present invention can be used in a variety of scenarios such as cluster management, storage resource management, and distributed lock management, and has great benefits in the direction of cloud computing and storage.
[0072] The existing technology also has a distributed lock based on Redis. Assuming that there are N Redis nodes, the process of obtaining a distributed lock based on the RedLock algorithm is as follows:
[0073] 1) First, get the current timestamp in milliseconds;
[0074] 2) The client acquires locks from all Redis instances in turn until it successfully acquires locks from more than half (N / 2+1) instances;
[0075] 3) At this time, the effective time of the lock is the initial effective time minus the time consumed to obtain the lock.
[0076] 4) If the client still fails to obtain more than half of the locks after polling all instances in the cluster, all previously obtained locks will be released, and the entire lock acquisition process will end in failure.
[0077] 5) If more than half of the locks are acquired and the last expiration time is valid, then the lock acquisition is considered successful.
[0078] The prior art has the following disadvantages:
[0079] 1) Many of the existing solutions are still based on various improvements of ZK and Redis, so they do not actually solve the problems they already have. For example, the implementation based on Redis needs to use the RedLock algorithm in cluster mode, but it cannot fully guarantee accuracy. This is mainly because it strictly relies on the clock. If the clock of some servers is abnormal, the distributed lock may be released in advance. This phenomenon can be avoided by using ETCD, because ETCD guarantees strong consistency and implements CP. Only when the Follower node synchronizes the Leader node data can it be considered successful.
[0080] 2) Compared with the gRPC communication protocol based on ETCD, the performance of the distributed lock based on Zookeeper is poor, and only the JAVA client provided by it can be used.
[0081] 3) The existing solution for ETCD distributed lock only provides basic lock implementation, namely exclusive lock mode, which cannot meet the multi-business scenarios in actual business needs.
[0082] This embodiment relates to a specific method for implementing a read-write lock based on ETCD, which supports both exclusive locks and read-write locks. At the same time, the write lock supports both fair locks and unfair locks, and the write lock also supports downgrade. This embodiment can expand the use scenarios and scope of ETCD distributed locks, and give full play to the high performance and high reliability of ETCD distributed locks. Specifically, it includes the following contents:
[0083] ETCD distributed read-write lock relies on the client SDK and ETCD service to be implemented at the same time. Its architecture is as follows Figure 3 As shown in the figure, in addition to the original exclusive lock occupation mode, the client can create a read-write lock according to actual needs. The characteristics of the etcd read-write lock include: read-read non-mutually exclusive, read-write mutually exclusive, write-read mutually exclusive, and write-write mutually exclusive.
[0084] The implementation process of the read-write lock mainly includes two parts: locking and releasing the read lock, and locking and releasing the write lock. Now assume that the key to be locked is lockKey. When a read-write lock is required, lockKey automatically becomes / lockKey:rwLock / . All lock requests in the read-write lock mode will be processed in the same way. The purpose is to distinguish it from the exclusive lock mode. The locking and releasing logic of the exclusive lock is completely independent and does not follow the following technical solution. In addition, it is necessary to introduce an auxiliary key, which can only be set or deleted by the node holding the current lock. It is used to record the lock mode of the current lock holder; such as Figure 4 The figure shows a schematic diagram of the read-write lock lockKey stored in ETCD.
[0085] The process diagram of the client obtaining a read lock is as follows Figure 5As shown, specifically including the following:
[0086] 1) When adding a read lock in read-write lock mode, the client SDK sends a request to ETCD in the transaction mode of ETCD, which is similar to the effect of Redis+lua.
[0087] 2) If the current node successfully creates the key and the Revision of this lockKey is the smallest (equal to 1), the read lock is successfully acquired, and the second key (auxiliary key) is set to lock_key: mode, value equal to read in the same transaction.
[0088] Among them, the ETCD pseudo DSL statement is:
[0089] Txn();
[0090] .If(CreateVersion(rwLockKey)=0and revision is minest);
[0091] .Then(OpPut(rwLockKey:mode,read));
[0092] .Else(OpPut(rwLockKey,UUID,other Operate);
[0093] 3) When adding a read lock, if the Revision is not the minimum (greater than 1), it proves that other nodes (clients) have created the lockkey. At this time, it is necessary to determine the lock mode of the locks currently held by other clients. If the mode of the current lock is = read, it proves that the current lock is a read lock, which is a shared lock. The current node can hold the lock, directly set the lease of the current node, and then return to successfully obtain the read lock; if the mode is = write at this time, it proves that the current lock is a write lock, a mutex lock. At this time, start Watching the first node (sort all nodes of the current key in reverse order, and the node with the smallest Revision is the first node). When the lock is released, it can be directly awakened. The reason for monitoring the first node instead of the previous node is that for scenarios with more reads and fewer writes, all shared read locks need to be awakened when the write lock is released.
[0094] Among them, the ETCD pseudo DSL statement is:
[0095] Txn();
[0096] .If(a node holding a lock already exists);
[0097] .Then (get the lock mode of the current lock node);
[0098] If (mode == read);
[0099] .then(return Success);
[0100] .Else(Watch first clientNode); );
[0102] 4) The read lock release process is:
[0103] Release the lock in the form of a Txn transaction. Delete the lockKey:mode node and the current / lockKey:rwLock / node. Then ETCD will send a node change event (the event sent at this time is DELETE) to all nodes that are watching the node, thereby waking up the Watch node.
[0104] The process diagram of the client obtaining a write lock is as follows: Figure 6 As shown, specifically including the following:
[0105] 1) When adding a write lock in read-write lock mode, the client SDK sends a request to ETCD in the transaction mode of ETCD;
[0106] 2) If the current node successfully creates a lockKey, and the obtained lockKey has the smallest Revision among all nodes (equal to 1), a write lock can be created directly. After successfully acquiring the write lock, the second key (auxiliary key) is set to lock_key:mode in the same transaction, with value equal to write, indicating that the current lock mode is write mode.
[0107] Among them, the ETCD pseudo DSL statement is:
[0108] Txn();
[0109] .If(Create_Version(rwLockKey)=0and revison is min);
[0110] .Then(OpPut(rwLockKey:mode,write));
[0111] .Else(OpPut(rwLockKey,UUID),OpPut(...));
[0112] 3) When the client adds a write lock, if the Revision is not the smallest, it means that another node (client) has created the key. Since write requests are mutually exclusive with all other requests, the client does not care what the current mode is, and determines whether the current client wants to implement an unfair lock or a fair lock.
[0113] If it is a fair lock, the write lock can directly watch the previous client node, that is, the last node in the Revision list that is smaller than itself. Only when the previous node is executed, the current node will be awakened, which reflects the fairness of first come first served;
[0114] If it is an unfair lock, that is, we hope that the write lock can be acquired as early as possible, if there is a lock currently, we will obtain the lease of the lock holder and start spinning. When it is evaluated that the current lock is about to expire, we will use long polling to try to acquire the write lock until the lock is acquired successfully or times out.
[0115] Among them, the ETCD pseudo DSL statement is:
[0116] Txn();
[0117] .If(a node holding a lock already exists);
[0118] .Then(find all revision lists and listen to the previous node or spin to acquire the lock));
[0119] 4) Write lock release lock process:
[0120] Through ETCD transaction operations, if the current client wants to continue holding the lock and completes the write operation, the write lock can be directly downgraded to a read lock, the lock mode of the auxiliary key can be changed to a read lock, and a put event can be published to wake up the listening node; if the lock is no longer held, the lockKey currently holding the lock needs to be released, a DELETE event can be published to wake up the listening node, and the auxiliary key lockKey:mode can be deleted.
[0121] The UML class diagram of the distributed lock SDK is as follows: Figure 7 As shown, specifically including the following:
[0122] Aiming at the distributed read-write lock function described above, we developed the ETCD distributed lock SDK.
[0123] The following interfaces and classes are mainly defined:
[0124] EtcdLock interface: defines the interface methods for locking and releasing locks;
[0125] EtcdAbstractLock abstract class: Based on the template design pattern, it defines the overall process of locking and releasing locks;
[0126] EtcdReadLock class: read lock implementation class;
[0127] EtcdWriteLock class: write lock implementation class;
[0128] EReadAndWriteLock interface: read-write lock interface;
[0129] EtcdReadAndWriteLock aggregation class: aggregates EtcdReadLock and EtcdWriteLock.
[0130] In order to avoid the thundering herd effect in the above embodiment, the above scenario is only applicable to the scenario with more reads than writes (for example, the read-write ratio is 5:1, 6:1, 10:1, etc.), otherwise please directly use the original mutex implementation method.
[0131] The embodiments of the present application support two implementation methods of fair locks and unfair locks, and provide a processing strategy for releasing the lock after successfully acquiring the write lock. It can support two implementation schemes: directly releasing the lock or downgrading to a read lock, and wake up all nodes in the Watch listening state by publishing a Put event or a Delete event; use ETCD transactions and double key values to complete the sharing of read locks; in addition, when the lock fails, the node range that the current node needs to Watch can be determined according to the current different lock holding modes; and the key value storage mode of the ETCD distributed lock is designed, and the design of the distributed lock is completed by introducing a single auxiliary key and cooperating with the lock key value list that conforms to the Prefix.
[0132] In addition, if we still use Zookeeper to implement distributed locks, we will definitely face the problem of poor performance, which will affect the overall performance of the system to a certain extent in high-concurrency scenarios, such as flash sales, big promotions and other activities; if we use the existing ETCD distributed lock solution, it will not be able to meet our diverse business scenario requirements and cannot support read-write locks.
[0133] The present invention implements a distributed read-write lock based on ETCD, which can meet complex business scenarios other than exclusive locks, while ensuring high performance and high reliability of distributed locks.
[0134] Another solution of the embodiment of the present application is: for reading and writing, two different keys are created respectively: / lockKey / read and / lockKey / write. Each time the operation of acquiring the lock is performed, these two key value lists are obtained and aggregated at the same time, and the read-write lock status of the aggregated list is used to determine whether the lock can be obtained and which node to watch.
[0135] The embodiment of the present application also provides a device for implementing a read-write lock based on ETCD. It should be noted that the device for implementing a read-write lock based on ETCD in the embodiment of the present application can be used to execute the method for implementing a read-write lock based on ETCD provided in the embodiment of the present application. The device is used to implement the above-mentioned embodiments and preferred implementation modes, and those that have been described will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware for a predetermined function. Although the device described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceived.
[0136] The following is an introduction to the device for implementing a read-write lock based on ETCD provided in an embodiment of the present application.
[0137] Figure 8 Schematic diagram of a device for implementing a read-write lock based on ETCD according to an embodiment of the present application. Figure 8 As shown, the device includes: a first creating unit 81, a second creating unit 82 and a setting unit 83.
[0138] The first creation unit 81 is used to start the ETCD transaction and create a read-write lock lockKey when receiving a request for a read lock or a write lock sent by the target client to the ETCD cluster in the transaction mode of ETCD;
[0139] Among them, ETCD is a distributed key-value storage system that supports ETCD transaction operations, which can ensure that a set of operations are either all executed successfully or all failed and rolled back. Therefore, the target client (integrated SDK) can use the transaction function of ETCD to ensure the consistency and reliability of data operations. When adding a read lock in the read-write lock mode, the SDK sends a request to ETCD in the transaction mode of ETCD, which is similar to the effect of Redis+lua.
[0140] The second creation unit 82 is used to determine whether the version number of the read-write lock lockKey is 1 when the read-write lock lockKey is successfully created, and to create an auxiliary key when it is determined that the version number of the read-write lock lockKey is 1. The version number of the read-write lock lockKey is 1, indicating that the target client successfully obtains the read lock or write lock;
[0141] Specifically, when the current node successfully creates a lockkey and the version number Revision of this lockkey is the smallest (equal to 1), the read lock or write lock is successfully acquired.
[0142] The first setting unit 83 is used to set the mode of the auxiliary key to a target mode to implement a read lock operation or a write lock operation of the target client, wherein the target mode includes a read lock mode and a write lock mode, and the target mode corresponding to the read lock request is the read lock mode, and the target mode corresponding to the write lock request is the write lock mode.
[0143] Specifically, when the read lock or write lock is successfully obtained, and the second key (auxiliary key) is set to lock_key:mode in the same transaction, when the client requests a read lock and successfully obtains the read lock, the mode of the auxiliary key is set to read lock mode; when the client requests a write lock and successfully obtains the write lock, the mode of the auxiliary key is set to write lock mode.
[0144] In this embodiment, the first creation unit is used to open the ETCD transaction and create the read-write lock lockKey when receiving the target client to send a read lock or write lock request to the ETCD cluster in the transaction mode of ETCD; the second creation unit is used to determine whether the version number of the read-write lock lockKey is 1 when the read-write lock lockKey is successfully created, and create an auxiliary key when the version number of the read-write lock lockKey is determined to be 1, and the version number of the read-write lock lockKey is 1, indicating that the target client successfully obtains the read lock or write lock; the first setting unit is used to set the mode of the auxiliary key to the target mode to implement the read lock operation or write lock operation of the target client, wherein the target mode includes the read lock mode and the write lock mode, the target mode corresponding to the read lock request is the read lock mode, and the target mode corresponding to the write lock request is the write lock mode. By using ETCD transactions and double key values to implement the client's read lock request and write lock request, the use scenario and scope of ETCD distributed locks are expanded, the high performance and high reliability of ETCD distributed locks are more fully utilized, and the existing process of ETCD clients obtaining read locks and write locks is simplified.
[0145] As an optional scheme, the device also includes a first determination unit and a first setting unit; the first determination unit is used to determine whether the locks held by other clients are read locks according to the auxiliary key after determining whether the version number of the read-write lock lockKey is 1, when it is determined that the version number of the read-write lock lockKey is not 1, and the target client sends a read lock request to the ETCD cluster in the transaction mode of ETCD, wherein the version number of the read-write lock lockKey is not 1, which is used to represent that other clients have created a read-write lock lockKey and obtained a read lock or a write lock; the first setting unit is used to set the lease of the read lock request of the target client to complete the read lock request of the target client when it is determined that the locks held by other clients are read locks.
[0146] Specifically, when it is determined that the version number of the read-write lock lockKey is not 1, it means that other clients have created a read-write lock lockKey. At this time, it is necessary to determine whether the lock held by the other client that currently created this lockKey is a read lock or a write lock based on the auxiliary key; when the lock held is a read lock, it is a shared lock, and the current target client can hold the lock, directly set the lease of the current node, and then return to successfully obtain the read lock.
[0147] An optional solution, the device also includes a monitoring unit and a wake-up unit, the monitoring unit is used to monitor the target node using a Watch mechanism to monitor whether other clients have completed the write lock operation after determining whether the lock held by other clients is a read lock based on the auxiliary key, when it is determined that the lock held by other clients is a write lock, wherein the target node is a node whose version number of the read-write lock lockKey is 1; the wake-up unit is used to wake up the target client's read lock request when monitoring other clients to complete the write lock operation.
[0148] Specifically, if it is determined that the version number of the read-write lock lockKey is not 1, and the lock held by other clients that currently create this lockKey is a write lock, a mutually exclusive lock, then start watching the first node (sort all nodes of the current key in reverse order, the node with the smallest Revision is the first node, that is, the version number Revision is 1), and when the locks held by other clients are released, they can be directly awakened. The reason for monitoring the first node instead of the previous node is that in the scenario of more reading and less writing, when the write lock is released, all shared read locks need to be awakened.
[0149] In an optional scheme, the device also includes a second determination unit and a third determination unit. The second determination unit is used to determine whether the write lock request of the target client is a fair lock after determining whether the version number of the read-write lock lockKey is 1, and when it is determined that the version number of the read-write lock lockKey is not 1, and the target client sends a write lock request to the ETCD cluster in an ETCD transaction mode; the third determination unit is used to add the write lock request of the target client to a waiting queue when it is determined that the write lock request sent by the target client is a fair lock, and wait for the read lock operation or write lock operation of other clients in the order of the waiting queue.
[0150] Specifically, when it is determined that the version number of the read-write lock lockKey is not 1, it means that other clients have created a read-write lock lockKey. At this time, it is necessary to determine whether the write lock request of the target client is a fair lock. When it is determined that the write lock request of the target client is a fair lock, it is processed in the order of the requests. Only when the previous node of the target client is executed, the current node will be awakened, which reflects the fairness of first come first served.
[0151] In an optional solution, the device also includes an acquisition unit and a control unit. The acquisition unit is used to determine whether the write lock request of the target client is a fair lock. The method also includes: when it is determined that the write lock request of the target client is an unfair lock, acquiring the lease of the lock held by other clients; the control unit is used to control the target client to obtain the write lock operation by long polling according to the lease.
[0152] Specifically, when it is determined that the version number of the read-write lock lockKey is not 1 and the write lock request of the target client is an unfair lock, the write lock is acquired by jumping the queue, that is, the write lock is expected to be acquired as early as possible. If other clients currently already have the lock, the lease of the lock holder is acquired and spin is started. When it is evaluated that the lock held by other clients is about to expire, long polling is used to try to acquire the write lock until the lock is successfully acquired or times out.
[0153] In an optional scheme, the device also includes a fourth determination unit and a change unit. The fourth determination unit is used to, after implementing the write lock operation of the target client, the method also includes: determining whether the target client continues to hold the lock when it is determined that the target client has completed the write lock operation; the change unit is used to downgrade the write lock of the target client to a read lock and change the write lock mode of the auxiliary key to a read lock mode when it is determined whether the target client continues to hold the lock.
[0154] Specifically, after the target client completes the write lock operation, if it wants to continue holding the lock, it can directly downgrade the write lock to a read lock, change the lock mode of the auxiliary key to a read lock, and publish a put event to wake up the listening node.
[0155] An optional solution, the device also includes a deletion unit, which is used to delete the read-write lock lockKey and the auxiliary key after implementing the read lock operation of the target client. The method also includes: when it is determined that the target client has completed the read lock operation, deleting the read-write lock lockKey and the auxiliary key, and sending a node change event to other clients listening to the read-write lock lockKey, wherein the node change event is a deletion event.
[0156] Specifically, after the target client completes the write lock operation, if the target client does not want to continue holding the lock, it is necessary to release the lockKey currently holding the lock, publish a DELETE event to wake up the listening node, and delete the auxiliary key lockKey: mode.
[0157] The device for implementing a read-write lock based on ETCD includes a processor and a memory, and the first creation unit, the second creation unit, and the setting unit are all stored in the memory as program units, and the processor executes the program units stored in the memory to implement corresponding functions. The above modules are all located in the same processor; or, the above modules are located in different processors in any combination.
[0158] The processor includes a kernel, which calls the corresponding program unit from the memory. One or more kernels can be set, and the problem of the existing technology of the read-write lock solution for etcd that it is complicated to obtain the read lock and write lock is solved by adjusting the kernel parameters.
[0159] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.
[0160] An embodiment of the present invention provides a computer-readable storage medium, which includes a stored program, wherein when the program is running, the device where the computer-readable storage medium is located is controlled to execute the method for implementing a read-write lock based on ETCD.
[0161] Specifically, the method for implementing a read-write lock based on ETCD includes:
[0162] Step S201, when receiving a request from the target client to send a read lock or write lock to the ETCD cluster in the transaction mode of ETCD, start the ETCD transaction and create a read-write lock lockKey;
[0163] Step S202: if the read-write lock lockKey is created successfully, determine whether the version number of the read-write lock lockKey is 1. If the version number of the read-write lock lockKey is determined to be 1, create an auxiliary key. The version number of the read-write lock lockKey is 1, indicating that the target client successfully obtains the read lock or write lock.
[0164] Step S203, set the mode of the auxiliary key to the target mode to implement the read lock operation or write lock operation of the target client, wherein the target mode includes a read lock mode and a write lock mode, the target mode corresponding to the read lock request is the read lock mode, and the target mode corresponding to the write lock request is the write lock mode.
[0165] An embodiment of the present invention provides a processor, which is used to run a program, wherein the method for implementing a read-write lock based on ETCD is executed when the program is running.
[0166] Specifically, the method for implementing a read-write lock based on ETCD includes:
[0167] Step S201, when receiving a request from the target client to send a read lock or write lock to the ETCD cluster in the transaction mode of ETCD, start the ETCD transaction and create a read-write lock lockKey;
[0168] Step S202: if the read-write lock lockKey is created successfully, determine whether the version number of the read-write lock lockKey is 1. If the version number of the read-write lock lockKey is determined to be 1, create an auxiliary key. The version number of the read-write lock lockKey is 1, indicating that the target client successfully obtains the read lock or write lock.
[0169] Step S203, set the mode of the auxiliary key to the target mode to implement the read lock operation or write lock operation of the target client, wherein the target mode includes a read lock mode and a write lock mode, the target mode corresponding to the read lock request is the read lock mode, and the target mode corresponding to the write lock request is the write lock mode.
[0170] An embodiment of the present invention provides a device, the device including a processor, a memory, and a program stored in the memory and executable on the processor, and when the processor executes the program, at least the following steps are implemented:
[0171] Step S201, when receiving a request from the target client to send a read lock or write lock to the ETCD cluster in the transaction mode of ETCD, start the ETCD transaction and create a read-write lock lockKey;
[0172] Step S202: if the read-write lock lockKey is created successfully, determine whether the version number of the read-write lock lockKey is 1. If the version number of the read-write lock lockKey is determined to be 1, create an auxiliary key. The version number of the read-write lock lockKey is 1, indicating that the target client successfully obtains the read lock or write lock.
[0173] Step S203, set the mode of the auxiliary key to the target mode to implement the read lock operation or write lock operation of the target client, wherein the target mode includes a read lock mode and a write lock mode, the target mode corresponding to the read lock request is the read lock mode, and the target mode corresponding to the write lock request is the write lock mode.
[0174] The devices in this article can be servers, PCs, PADs, mobile phones, etc.
[0175] The present application also provides a computer program product, which, when executed on a data processing device, is suitable for executing a program for initializing at least the following method steps:
[0176] Step S201, when receiving a request from the target client to send a read lock or write lock to the ETCD cluster in the transaction mode of ETCD, start the ETCD transaction and create a read-write lock lockKey;
[0177] Step S202: if the read-write lock lockKey is created successfully, determine whether the version number of the read-write lock lockKey is 1. If the version number of the read-write lock lockKey is determined to be 1, create an auxiliary key. The version number of the read-write lock lockKey is 1, indicating that the target client successfully obtains the read lock or write lock.
[0178] Step S203, set the mode of the auxiliary key to the target mode to implement the read lock operation or write lock operation of the target client, wherein the target mode includes a read lock mode and a write lock mode, the target mode corresponding to the read lock request is the read lock mode, and the target mode corresponding to the write lock request is the write lock mode.
[0179] Obviously, those skilled in the art should understand that the above modules or steps of the present invention can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order than here, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present invention is not limited to any specific combination of hardware and software.
[0180] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.
[0181] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.
[0182] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.
[0183] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.
[0184] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0185] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.
[0186] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.
[0187] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.
[0188] The above description is only the preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.
Claims
1. A method for implementing a read-write lock based on ETCD, characterized in that: include: When receiving a request for a read lock or a write lock from the target client to the ETCD cluster in the transaction mode of ETCD, start the ETCD transaction and create a read-write lock lockKey; If the read-write lock lockKey is created successfully, determine whether the version number of the read-write lock lockKey is 1, and if it is determined that the version number of the read-write lock lockKey is 1, create an auxiliary key, and the version number of the read-write lock lockKey is 1, indicating that the target client successfully obtains the read lock or the write lock; The mode of the auxiliary key is set to the target mode to implement the read lock operation or write lock operation of the target client, wherein the target mode includes a read lock mode and a write lock mode, the target mode corresponding to the read lock request is the read lock mode, and the target mode corresponding to the write lock request is the write lock mode.
2. The method according to claim 1, characterized in that After determining whether the version number of the read-write lock lockKey is 1, the method further includes: When it is determined that the version number of the read-write lock lockKey is not 1, and the target client sends a read lock request to the ETCD cluster in the transaction mode of the ETCD, determine whether the lock held by other clients is a read lock according to the auxiliary key, wherein the version number of the read-write lock lockKey is not 1, which is used to indicate that the other client has created the read-write lock lockKey and obtained the read lock or the write lock; When it is determined that the lock held by the other client is the read lock, a lease for the read lock request of the target client is set to complete the read lock request of the target client.
3. The method according to claim 2, characterized in that After determining whether the locks held by other clients are read locks according to the auxiliary key, the method further includes: When it is determined that the lock held by the other client is the write lock, a Watch mechanism is used to monitor the target node to monitor whether the other client completes the write lock operation, wherein the target node is a node whose version number of the read-write lock lockKey is 1; When monitoring that the other clients complete the write lock operation, the read lock request of the target client is awakened.
4. The method according to claim 1, characterized in that: After determining whether the version number of the read-write lock lockKey is 1, the method further includes: When it is determined that the version number of the read-write lock lockKey is not 1, and the target client sends a write lock request to the ETCD cluster in the transaction mode of the ETCD, determine whether the write lock request of the target client is a fair lock; When it is determined that the write lock request sent by the target client is a fair lock, the write lock request of the target client is added to a waiting queue, and waits for read lock operations or write lock operations of other clients in the order of the waiting queue.
5. The method according to claim 4, characterized in that After determining whether the write lock request of the target client is a fair lock, the method further includes: When it is determined that the write lock request of the target client is an unfair lock, acquiring a lease of the lock held by the other client; The target client is controlled according to the lease to obtain the write lock operation in a long polling manner.
6. The method according to claim 1, characterized in that After implementing the write lock operation of the target client, the method further includes: In the case of determining that the target client completes the write lock operation, determining whether the target client continues to hold the lock; When determining whether the target client continues to hold the lock, downgrade the write lock of the target client to a read lock, and change the write lock mode of the auxiliary key to the read lock mode.
7. The method according to claim 1, characterized in that After implementing the read lock operation of the target client, the method further includes: When it is determined that the target client completes the read lock operation, the read-write lock lockKey and the auxiliary key are deleted, and a node change event is sent to other clients listening to the read-write lock lockKey, wherein the node change event is a deletion event.
8. A device for implementing a read-write lock based on ETCD, characterized in that: include: The first creation unit is used to start the ETCD transaction and create a read-write lock lockKey when receiving a request for a read lock or a write lock sent by the target client to the ETCD cluster in the transaction mode of ETCD; A second creation unit is used to determine whether the version number of the read-write lock lockKey is 1 when the read-write lock lockKey is successfully created, and to create an auxiliary key when it is determined that the version number of the read-write lock lockKey is 1, wherein the version number of the read-write lock lockKey is 1, indicating that the target client successfully obtains the read lock or the write lock; The first setting unit is used to set the mode of the auxiliary key to a target mode to implement a read lock operation or a write lock operation of the target client, wherein the target mode includes a read lock mode and a write lock mode, the target mode corresponding to the read lock request is the read lock mode, and the target mode corresponding to the write lock request is the write lock mode.
9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein when the program is executed, the device where the computer-readable storage medium is located is controlled to execute the method for implementing a read-write lock based on ETCD as described in any one of claims 1 to 7.
10. An electronic device, characterized in that: include: One or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and are configured to be executed by the one or more processors, and the one or more programs include a method for executing the method for implementing a read-write lock based on ETCD as described in any one of claims 1 to 7.