This article systematically reconstructs the knowledge system behind distributed locks, focusing on the implementation principles, strengths, weaknesses, and selection boundaries of three mainstream approaches: Redis, ZooKeeper, and etcd. It addresses high-concurrency mutual exclusion, lock expiration, and consistency trade-offs. Keywords: distributed locks, Redlock, clock rollback.
Technical Specification Snapshot
| Parameter | Details |
|---|---|
| Primary Language | Java / Distributed Systems |
| Core Protocols | Redis SET NX PX, ZAB, Raft |
| Document Type | Architecture Principles and Selection Guide |
| GitHub Stars | Not provided in the original |
| Core Dependencies | Redisson, Curator, etcd concurrency |
A distributed lock is fundamentally a cross-process mutual exclusion component
At its core, a distributed lock provides mutually exclusive access to shared resources across multiple nodes and processes. It does not solve thread synchronization inside a single JVM. Instead, it resolves concurrency conflicts across service instances, such as inventory deduction, job scheduling, idempotency control, and leader election.
A qualified distributed lock should satisfy at least four baseline requirements: strong mutual exclusion, deadlock prevention, owner-only unlock, and fault tolerance. In real-world engineering, teams often also require reentrancy, fairness, automatic renewal, timeout-based acquisition, and interruptibility.
CAP trade-offs determine the technical direction of a lock
Redis-based locks lean toward AP. They prioritize performance and availability, but they cannot guarantee strong consistency by design. ZooKeeper and etcd lean toward CP. They emphasize linearizable consistency and reliability, at the cost of lower throughput and higher operational complexity.
AP-style locks: high performance and high availability, suitable for non-critical scenarios that do not require strong consistency
CP-style locks: strong consistency and high reliability, suitable for transactions, scheduling, and election scenariosThis comparison shows a key principle: do not choose the “strongest” lock. Choose the one that best matches your business constraints.
Redis distributed locks are a better fit for high-concurrency business paths
A Redis-based lock relies on the atomicity of single-threaded commands to enforce mutual exclusion. The basic version must use a single command, SET key value NX PX ttl, and must not split the operation into SETNX and EXPIRE. Otherwise, a failure in the middle can leave a deadlock behind.
SET order_lock client_uuid_123 NX PX 30000This command acquires the lock atomically: it writes the key only if it does not already exist and sets the expiration time at the same time.
Unlocking must verify the value to avoid deleting another client’s lock by mistake. In practice, teams usually rely on Lua to guarantee that the compare-and-delete operation executes atomically.
-- Delete only when the value matches, preventing accidental release of another client's lock
if redis.call('get', KEYS[1]) == ARGV[1] then
return redis.call('del', KEYS[1])
else
return 0
endThis script performs safe unlock logic and ensures that only the lock owner can release it.
Redisson fills in the engineering gaps of Redis locks
In production systems, teams rarely implement Redis locks by hand. They usually use Redisson directly. Redisson provides reentrant locks, WatchDog-based automatic renewal, fair locks, read-write locks, and cluster support, which significantly reduces the risk of misuse.
Its core value is straightforward: it uses a Hash to record thread identity and reentry count, Lua to preserve atomicity, and a watchdog-based periodic renewal mechanism to prevent locks from expiring too early when business execution runs longer than expected.
RLock lock = redissonClient.getLock("order_lock");
try {
// Try to acquire the lock, wait up to 2 seconds, and let the watchdog renew the lease automatically
if (lock.tryLock(2, TimeUnit.SECONDS)) {
// Execute business logic
processOrder();
}
} finally {
// Release the lock in finally to avoid leaks on exceptional paths
if (lock.isHeldByCurrentThread()) {
lock.unlock();
}
}This example shows the standard Redisson usage pattern, with special emphasis on timed acquisition and releasing the lock in finally.
ZooKeeper distributed locks naturally favor strong consistency and fairness
A ZooKeeper-based lock relies on ephemeral sequential nodes and Watchers. After a client creates an ephemeral sequential node, it acquires the lock if its sequence number is the smallest. Otherwise, it watches only its immediate predecessor, which avoids the herd effect caused by watching the parent node.
Ephemeral nodes are automatically deleted when the session disconnects, which gives ZooKeeper a built-in deadlock prevention mechanism. Sequential nodes preserve request order, which makes ZooKeeper naturally suitable for fair-lock scenarios. This is one of the most distinctive architectural strengths of ZooKeeper locks.
Curator is the standard engineering entry point for ZooKeeper locks
Apache Curator’s InterProcessMutex already encapsulates node creation, predecessor watching, reentrancy, and exception handling. It is suitable for direct production use. It is more reliable than handwritten Watcher logic and makes it easier to avoid subtle issues related to session timeouts.
InterProcessMutex lock = new InterProcessMutex(client, "/locks/task");
try {
// Acquire the lock with a timeout to avoid blocking the thread indefinitely
if (lock.acquire(3, TimeUnit.SECONDS)) {
// Execute the scheduled task or leader-only work
runTask();
}
} finally {
// Release only after successful ownership to ensure resource cleanup
lock.release();
}This example reflects Curator’s high-level encapsulation of the fair-lock workflow.
etcd distributed locks offer a more balanced model in cloud-native systems
etcd builds its lock capabilities on top of Raft, Lease, and global Revision. Lease handles TTL and automatic expiration, KeepAlive handles renewal, and Revision provides global ordering. As a result, etcd offers the core building blocks for strong consistency, automatic release, and fair queuing at the same time.
Compared with ZooKeeper, etcd provides a more modern Watch mechanism with resumable streams and more stable event delivery. Compared with Redis, it does not depend on the local clock to determine lock correctness, which makes it a better fit for Kubernetes, control planes, and infrastructure-oriented workloads.
// Create a session and bind it to a lease; the lock is released automatically when the lease expires
session, _ := concurrency.NewSession(cli)
defer session.Close()
mutex := concurrency.NewMutex(session, "/locks/job")
// Execute critical-section logic after acquiring the lock
if err := mutex.Lock(context.Background()); err == nil {
doJob()
mutex.Unlock(context.Background())
}This example shows the typical locking pattern in the official etcd concurrency package.
The differences between the three mainstream approaches can be summarized in one table
| Dimension | Redis | ZooKeeper | etcd |
|---|---|---|---|
| Consistency | AP-leaning | CP | CP |
| Performance | Very high | Moderate | Moderate |
| Fairness | Not by default | Native support | Can be supported naturally |
| Deadlock prevention | TTL | Ephemeral nodes | Lease |
| Reentrancy | Provided by Redisson | Provided by Curator | Supported by the official package |
| Clock rollback risk | High | None | None |
| Best-fit scenarios | Flash sales, rate limiting, cache mutual exclusion | Scheduling, leader election, financial coordination | Cloud-native control planes, Kubernetes ecosystem |
The key takeaway from this table is simple: Redis wins on performance, ZooKeeper wins on classic strong consistency, and etcd wins on cloud-native integration and modern capabilities.
Redlock reduces the single-point problem but does not eliminate controversy
Redlock uses voting across multiple independent Redis master nodes to reduce the risk of lock loss during failover. A client is considered to hold the lock only if it acquires the lock on a majority of nodes and the total elapsed time stays below the lease duration.
However, Redlock still depends heavily on stable clocks and tightly controlled network latency. The main industry concerns are well known: it cannot fundamentally eliminate issues such as GC pauses, clock drift, or delayed requests that write to shared resources. In particular, without a fencing token, an old client may still corrupt data correctness.
Do not overestimate Redlock in core consistency-critical workloads
Redlock can improve the fault tolerance of Redis locks, but it cannot replace a CP system. If your business involves transactions, payment deduction, accounting, or state machine progression, prefer etcd or ZooKeeper first, and then add database versioning, unique indexes, or fencing tokens as the final safety net.
Clock rollback is the biggest hidden risk of Redis locks
Redis lock TTL evaluation depends on the server’s local clock. If NTP rollback, virtual machine migration, or manual time adjustment occurs, a lock may expire earlier than expected, allowing multiple clients to enter the critical section at the same time. This issue applies to both single-instance locks and Redlock, although the probability of exposure differs.
ZooKeeper and etcd do not rely on absolute physical time to control lock lifetime. They rely on session or lease heartbeats instead, so they are largely immune to clock rollback. This is one of the fundamental reasons they are more stable in strong-consistency scenarios.
Redis risk chain: local clock rollback -> abnormal TTL evaluation -> premature lock expiration -> mutual exclusion failure
ZooKeeper/etcd: based on session or lease heartbeats, independent of absolute time shiftsThis chain explains why clock-related issues are a production risk that Redis locks must address explicitly.
Engineering decisions should be based on the business loss model
If your system pursues extreme throughput and can tolerate a very low probability of inconsistency, Redis + Redisson is the most practical choice. If your business values consistency and ordering more highly, ZooKeeper is the safer option. If your system is already deeply integrated with Kubernetes or a cloud-native control plane, etcd is often the more natural fit.
Best practices must cover frameworks, timeouts, and business-level safeguards
Always prioritize mature frameworks over handwritten lock implementations. Keep lock granularity as small as possible. Always acquire locks with a timeout. Always release them in finally. For critical write operations, combine distributed locks with optimistic locking, unique constraints, or fencing tokens to prevent a single lock failure from escalating into a data incident.
FAQ
FAQ 1: Why is it not recommended to implement Redis distributed locks by hand?
Because a basic implementation can easily fail in several ways: non-atomic lock acquisition, accidental deletion of another client’s lock, missing lease renewal, and lock loss during master-replica failover. In production, you should prefer Redisson.
FAQ 2: How should I quickly choose between Redis, ZooKeeper, and etcd?
Choose Redis for high-concurrency but non-critical paths. Choose ZooKeeper for strongly consistent scheduling and coordination. Prefer etcd for cloud-native infrastructure and Kubernetes ecosystems.
FAQ 3: If I already use a distributed lock, why do I still need a database-level safeguard?
Because a lock can only reduce the probability of concurrency conflicts. It cannot absolutely guarantee business correctness under every failure mode. Database version numbers, unique indexes, and fencing tokens remain the last line of defense for consistency.
AI Readability Summary: This article breaks down the core properties of distributed locks, CAP trade-offs, and the three mainstream implementations: Redis, ZooKeeper, and etcd. It focuses on Redlock controversies, clock rollback risks, engineering trade-offs, and best practices, helping developers make the right decision across performance, consistency, and availability.