Understanding Thread Locks, Process Locks, and Distributed Locks in Distributed Systems

In distributed cluster system development, thread locks often cannot satisfy all scenarios, so new technical solutions such as distributed locks must be introduced.

Thread Lock, Process Lock, Distributed Lock

Thread lock: Everyone is familiar with it; it is used to lock methods or code blocks so that at most one thread can execute the locked section at a time, while other threads may still run non‑locked code.

Process lock: It controls multiple processes within the same operating system from accessing a shared resource, typically using OS‑level semaphores.

Distributed lock: When multiple processes run on different machines, a distributed lock is used to coordinate their access to a shared resource.

What Exactly Is a Distributed Lock and How to Implement It?

To implement a distributed lock, a third‑party storage medium is used to store lock metadata. For example, when a distributed cluster wants to operate on a specific row of data, the row’s unique serial number can be used as a lock ID. A process that wants to operate on that data first checks the storage; if the lock ID does not exist, it writes the ID and proceeds. Other processes see the existing lock ID and repeatedly poll the storage until the lock is released, after which they delete the lock ID.

In Redis, simple get/set operations are not atomic, so the atomic command jedis.set(String key, String value, String nxxx, String expx, int time) should be used.

Specific implementation details: https://www.cnblogs.com/linjiqin/p/8003838.html

The purpose of thread, process, and distributed locks is the same—controlling access to resources—but their scope differs: distributed lock > process lock > thread lock. Using a lock with a larger scope increases technical complexity.

Why Distributed Locks Often Feel Unnecessary in J2EE Development

In high‑concurrency Java EE systems, a Tomcat cluster may share a single database. Although multiple servers modify the same database rows, the database itself provides row‑level locking, so an additional distributed lock at the application layer is usually unnecessary.

However, when multiple rows need to be updated atomically, database row locks are insufficient, and a distributed lock (or database transaction with appropriate isolation) becomes necessary.

Does Distributed Lock Design Need to Consider Business Logic?

Distributed locks are not a universal solution; they should be applied only to suitable business scenarios after fully understanding the requirements, similar to how MyBatis second‑level cache must be used with awareness of its namespace constraints.

For example, we may lock the second and third rows of a table; if an operation tries to modify those rows simultaneously, it must acquire the lock first. If an operation only modifies the second row, it can obtain a lock on that specific row without affecting others.

Distributed Locks for HBase Storage Systems

In practice, we apply distributed locks to HBase operations. HBase provides row‑level transactions (ACID properties) but does not support multi‑row atomicity, so a distributed lock is needed when concurrent operations span multiple rows.

How to Reduce Database Load Beyond Master‑Slave Replication

Database servers create a thread for each client request, and threads contend for row locks. When many clients compete for the same row, threads continuously poll the database, increasing load.

By moving the lock‑acquisition polling to the client side using a distributed lock, the database no longer suffers from excessive thread polling, reducing pressure on the database server.

Which Third‑Party Medium Should Store Distributed Locks?

Currently, Zookeeper and Redis are popular choices. Redis offers in‑memory caching, horizontal scalability, high‑throughput read/write, and mechanisms like AOF and Sentinel to prevent data loss.

Zookeeper implements the Paxos consensus algorithm, handling high‑load requests with strong consistency and providing a watch mechanism that notifies other processes when a lock is released, eliminating the need for custom polling.

Many newcomers to big‑data mistakenly introduce distributed locks where simple thread locks would suffice, complicating system design.

Zookeeper, while often seen only as a coordinator in big‑data frameworks, is also widely used in micro‑service architectures for functions such as distributed locks and configuration centers.