CN111258771A - Method and system for realizing distributed lock based on Raft algorithm - Google Patents
Method and system for realizing distributed lock based on Raft algorithm Download PDFInfo
- Publication number
- CN111258771A CN111258771A CN202010048471.5A CN202010048471A CN111258771A CN 111258771 A CN111258771 A CN 111258771A CN 202010048471 A CN202010048471 A CN 202010048471A CN 111258771 A CN111258771 A CN 111258771A
- Authority
- CN
- China
- Prior art keywords
- lock
- client
- log information
- revision number
- value pair
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 37
- 230000001174 ascending effect Effects 0.000 claims description 5
- 238000012544 monitoring process Methods 0.000 claims description 5
- 238000003745 diagnosis Methods 0.000 claims description 3
- 238000010586 diagram Methods 0.000 description 3
- 239000000284 extract Substances 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Storage Device Security (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention discloses a distributed lock realization method and a system based on a Raft algorithm, wherein the method comprises the steps of firstly receiving lock acquisition request information of a first lock sent by a first client; generating first log information and a key value pair list according to the locking request information; the key-value pair list comprises a plurality of log information, and each log information corresponds to a revision number; and determining whether the first client obtains the operation authority of the first lock according to the first revision number of the first log information and the minimum second revision number in the key-value pair list. By adopting the technical scheme of the invention, the condition that a plurality of clients operate the same lock at the same time can be avoided, so that only one client holds the same lock at the same time, and the data consistency is further improved.
Description
Technical Field
The invention relates to the technical field of computers, in particular to a distributed lock implementation method and system based on a Raft algorithm.
Background
Under a modern distributed architecture, most large websites adopt a distributed cluster mode, however, under the distributed cluster mode, resource competition exists among clients, and uncontrollable resource competition causes flow blockage and blocking of the operation of the clients, thereby reducing the overall performance of the system.
In the prior art, a distributed lock based on a Redis algorithm is adopted to achieve data consistency, so that the problem of resource competition in a distributed scene is solved, and the specific work flow is as follows:
step 1, a client requests a server for SETNX to request to occupy a resource zone bit, and if the client successfully occupies the space, a distributed lock is obtained; and if the client side fails to occupy the space, waiting for the next preemption.
And 2, setting expiration time by using an EXPIRE method after the client occupies the distributed lock, and automatically deleting the distributed lock by the system to release resources when the time for the client to occupy the distributed lock is greater than the expiration time.
And 3, after the resources are released, other clients continue to poll and preempt the distributed locks, and the steps 1 and 2 are repeated to realize data consistency.
During the research process of the invention, the inventor finds that the distributed lock based on the Redis algorithm has at least the following problems:
1. each client can be connected with the redis server, and the request occupies the same lock resource, so that the same lock at the same time cannot be guaranteed, and only one client can own the same lock. Moreover, other clients may delete the current valid lock.
2. If the SETNX is down or blocked in the execution process, the client cannot acquire the lock.
3. If a downtime phenomenon occurs before the EXPIRE method is executed after the SETNX is successfully executed, a deadlock phenomenon will occur.
4. Redis is a single-process implementation component, and the string of LOCK can only be set in SETNX of a single machine, and the information of the LOCK node cannot be synchronized to each client in time.
5. The Redis cluster uses asynchronous replication, and under the condition that a server is down, lock data is lost, so that the lock cannot be normally unlocked, and deadlock is generated.
Disclosure of Invention
The embodiment of the invention provides a distributed lock implementation method and system based on a Raft algorithm, which can prevent a plurality of clients from operating the same lock at the same time, so that only one client holds the same lock at the same time, and the data consistency is further improved.
In order to solve the above technical problem, an embodiment of the present invention provides a method for implementing a distributed lock based on a Raft algorithm, including:
the server receives locking request information of a first lock sent by a first client;
generating first log information and a key value pair list according to the locking request information; the key-value pair list comprises a plurality of log information, and each log information corresponds to a revision number;
and determining whether the first client side obtains the operation authority of the first lock or not according to the first revision number of the first log information and the minimum second revision number in the key-value pair list.
As a preferred scheme, the generating, according to the locking request information, first log information specifically includes:
generating first log information according to a prefix path of a first lock in the lock acquisition request and an identifier of a first client; wherein the first log information includes a first option number, a first index number, and a first revision number.
As a preferred scheme, the generating a key-value pair list according to the locking request information specifically includes:
and acquiring all log information which is the same as the prefix path of the first lock in the locking request information according to the prefix path of the first lock, and arranging the log information in an ascending order according to the size of the revision number to form the key value pair list.
Preferably, the determining, according to the first revision number of the first log information and the minimum second revision number in the key-value pair list, whether the first client obtains the operation permission of the first lock specifically includes:
if the first revision number is equal to the second revision number, the first client obtains the operation authority of the first lock;
if the first revision number is larger than the second revision number, acquiring a first position of the first revision number in a key-value pair list according to the first revision number;
and monitoring a second client corresponding to a position before the first position in the key-value pair list according to the first position, and once the second client releases the first lock, the first client obtains the operation authority of the first lock.
Preferably, after the first client obtains the operation right of the first lock, the method further includes:
if the time that the first client obtains the operation authority of the first lock exceeds a preset lease, deleting the first lock so that other clients apply to reestablish the first lock or the other clients freely call the data resource corresponding to the first lock;
and if the time for the first client to obtain the operation permission of the first lock does not exceed the preset lease, the first client automatically releases the first lock after the first client completes the business operation corresponding to the first lock, so that other clients can obtain the operation permission of the first lock.
As a preferred scheme, before the server receives the lock acquisition request information of the first lock sent by the first client, the method further includes:
the server receives locking request information sent by any client;
and creating the first lock according to the locking request information.
Preferably, after the first log information is generated, the method further includes:
the server copies the first log information to a candidate server so that the first log information is not lost when the server is down.
As a preferred scheme, when the server is down, the candidate server corresponding to the log information with the largest expiration number and the largest index number is used as a new server.
Correspondingly, the invention also provides a system for realizing the distributed lock based on the Raft algorithm, which comprises the following steps:
the receiving module is used for receiving lock acquisition request information of a first lock sent by a first client;
the data generation module is used for generating first log information and a key value pair list according to the locking request information; the key-value pair list comprises a plurality of log information, and each log information corresponds to a revision number;
and the diagnosis module is used for determining whether the first client side obtains the operation authority of the first lock according to the first revision number of the first log information and the minimum second revision number in the key-value pair list.
The embodiment of the invention has the following beneficial effects:
the distributed lock implementation method based on the Raft algorithm provided by the embodiment of the invention comprises the steps of firstly receiving lock acquisition request information of a first lock sent by a first client; generating first log information and a key value pair list according to the locking request information; the key-value pair list comprises a plurality of log information, and each log information corresponds to a revision number; and determining whether the first client obtains the operation authority of the first lock according to the first revision number of the first log information and the minimum second revision number in the key-value pair list. Compared with the prior art that the consistency of data is realized by adopting a distributed lock based on a Redis algorithm, each client in the technical scheme of the invention compares the revision number of the current operation with the revision number in the key value pair list so as to determine whether to obtain the operation permission of the lock.
Drawings
FIG. 1 is a schematic flow chart diagram of a first embodiment of a distributed lock implementation method based on a Raft algorithm provided by the invention;
fig. 2 is a schematic structural diagram of a second embodiment of the system for implementing a distributed lock based on a Raft algorithm provided by the invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
It should be noted that the terms "first," "second," and the like in the description of the present invention are used for distinguishing between the description and not necessarily for indicating or implying relative importance.
The first embodiment:
referring to fig. 1, it is a schematic flowchart of an embodiment of a method for implementing a distributed lock based on a Raft algorithm provided in the present invention. As shown in fig. 1, the construction method includes steps 101 to 103, and each step is as follows:
step 101: and the server receives locking request information of the first lock sent by the first client.
In this embodiment, step 101 specifically includes: the server receives locking request information of a first lock sent by a first client; the locking request information of the first lock comprises a first lock prefix path and a first client identifier. For example, the prefix path of the first lock is/lock/samp, and the first client identifier is UUIDAA; therefore, the lock acquisition request information of the first lock is/lock/samp + UUIDA. It should be noted that the prefix path of the first lock is represented as the storage address of the first lock in the server, and the client identifier is determined by the UUID method, so that the identifier of each client is unique.
In this embodiment, before the server receives the lock acquisition request information of the first lock sent by the first client, the server first receives the locking request information sent by the client, and creates the first lock according to the locking request information, where the locking request information includes locking data and a first lock name. For example, the locking request message sent by the ith client includes the first data and the first lock name samp, and then a lock named samp is created according to the first data and the first lock name samp and stored in the storage path of lock, so that the prefix path of the first lock is/lock/samp; it should be noted that the first data represents any data to be locked, the first lock represents a lock corresponding to the first data, the first client represents any client that sends locking request information or locking request information to the server, and it should be noted that, after the first lock is successfully created, a lease is set on the first lock, so that when the time for the first client to acquire the operation right of the first lock exceeds the lease, other clients cannot acquire the operation right of the first lock.
Step 102: generating first log information and a key value pair list according to the locking request information; the key-value pair list comprises a plurality of log information, and each log information corresponds to a revision number.
In this embodiment, step 102 specifically includes: and automatically generating first log information according to the prefix path of the first lock in the locking request and the identification of the first client. The log information includes an option number, an index number, and a revision number, and it should be noted that the option number is an option identifier of the server, for example, the option number of the current server is 1, the option number in the log information generated by the server is 1, and then the server goes down, the cluster autonomously selects a new server, so the option number of the new server is 2, and the option number of the generated log information is also 2. The index number is the number of the data item. The revision number is globally unique, and each time log information is generated, the client accesses the server, and the server assigns the log information to the client, one is added on the basis of the global revision number. After the first log information is generated, the server stores the first log information in its own log storage module, and also returns the first log information to the first client and stores the first log information in the log storage module of the first client.
In this embodiment, according to the locking request information, a key-value pair list is generated, which specifically includes: and according to the prefix path of the first lock in the locking request information, acquiring all log information which is the same as the prefix path of the first lock in a log storage module of the server, and arranging the log information according to the size of the revision number in ascending order to form a key value pair list.
Step 103: and determining whether the first client obtains the operation authority of the first lock according to the first revision number of the first log information and the minimum second revision number in the key-value pair list.
In this embodiment, step 103 specifically includes: if the first revision number is equal to the second revision number, the first client obtains the operation authority of the first lock; if the first revision number is larger than the second revision number, acquiring a first position of the first revision number in the key-value pair list according to the first revision number; and monitoring a second client corresponding to the position before the first position in the key value pair list according to the first position, and obtaining the operation authority of the first lock by the first client once the first lock is released by the second client.
In this embodiment, the client determines whether the revision number of the client is equal to the minimum revision number in the key-value pair list or not through the revision number in the key-value pair list, and determines whether the client obtains the operation right of the lock, so that the multiple clients are prevented from obtaining the operation right of the same lock in the same time, the lock obtaining and the unlocking are performed by the same client, and the consistency of data is improved.
In this embodiment, when the first client finds that the revision number currently operated is not equal to the revision number of the minimum in the key-value pair list, a first position of the first revision number in the key-value pair list is obtained; according to the first position, extracting second log information of a position before the first position in the key-value pair list, and monitoring a second client corresponding to the second log information; once the second client releases the first lock, the first client obtains the operation permission of the first lock, so that the client can wait by only sending the lock acquisition request information to the server once, and the occurrence of frightening group effect caused by the fact that the client continuously sends the lock acquisition request information to the server is avoided.
In this embodiment, after the first client obtains the operation permission of the first lock, if the time for the first client to obtain the operation permission of the first lock exceeds a preset lease, the first lock is deleted, so that other clients apply for re-creating the first lock or other clients freely call a data resource corresponding to the first lock; and if the time for the first client to obtain the operation permission of the first lock does not exceed the preset lease, the first client automatically releases the first lock after the first client completes the business operation corresponding to the first lock, so that other clients can obtain the operation permission of the first lock. By setting a lease on the lock, even if the client does not normally release the lock, the normal operation of locking, locking and unlocking services of other clients can be ensured after the lease.
In this embodiment, when the server is down, the candidate server corresponding to the log information with the largest expiration number and the largest index number is marked as a new server. The method specifically comprises the following steps: and each client arranges all log information in the log storage module in an ascending order according to the size of the revision number, extracts the last log information of each candidate server, respectively compares the option number and the index number of the last log information, and marks the candidate server with the largest option number and the largest index number as a new server.
In this embodiment, when the server is down, the system does not fail to perform the corresponding data locking operation due to the down of the server, but a new server is reselected from the candidate servers, and the server continues to receive the request operation of the client, so that the stability of the system is improved. In addition, the server synchronizes the generated log information to the storage module of each candidate server, and once the server goes down, the new server extracts all the log information from the storage module to the log storage module, so that the client can compare the current log information with the log information of the key value pair list in the server.
To better illustrate the flow and principles of the present embodiment, the following example serves as a detailed description:
the method comprises the following steps: the server receives a locking request sent by the client, wherein the locking request is 'first data + samp', a lock named samp is created according to the locking request and is stored in a storage path/lock/samp of the server, and a lease is set for the samp lock.
Step two: when the server receives the lock acquisition request information of the client samp lock; the lock acquisition request information is/lock/samp + UUIDA, the server automatically generates first log information according to the lock acquisition request information, and it needs to be noted that the log information comprises an option number, an index number and a revision number, and the log information corresponding to each lock is globally unique. After generating the log information, the server not only stores the first log information in its own log storage module, but also transmits the first log information back to the first client and saves it in the log storage module of the first client.
Step three: the client side obtains all log information which is the same as the prefix path of the samp lock according to the prefix path/lock/samp of the samp lock, and arranges the log information in an ascending order according to the size of the revision number to form a key-value pair list, and obtains the log information with the minimum revision number from the key-value pair list.
Step four: comparing the first revision number of the first log information with the minimum second revision number in the key value pair list, and if the first revision number is equal to the second revision number, the first client side obtains the operation authority of the first lock; if the first revision number is larger than the second revision number, acquiring a first position of the first revision number in the key-value pair list according to the first revision number; monitoring a second client corresponding to a position before the first position in the key-value pair list according to the first position; and once the second client releases the first lock, the first client obtains the operation authority of the first lock.
Step five: after the first client obtains the operation authority of the first lock, if the time for the first client to obtain the operation authority of the first lock exceeds a preset lease, deleting the first lock so that other clients can apply for recreating the first lock or other clients can freely call first data corresponding to the first lock; and if the time for the first client to obtain the operation permission of the first lock does not exceed the preset lease, the first client automatically releases the first lock after the first client completes the business operation corresponding to the first lock, so that other clients can obtain the operation permission of the first lock.
In view of the above, in the implementation method of the distributed lock based on the Raft algorithm provided in the embodiment of the present invention, the method first receives lock acquisition request information of a first lock sent by a first client; generating first log information and a key value pair list according to the locking request information; the key-value pair list comprises a plurality of log information, and each log information corresponds to a revision number; and determining whether the first client obtains the operation authority of the first lock according to the first revision number of the first log information and the minimum second revision number in the key-value pair list. Compared with the prior art that the consistency of data is realized by adopting a distributed lock based on a Redis algorithm, each client in the technical scheme of the invention compares the revision number of the current operation with the revision number in the key value pair list so as to determine whether to obtain the operation permission of the lock.
Second embodiment:
fig. 2 is a schematic structural diagram of a system for implementing a distributed lock based on a Raft algorithm according to a second embodiment of the present invention, where the system includes a receiving module 201, a data generating module 202, and a diagnosing module 203.
A receiving module 201, configured to receive lock acquisition request information of a first lock sent by a first client;
the data generation module 202 is configured to generate first log information and a key-value pair list according to the locking request information; the key-value pair list comprises a plurality of log information, and each log information corresponds to a revision number;
and the diagnosis module 203 is used for determining whether the first client obtains the operation authority of the first lock according to the first revision number of the first log information and the minimum second revision number in the key value pair list.
The more detailed working principle and flow of this embodiment can refer to, but are not limited to, the implementation method of the distributed lock based on the Raft algorithm of the first embodiment.
Compared with the prior art that the consistency of data is realized by adopting a distributed lock based on a Redis algorithm, each client in the technical scheme of the invention compares the revision number of the current operation with the revision numbers in the key value pair list so as to determine whether to obtain the operation authority of the lock, and the technical scheme of the invention effectively prevents a plurality of clients from obtaining the operation authority of the same lock in the same time, so that the lock obtaining and the unlocking are the same client operation, and the consistency of the data is improved.
It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware related to instructions of a computer program, and the program can be stored in a computer readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), or the like.
The foregoing is a preferred embodiment of the present invention, and it should be noted that it would be apparent to those skilled in the art that various modifications and enhancements can be made without departing from the principles of the invention, and such modifications and enhancements are also considered to be within the scope of the invention.
Claims (9)
1. A distributed lock implementation method based on a Raft algorithm is characterized by comprising the following steps:
the server receives locking request information of a first lock sent by a first client;
generating first log information and a key value pair list according to the locking request information; the key-value pair list comprises a plurality of log information, and each log information corresponds to a revision number;
and determining whether the first client side obtains the operation authority of the first lock or not according to the first revision number of the first log information and the minimum second revision number in the key-value pair list.
2. A method for implementing a distributed lock based on a Raft algorithm as claimed in claim 1, wherein the generating of the first log information according to the lock acquisition request information specifically includes:
generating first log information according to a prefix path of a first lock in the lock acquisition request and an identifier of a first client; wherein the first log information includes a first option number, a first index number, and a first revision number.
3. The method for implementing a distributed lock based on a Raft algorithm as recited in claim 1, wherein the generating a key-value pair list according to the lock acquisition request information specifically comprises:
and acquiring all log information which is the same as the prefix path of the first lock in the locking request information according to the prefix path of the first lock, and arranging the log information in an ascending order according to the size of the revision number to form the key value pair list.
4. A method for implementing a distributed lock based on a Raft algorithm as claimed in claim 3, wherein the determining whether the first client obtains the operation authority of the first lock is performed according to a first revision number of the first log information and a minimum second revision number in the key-value pair list, specifically:
if the first revision number is equal to the second revision number, the first client obtains the operation authority of the first lock;
if the first revision number is larger than the second revision number, acquiring a first position of the first revision number in a key-value pair list according to the first revision number;
and monitoring a second client corresponding to a position before the first position in the key-value pair list according to the first position, and once the second client releases the first lock, the first client obtains the operation authority of the first lock.
5. A method for implementing a distributed lock based on a Raft algorithm as claimed in claim 4, wherein after the first client obtains the operation right of the first lock, further comprising:
if the time that the first client obtains the operation authority of the first lock exceeds a preset lease, deleting the first lock so that other clients apply to reestablish the first lock or the other clients freely call the data resource corresponding to the first lock;
and if the time for the first client to obtain the operation permission of the first lock does not exceed the preset lease, the first client automatically releases the first lock after the first client completes the business operation corresponding to the first lock, so that other clients can obtain the operation permission of the first lock.
6. A method for implementing a distributed lock based on a Raft algorithm as claimed in claim 5, wherein before the server receives the lock acquisition request information of the first lock sent by the first client, the method further comprises:
the server receives locking request information sent by any client;
and creating the first lock according to the locking request information.
7. A method for implementing a distributed lock based on a Raft algorithm as recited in claim 1, further comprising, after generating the first log information:
the server copies the first log information to a candidate server so that the first log information is not lost when the server is down.
8. A method for implementing a distributed lock based on a Raft algorithm as claimed in any one of claims 1-7, wherein when the server is down, the candidate server corresponding to the log information with the largest expiration number and the largest index number is used as a new server.
9. A distributed lock implementation system based on a Raft algorithm is characterized by comprising:
the receiving module is used for receiving lock acquisition request information of a first lock sent by a first client;
the data generation module is used for generating first log information and a key value pair list according to the locking request information; the key-value pair list comprises a plurality of log information, and each log information corresponds to a revision number;
and the diagnosis module is used for determining whether the first client side obtains the operation authority of the first lock according to the first revision number of the first log information and the minimum second revision number in the key-value pair list.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010048471.5A CN111258771A (en) | 2020-01-16 | 2020-01-16 | Method and system for realizing distributed lock based on Raft algorithm |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010048471.5A CN111258771A (en) | 2020-01-16 | 2020-01-16 | Method and system for realizing distributed lock based on Raft algorithm |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111258771A true CN111258771A (en) | 2020-06-09 |
Family
ID=70950748
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010048471.5A Pending CN111258771A (en) | 2020-01-16 | 2020-01-16 | Method and system for realizing distributed lock based on Raft algorithm |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111258771A (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111782669A (en) * | 2020-06-28 | 2020-10-16 | 百度在线网络技术（北京）有限公司 | Method and device for realizing distributed lock and electronic equipment |
| CN111930503A (en) * | 2020-08-05 | 2020-11-13 | 浪潮云信息技术股份公司 | Resource lock acquisition method based on ETCD |
| CN115051913A (en) * | 2022-08-12 | 2022-09-13 | 杭州悦数科技有限公司 | Method and device for changing Raft configuration |
| CN116938881A (en) * | 2023-09-18 | 2023-10-24 | 深圳创新科技术有限公司 | Method, system, equipment and readable storage medium for realizing dynamic IP pool |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108874552A (en) * | 2018-06-28 | 2018-11-23 | 杭州云英网络科技有限公司 | Distributed lock executes method, apparatus and system, application server and storage medium |
| US20190079726A1 (en) * | 2017-09-08 | 2019-03-14 | EMC IP Holding Company LLC | Mitigating causality discrepancies caused by stale versioning |
| US10534756B1 (en) * | 2016-04-27 | 2020-01-14 | Google Llc | Systems and methods for cross-referencing electronic documents on distributed storage servers |
-
2020
- 2020-01-16 CN CN202010048471.5A patent/CN111258771A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10534756B1 (en) * | 2016-04-27 | 2020-01-14 | Google Llc | Systems and methods for cross-referencing electronic documents on distributed storage servers |
| US20190079726A1 (en) * | 2017-09-08 | 2019-03-14 | EMC IP Holding Company LLC | Mitigating causality discrepancies caused by stale versioning |
| CN108874552A (en) * | 2018-06-28 | 2018-11-23 | 杭州云英网络科技有限公司 | Distributed lock executes method, apparatus and system, application server and storage medium |
Non-Patent Citations (1)
| Title |
|---|
| GEEKERLOU: "【分布式锁第五篇 基于etcd】", 《简书网：HTTPS://WWW.JIANSHU.COM/P/7ABFB83CFA08》 * |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111782669A (en) * | 2020-06-28 | 2020-10-16 | 百度在线网络技术（北京）有限公司 | Method and device for realizing distributed lock and electronic equipment |
| CN111782669B (en) * | 2020-06-28 | 2023-12-12 | 百度在线网络技术（北京）有限公司 | Method and device for realizing distributed lock and electronic equipment |
| CN111930503A (en) * | 2020-08-05 | 2020-11-13 | 浪潮云信息技术股份公司 | Resource lock acquisition method based on ETCD |
| CN115051913A (en) * | 2022-08-12 | 2022-09-13 | 杭州悦数科技有限公司 | Method and device for changing Raft configuration |
| CN115051913B (en) * | 2022-08-12 | 2022-10-28 | 杭州悦数科技有限公司 | Method and device for changing Raft configuration |
| CN116938881A (en) * | 2023-09-18 | 2023-10-24 | 深圳创新科技术有限公司 | Method, system, equipment and readable storage medium for realizing dynamic IP pool |
| CN116938881B (en) * | 2023-09-18 | 2024-02-09 | 深圳创新科技术有限公司 | Method, system, equipment and readable storage medium for realizing dynamic IP pool |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111258771A (en) | Method and system for realizing distributed lock based on Raft algorithm | |
| US5659682A (en) | Scheme to determine completion of directory operations for server recovery | |
| US7266722B2 (en) | System and method for efficient lock recovery | |
| KR101150146B1 (en) | System and method for managing cached objects using notification bonds | |
| CN109101341B (en) | Distribution method and equipment of distributed lock | |
| US5560008A (en) | Remote authentication and authorization in a distributed data processing system | |
| KR101042908B1 (en) | Method, system, and computer-readable recording medium for determining major group under split-brain network problem | |
| US20080033966A1 (en) | System and method for recovery detection in a distributed directory service | |
| US6449734B1 (en) | Method and system for discarding locally committed transactions to ensure consistency in a server cluster | |
| US8156491B2 (en) | Fault tolerant virtual machine | |
| US6769008B1 (en) | Method and apparatus for dynamically altering configurations of clustered computer systems | |
| US5463733A (en) | Failure recovery apparatus and method for distributed processing shared resource control | |
| US20030187927A1 (en) | Clustering infrastructure system and method | |
| WO2016177130A1 (en) | Method and device for selecting communication node | |
| US7356531B1 (en) | Network file system record lock recovery in a highly available environment | |
| CN109753364A (en) | A kind of implementation method, equipment and the medium of network-based distributed lock | |
| US20090319661A1 (en) | Cluster node control apparatus of file server | |
| US20060184672A1 (en) | Communication channels in a storage network | |
| Hine et al. | An architecture for distributed OASIS services | |
| CN103488526A (en) | System and method for locking business resource in distributed system | |
| US7788328B2 (en) | Cross-forest sharing | |
| US10048983B2 (en) | Systems and methods for enlisting single phase commit resources in a two phase commit transaction | |
| CN107547512B (en) | User authentication method and device in multi-level cloud platform | |
| KR20200117405A (en) | Distributed sysetm for managing distributed lock and operating method thereof | |
| US7028219B2 (en) | Hybrid method for flushing transaction state in a fault-tolerant clustered database |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20200609 |