Mutual Exclusion and Idempotency in Distributed Systems: Problems, Principles, and Solutions

With the rapid growth of internet technologies, data volumes and business logic have become increasingly complex, making high‑availability, scalability, and extensibility essential for modern systems.

Traditional centralized architectures struggle to meet these demands, leading to the adoption of distributed systems composed of loosely coupled servers.

Distributed systems exhibit characteristics such as scalability, high reliability, high concurrency, and cost‑effectiveness, but also introduce complexities like clock inconsistency and Byzantine failures, making mutual exclusion and idempotency critical issues.

Mutual Exclusion Problem

Two examples illustrate resource contention: (1) concurrent updates to a shared value X, and (2) multiple services randomly picking tasks from a shared pool, both leading to inconsistent results without proper synchronization.

In multithreaded environments, Java provides ReentrantLock and synchronized to serialize access to shared resources.

ReentrantLock Implementation

ReentrantLock uses CAS (Compare‑And‑Swap) and a CLH queue to acquire and release locks, supporting both fair and non‑fair modes.

final boolean nonfairTryAcquire(int acquires) { ... }

When a thread fails to acquire the lock, it joins the CLH queue and may block until the lock becomes available.

boolean acquireQueued(final Node node, int arg) { ... }

The synchronized keyword inserts monitorenter and monitorexit bytecode instructions, ensuring that only the owning thread can enter the critical section.

Multiprocess Solution

Processes share resources via semaphores (named or unnamed). A semaphore’s P (wait) operation decrements the count, blocking if the count is zero; V (signal) increments the count and wakes waiting processes.

Distributed Lock Solution

To achieve mutual exclusion across machines, a distributed lock must satisfy three basic conditions: a shared storage space, a unique identifier, and at least two states (locked/unlocked).

Typical storage includes databases, Redis, Tair, or Zookeeper.

Zookeeper Implementation

Clients create an EPHEMERAL_SEQUENTIAL node under a lock path; the client with the smallest sequence number holds the lock, while others watch the predecessor node.

Redis Implementation

Redis uses SETNX (or SET with NX ) to atomically create a lock key, often combined with an expiration to avoid deadlocks.

SET lock.key value NX PX 30000

Cerberus Distributed Lock

Cerberus abstracts multiple engines (Zookeeper, Tair, future Redis) behind a unified interface, offering features such as re‑entrancy, fair locking, and one‑click engine downgrade.

Key methods mirror JUC’s Lock interface: lock() , tryLock() , unlock() , etc.

Idempotency Problem

Idempotency ensures that repeated calls to an interface produce the same result as a single call, preventing issues like duplicate orders or message reprocessing.

GTIS Solution

GTIS generates a global unique ID for each operation (e.g., MD5 of operation content) and stores it in an external engine (typically Tair) using SETNX to guarantee single execution.

boolean success = tair.setNx(globalId, timestamp+payload);

The workflow includes a pre‑check to acquire the ID, execution of the business logic if successful, and a post‑check to confirm success and extend the key’s TTL.

Conclusion

Mutual exclusion in distributed systems is typically addressed with distributed locks that borrow concepts from multithreaded and multiprocess locking, while idempotency can be achieved by preventing duplicate operations via unique identifiers and external storage; both Cerberus and GTIS provide mature, production‑tested implementations.