Distributed Lock Options

Distributed locks provide mutual exclusion across processes or nodes. Common implementations: Redis (SET NX PX + Lua release), ZooKeeper (ephemeral sequential nodes + Watch), database (unique index or SELECT FOR UPDATE), Etcd (lease + transaction). This article compares these options with a selection guide and table.

Overview

  • Redis: SET key value NX PX ttl; Lua to verify value before DEL on release. Simple and fast; single-node or failover may allow duplicate lock (Redlock mitigates).
  • ZooKeeper: Create ephemeral sequential node; lowest sequence owns lock; delete node to release. Strong consistency; no duplicate; depends on ZK cluster; higher latency and ops cost.
  • Database: Unique index insert as lock, or SELECT FOR UPDATE. Simple; higher DB load and coarse granularity; generally not recommended for high concurrency.
  • Etcd: Lease + transaction (Compare-And-Swap); similar to ZK, strong consistency. Fits K8s ecosystem with existing Etcd.

Example

Example 1: Option comparison

OptionConsistencyPerformanceDependencyTypical use
Redis SET NXRisk on failoverHighRedisGeneral mutex, rate limit
RedlockLower risk with multi-nodeMediumMultiple RedisHigher assurance mutex
ZooKeeperStrongMediumZK clusterConfig, leader election, strong lock
DatabaseStrongLowDBLow frequency, simple
EtcdStrongMediumEtcdK8s, discovery, lock

Example 2: Redis SET NX (conceptual)

Redis
SET lock_key unique_value NX PX 30000
-- NX = set if not exists; PX = millisecond TTL
  • Release with Lua so only the holder can delete (check value before DEL).

Example 3: Selection guide

  • General mutex, rate limit: Redis + Lua is enough. Single node if rare duplicates are acceptable; otherwise Redlock.
  • Leader election, config lock, must be strongly consistent: ZooKeeper or Etcd.
  • Low frequency, simple: Database unique index; not recommended for high concurrency.

Example 4: Important details

  • TTL: Every option needs expiration/lease to avoid deadlock. Redis PX, ZK session timeout, Etcd lease.
  • Release: Only the holder can release (Redis: unique value + Lua; ZK/Etcd: same session/lease).
  • Reentrancy: Redis needs manual reentrancy count; ZK can use multiple nodes in same session.

Core Mechanism / Behavior

  • Redis: NX ensures only one acquires; PX adds TTL. Lua for atomic check-and-delete on release.
  • ZooKeeper: Ephemeral node tied to session; sequential ordering for fairness; Watch for change notification.
  • Etcd: Lease for TTL; transaction for atomic compare-and-swap.

Key Rules

  • Choose by consistency requirement and existing infra; prefer Redis when strong consistency is not needed; ZK/Etcd when it is.
  • Always set TTL/lease and release only from the holder; consider renewal (watchdog) for long tasks.
  • Understand failure modes (failover, network partition); Redlock and ZK docs have details.

What's Next

See Distributed Lock with Redis, CAP Theorem. See High Availability for multi-node deployment.