Distributed Lock Implementations: Database, Redis, and Zookeeper

The article begins with a light‑hearted preface referencing the popular WeChat "tap" feature before diving into the technical discussion of distributed locks.

Distributed Lock Overview

Three main implementation approaches are introduced: database‑based locks, Redis‑based locks, and Zookeeper‑based locks. A distributed lock must satisfy mutual exclusion, reentrancy, efficient lock/unlock operations, and support for blocking or fairness policies.

Database Distributed Lock

Database locks can be implemented using pessimistic locking (e.g., SELECT … WHERE … FOR UPDATE) or optimistic locking based on version numbers and CAS semantics. Example SQL statements and a table definition for a LOCK table are provided, along with insert/delete operations to acquire and release locks.

Redis Distributed Lock

Redis can implement locks via transactions for a simple flash‑sale scenario, using WATCH, MULTI, and EXEC. Code snippets show thread‑pool initialization, stock initialization, and lock acquisition logic.

Another method uses the commands SETNX, GETSET, EXPIRE, and DEL to build a lock with timeout handling and retry logic. The article also covers the Redisson library, which abstracts lock handling with Lua scripts, supports reentrancy via counter increments, and provides a watchdog to extend lock TTL.

public void redis(Produce produce) {
    long timeout = 10000L;
    Long result = RedisUtil.setnx(produce.getId(), String.valueOf(System.currentTimeMillis() + timeout));
    if (result != null && result.intValue() == 1) {
        RedisUtil.expire(produce.getId(), 10);
        // business logic
        RedisUtil.del(produce.getId());
    } else {
        System.out.println("没有获取到锁");
    }
}

Zookeeper Distributed Lock

Zookeeper implements locks using temporary sequential nodes. Clients create a sequential node under a parent lock node; the client with the smallest sequence acquires the lock, while others set a watcher on the predecessor node and wait for its deletion before retrying.

Comparison and Summary

Performance ranking: Cache (Redis) > Zookeeper >= Database. Reliability ranking: Zookeeper > Cache > Database. The article concludes that while each method has trade‑offs, understanding their mechanisms helps choose the right lock for a given scenario.