How Distributed Locks Prevent Chaos in Massive Red‑Packet Systems

Distributed locks work on the same principle as ordinary locks: they guarantee that, when many threads or processes run concurrently, only one can execute a critical section at any given moment.

In a single‑JVM application, Java provides synchronized or Lock to achieve this. However, when an application is deployed on dozens or hundreds of servers, a single JVM lock cannot coordinate across the whole cluster.

Consider a scenario like a large‑scale red‑packet distribution during a shopping festival, where 10 million users share a total of 100 million yuan. The system must ensure that the sum of all distributed amounts never exceeds the total budget.

1. Why Conventional Locks Fail in a Cluster

When traffic spikes to hundreds of thousands of requests per second, a single server cannot handle the load. Distributing the load across many servers solves capacity issues, but it also introduces the problem of coordinating shared state (e.g., the remaining amount of money).

2. How a Distributed Lock Solves the Problem

Each server, before allocating a portion of the red‑packet, contacts a dedicated lock service (or a Redis/ZooKeeper instance) to acquire a lock. Only the server that holds the lock can read the current total, deduct the requested amount, and write the new total back.

If the lock is not available, the server waits and retries, ensuring that no two servers modify the total simultaneously.

3. Common Implementations of Distributed Locks

3.1 Why Redis Can Implement a Distributed Lock

Redis runs a single network thread, so commands are executed atomically. The typical workflow is:

Server attempts SETNX lock_key any_value. If the command returns 1, the lock is acquired.

If it returns 0, another server holds the lock and the request must wait.

After the critical section, the server releases the lock with DEL lock_key, which returns 1 on success.

To avoid deadlocks when a server crashes, an expiration time is set on the key. Two common approaches are:

Set the key and then call EXPIRE lock_key timeout so Redis automatically deletes the key after the timeout.

Store a timestamp as the value, and let other servers use GETSET lock_key new_timestamp to detect expiration and take over the lock if needed.

3.2 Why ZooKeeper Can Implement a Distributed Lock

ZooKeeper provides a hierarchical namespace of znodes, similar to a file system. Nodes can be persistent, persistent‑sequential, ephemeral, or ephemeral‑sequential.

For locking, servers create an ephemeral sequential znode under a common lock path (e.g., /lock). The server that creates the node with the smallest sequence number obtains the lock.

All other servers set a watch on the next‑smaller node. When the holder deletes its znode after completing the work, ZooKeeper notifies the waiting server, which then becomes the new lock holder.

This mechanism avoids the “herd effect” because each server watches only the node directly before it, and the use of ephemeral nodes guarantees automatic cleanup if a client crashes.

Both Redis and ZooKeeper solutions must handle edge cases such as lock expiration, network partitions, and the possibility of multiple servers attempting to acquire the lock simultaneously.