When Redis Is Not Enough
Redis is a cache that has been extended to support locking. Its replication is asynchronous and its clock-based TTLs are vulnerable to drift. For use cases that require linearizable (strictly consistent) locking — where a lock is either held or not, with no ambiguity — you need a system built on a consensus algorithm.
ZooKeeper uses the ZAB (ZooKeeper Atomic Broadcast) protocol. etcd uses Raft. Both guarantee that a write is only acknowledged after a majority of nodes have durably recorded it. There is no window where a lock can be "lost" due to async replication.
How etcd Locking Works
etcd provides a native Lock API via its concurrency package. Under the hood, it uses leases (called Grant) combined with sessions and revision-based fencing tokens. Acquiring a named lock with a TTL via etcdctl lock blocks until it succeeds — a second client attempting to acquire the same named lock simply blocks until the first is released or expires.
Every write to etcd is assigned a revision number — a globally monotonically increasing integer. When you acquire a lock, you receive the revision at which your lock key was written. This revision IS the fencing token. The protected resource can compare incoming revision numbers and reject stale writers.
ZooKeeper Ephemeral Nodes
ZooKeeper implements distributed locks using ephemeral sequential nodes:
- A worker creates an ephemeral sequential node:
/locks/job-0000000042. - It lists all nodes under
/locks/and checks if its node has the lowest sequence number. - If yes → it holds the lock.
- If no → it watches the node with the next-lower sequence number and waits for it to be deleted.
- When a worker finishes or crashes, its ephemeral node is automatically deleted by ZooKeeper (because ephemeral nodes are tied to the client session). The next worker in line is notified.
This design is inherently fair (FIFO ordering), crash-safe (ephemeral nodes disappear on disconnect), and produces a monotonically increasing sequence number that serves as a fencing token.
Trade-off summary:
| Property | Redis (Redlock) | etcd / ZooKeeper |
|---|---|---|
| Consistency | Probabilistic | Linearizable |
| Fencing Tokens | No (manual) | Yes (native) |
| Latency | ~1ms | ~5–15ms |
| Operational Complexity | Low | Medium–High |
| Best For | Efficiency locks | Correctness locks |