←back to thread

How to do distributed locking (2016)

(martin.kleppmann.com)
240 points yusufaytas | 7 comments | 20 Oct 24 10:38 UTC | HN request time: 0.82s | source | bottom
Show context
jmull ◴[20 Oct 24 12:46 UTC] No.41895002[source]▶
This overcomplicates things...

* If you have something like what the article calls a fencing token, you don't need any locks.

* The token doesn't need to be monotonically increasing, just a passive unique value that both the client and storage have.

Let's call it a version token. It could be monotonically increasing, but a generated UUID, which is typically easier, would work too. (Technically, it could even be a hash of all the data in the store, though that's probably not practical.) The logic becomes:

(1) client retrieves the current version token from storage, along with any data it may want to modify. There's no external lock, though the storage needs to retrieve the data and version token atomically, ensuring the token is specifically for the version of the data retrieved.

(2) client sends the version token back along with any changes.

(3) Storage accepts the changes if the current token matches the one passed with the changes and creates a new version token (atomically, but still no external locks).

Now, you can introduce locks for other reasons (hopefully goods ones... they seem to be misused a lot). Just pointing out they are/should be independent of storage integrity in a distributed system.

(I don't even like the term lock, because they are temporary/unguaranteed. Lease or reservation might be a term that better conveys the meaning.)

replies(6): >>41895192 #>>41895264 #>>41895382 #>>41895448 #>>41895475 #>>41895513 #
1. bootsmann ◴[20 Oct 24 13:55 UTC] No.41895382[source]▶
Won't this lead to inconsistent states if you don't do monotonically increasing tokens?

I.e. your storage system has two nodes and there are two read-modify-write processes running. Process 1 acquires the first token "abc" and process two also acquires the token "abc". Now process 1 commits, the token is changed to "cde" and the change streamed to node 2. Due to network delay, the change to node 2 is delayed. Meanwhile process 2 commits to node 2 with token "abc". Node 2 accepts the change because it has not received the message from node 1 and your system is now in an inconsistent state.

Note that this cannot happen in a scenario where we have monotonically increasing fencing tokens because that requirement forces the nodes to agree on a total order of operations before they can supply the fencing token.

replies(2): >>41895446 #>>41895458 #
2. computerfan494 ◴[20 Oct 24 14:05 UTC] No.41895446[source]▶
In the above description of optimistic locking, it is assumed that it is impossible to issue the same token to multiple clients. Nodes can agree that a given token has also never been issued before just like a monotonically increasing value. The nice property about non-monitonically-increasing tokens is that nodes may generate them without coordinating if you can make other assumptions about that system. A good example is when nodes use an ID they were assigned beforehand as part of the token generation, guaranteeing that the leasing tokens they mint will not conflict with other nodes' as long as node IDs are not reused.
replies(1): >>41896604 #
3. jmull ◴[20 Oct 24 14:07 UTC] No.41895458[source]▶
"node1", "node2", and "storage" are three separate things in the distributed environment. Only storage accepts changes, and it's what verifies the incoming token matches the current token.

So node2 doesn't get to accept changes. It can only send changes to storage, which may or may not be accepted by it.

replies(1): >>41896506 #
4. bootsmann ◴[20 Oct 24 16:30 UTC] No.41896506[source]▶
If the storage is a singular entity then this is not a distributed systems problem at all, no?
5. bootsmann ◴[20 Oct 24 16:41 UTC] No.41896604[source]▶
I have a hard time wrapping my head around what you are proposing here. Say client A requests data, they get the token a-abc. Then client B requests data, they get the token b-cde. Client A commits their write, does the storage reject it because they already issued another token (the one from client B) or does it accept it?
replies(1): >>41896803 #
6. computerfan494 ◴[20 Oct 24 17:04 UTC] No.41896803{3}[source]▶
My understanding of what the OP was discussing is an optimistic locking system where the nodes only accept commits if the last issued token matches the token included in the commit. While agreeing on the last token requested requires coordination, unlike monotonically increasing tokens you could have well-behaved clients generate token content themselves without coordination. That may or may not be useful as a property.
replies(1): >>41897171 #
7. bootsmann ◴[20 Oct 24 17:54 UTC] No.41897171{4}[source]▶
Got it, thank you for clarifying this.