Distributed Locks: Concepts, Characteristics, and Common Implementation Strategies

Preface

In the single‑machine era, although there is no distributed lock, resource contention still occurs; multiple threads accessing a shared resource can be synchronized using thread‑level locks such as Java's synchronize or Lock mechanisms.

When systems become distributed, thread‑level locks no longer work because resources are shared across processes on different machines. To coordinate access to these shared resources, a distributed lock is required.

A distributed lock controls synchronized access to shared resources in a distributed system, ensuring mutual exclusion and consistency when multiple nodes or processes contend for the same resource.

Distributed Lock Characteristics

Common Implementation Schemes

Implementation Based on Databases

Optimistic Lock

The optimistic lock performs business operations first and only acquires the lock at the final update step, assuming the lock will usually succeed.

The mechanism introduces a version column in the table.

When reading a row, the current version is also retrieved; on update, the version is incremented and the row is updated only if the stored version still matches, otherwise the update fails because another process has modified the data.

Two rules of optimistic locking:

Lock service must maintain an incrementing version number.

Every data update must first verify the version before writing the new version.

Pessimistic Lock

The pessimistic lock acquires the lock before performing any business logic, assuming that lock acquisition may fail and therefore must succeed before proceeding.

This is often described as “one lock, two queries, three updates”.

When the database executes select for update , it obtains a row‑level lock on the rows returned by the underlying select .

Concurrent select for update statements on the same row will block until the lock is released, achieving mutual exclusion.

The row lock obtained by select for update is automatically released when the transaction ends, so it must be used within a transaction.

Summary of Database Implementation

Implementation Based on Redis

The Redis‑based lock relies on Redis's atomic operations.

Implementation Idea

When acquiring the lock, use setnx to set a key and immediately set an expiration with expire ; the key value is a randomly generated UUID, which is later used to verify ownership when releasing.

Set a timeout for acquiring the lock; if the timeout is exceeded, give up.

When releasing, compare the stored UUID with the lock's value and, if they match, execute del to delete the key.

Principle

Summary

Implementation Based on ZooKeeper

ZooKeeper implements distributed locks using temporary sequential nodes.

Implementation Idea:

(1) Create a directory mylock ;

(2) Thread A creates a temporary sequential node under mylock to request the lock;

(3) Retrieve all child nodes of mylock ; if no node with a smaller sequence number exists, the thread holds the lock;

(4) Thread B, seeing it is not the smallest, sets a watch on the next‑smaller node;

(5) After Thread A finishes and deletes its node, Thread B receives the watch event, checks if it is now the smallest, and acquires the lock.

Principle

Curator (ZooKeeper Client Library)

Summary

Conclusion

There are many kinds of distributed locks; the three mainstream types mentioned here are only a personal view.

The concrete implementation should be chosen according to the specific scenario and constraints.

The essence is to occupy shared resources reasonably; the ideal solution is to avoid locking altogether by eliminating concurrent conflicts.