How Distributed Locks Prevent Over‑Allocation in Massive Red‑Packet Systems

1. Problems with Conventional Locks

Traditional locks (e.g., synchronized or Lock) work within a single JVM, but when an application is deployed across many servers, concurrent requests can overwhelm a single node, leading to inconsistent state such as over‑allocating red‑packet amounts.

In a scenario with 100 servers handling 10 000 requests each, each server might independently deduct from a shared total of 1 billion, resulting in a combined deduction of 100 billion, which is obviously incorrect.

The first user receives a random amount, reducing the total.

The second user receives another random amount, further reducing the total.

After many users, the remaining amount may become insufficient, causing errors.

2. How Distributed Locks Solve the Problem

A distributed lock treats the whole cluster as a single application, ensuring that only one server can modify the shared resource at a time. Each request obtains the lock, updates the remaining amount, and releases the lock, guaranteeing that the total distributed amount never exceeds the original budget.

Using a central service (or Redis) to manage the total, each server asks the service for a portion of the amount; the service grants it only if the lock is acquired.

3. Distributed Lock Implementations

Redis : Redis is single‑threaded for network requests, making SETNX a natural lock primitive. A server attempts SETNX key value; a return of 1 means the lock is acquired, 0 means it is held by another server. After processing, the server deletes the key to release the lock. To avoid deadlocks, an expiration time can be set with EXPIRE key timeout or by storing a timestamp and using GETSET to detect and recover expired locks.

Zookeeper : Zookeeper provides coordination via znodes. A server creates an exclusive znode (e.g., /lock) to acquire the lock; other servers watch this node and wait for its deletion. Using ephemeral nodes ensures that if a server crashes, the node disappears automatically. Ephemeral sequential nodes further avoid the thundering‑herd problem by giving each contender a unique order; the node with the smallest sequence number holds the lock, and others watch the predecessor.

4. Zookeeper Locking Details

Servers create an ephemeral sequential znode under a lock path (e.g., /zkjjj/000000001). The server with the smallest suffix holds the lock. When it finishes, it deletes its node, triggering a watch event for the next server, which then acquires the lock. This pattern prevents deadlocks and reduces unnecessary wake‑ups.