Understanding Thread Locks, Process Locks, and Distributed Locks: Concepts and Implementation with Redis and Zookeeper

Thread Lock, Process Lock, Distributed Lock

Thread lock: Commonly used to protect methods or code blocks so that only one thread can execute the locked section at a time, while other threads may still run non‑locked code.

Process lock: Controls access to a shared resource across multiple processes on the same operating system, typically using OS semaphores.

Distributed lock: Extends locking to processes running on different machines, coordinating access via a shared external storage.

What is a Distributed Lock and How to Implement It?

Implementation relies on a third‑party storage medium to hold lock metadata. For example, a unique row identifier in a distributed database can serve as a lock ID; a process writes this ID to the storage to acquire the lock and deletes it after completing its operation.

Other processes check the storage for the lock ID; if it exists, they poll until the lock is released.

Redis cannot guarantee atomicity with simple get / set operations, so the atomic command

jedis.set(String key, String value, String nxxx, String expx, int time)

should be used.

Implementation details can be found at https://www.cnblogs.com/linjiqin/p/8003838.html .

The scope of locks increases from thread lock < → process lock < → distributed lock; using a larger‑scope lock adds technical complexity.

Practical Experience with Distributed Locks

In Java EE environments, high‑concurrency systems often use Tomcat clusters accessing a single database. Although multiple JVMs may modify the same row, the database itself handles row‑level locking, so an application‑level distributed lock is unnecessary for single‑row updates.

When updating multiple rows, database row locks may be insufficient, and a distributed lock becomes useful, either relying on the database's transaction mechanisms or an external lock.

Design Considerations for Distributed Locks

Distributed locks are not universally applicable; they must be designed with specific business scenarios in mind, similar to considerations for MyBatis second‑level cache namespaces.

For example, locking specific rows (e.g., rows 2 and 3) ensures that concurrent updates to those rows are serialized, while operations affecting only row 2 can proceed independently.

Distributed Locks in HBase

HBase provides row‑level transactions (ACID) but lacks multi‑row transaction support. When business logic requires atomic operations on multiple rows, an external distributed lock can compensate for this limitation.

Load Reduction for High Database Traffic

Database threads handling row‑level locks can cause polling pressure when many clients contend for the same row. Offloading the polling to client machines via a distributed lock reduces database load.

Choosing a Third‑Party Store for Locks

Redis and Zookeeper are popular choices. Redis offers in‑memory speed, horizontal scalability, and persistence mechanisms (AOF, Sentinel). Zookeeper provides strong consistency via the Paxos algorithm, built‑in watch notifications, and resilience to node failures.

Both are widely used in micro‑service architectures for distributed locks, configuration centers, and service discovery.