Mastering Distributed Locks: When to Use Redis, Zookeeper, and Redlock

Distributed Lock Guide

Distributed locks solve resource sharing problems and appear frequently in interviews. This article analyzes correct usage from three aspects—locking, unlocking, and protected‑resource safety—and compares two common implementations based on Redis and Zookeeper, finally recommending production‑ready solutions.

Why Distributed Locks Are Needed

In single‑machine programs, multiple threads run on multi‑core CPUs, leading to competition for kernel or user data. Common scenarios include Go map updates without locks, flash‑sale systems where many users simultaneously decrement inventory, and any shared‑resource access that requires mutual exclusion.

Mutual exclusion is achieved by locking; in single‑machine contexts we call it a local lock, while in a micro‑service deployment it becomes a distributed lock.

How to Use Distributed Locks Correctly

Correct usage must address three problems: acquiring the lock, releasing the lock, and ensuring the safety of the protected resource.

Atomicity of Lock Acquisition

The process must check whether the lock exists and create it atomically; otherwise concurrent attempts can cause errors. Setting a timeout prevents deadlock when a process blocks after acquiring the lock.

Redis supports atomic lock acquisition with the SET resource-name anystring NX EX max-lock-time command, using the NX and PX options introduced in Redis 2.6.12. SET resource-name anystring NX EX max-lock-time Diagram of deadlock flow:

Atomicity of Unlocking

Unlocking must delete the lock atomically; otherwise race conditions can occur. A common solution is to store a unique client identifier as the lock value and delete the lock only if the stored value matches.

In Redis this requires a Lua script that performs a GET‑then‑DEL atomically:

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

Diagram of unsafe unlock scenario:

Safety of the Protected Resource

Even with correct lock acquisition and release, a protected resource can become unsafe if a blocked client resumes and overwrites newer data. The fencing mechanism solves this by attaching an ever‑increasing token to each update; older tokens are rejected.

Diagram of fencing mechanism:

Practical Implementations

Two common engineering solutions are based on Redis and Zookeeper.

Redis Implementation

Redis offers high performance (<10 ms latency, up to 100 k QPS) and low latency. Lock acquisition uses SET lock $uuid NX PX $expireTime. Unlocking uses the Lua script shown earlier. Redis can be deployed in a single‑master setup with Sentinel or in a multi‑master “Redlock” configuration.

Redlock requires at least three of five independent Redis instances to succeed in both lock and unlock phases, and it relies on synchronized client timestamps.

Zookeeper Implementation

Zookeeper provides built‑in high availability and automatic cleanup of temporary nodes on heartbeat timeout, eliminating the need for explicit lock expiration. Watches enable fair lock queuing without busy‑waiting, though throughput is limited to <2000 QPS.

The lock workflow creates a permanent node, then each client creates an ordered temporary node; the client with the smallest sequence number holds the lock, and others watch the predecessor node.

Conclusion

Both Redis and Zookeeper have trade‑offs: Redis single‑master offers the highest performance but risks data loss during failover; Redlock improves availability at the cost of complexity and time‑synchronization requirements; Zookeeper guarantees safety and fairness but handles lower concurrency. Choose the solution that matches your workload and operational constraints.