Designing a Redis-Based Distributed Lock Service: Architecture and Implementation

Overall Scheme

The lock solves resource concurrency problems; in a single‑process Java application, Synchronized or ReentrantLock can be used. In a distributed environment, a distributed lock is needed. This article introduces a Redis‑based distributed lock design, with the code to be released in a follow‑up article, elevating the traditional JAR‑based lock to a lock service.

Component Diagram

Component Introduction

(1) Lock Service – Client: encapsulates LockService calls, usable via proxy or annotation for business functions.

(2) Lock Service – Server: implements lock and unlock functions, supporting manual and automatic unlocking.

(3) Lock Service – Management: monitors lock service operation and controls lock parameters.

Lock Lifecycle

Lock states: no lock, locked, lock success, unlocked.

Lock operations: request lock, request unlock, automatic unlock, lock wait, lock timeout.

Lock Service – Server Design

Design Class Diagram

Class Diagram Introduction

(1) Exposes lock and unlock interfaces; the Key parameter is of type Map<String,String>.

(2) Lock mechanism relies on Redis serial execution and the SETNX command.

(3) lock(keyMap : Map<String, String>) uses a default timeout, which can be customized via the management side.

(4) lock(keyMap : Map<String, String>, ltimeout : long) specifies a timeout, also customizable through management.

Lock Service – Client Design

Class Diagram Design

Class Diagram Introduction

(1) The left side shows a simple wrapper of the lock service to reduce duplicate code, following the proxy pattern.

(2) The right side adds annotation and interception on top of the proxy pattern; implementation is optional based on complexity.

(3) For simple use cases, the proxy can be omitted and the service interface called directly.

Lock Service – Management Design

Functional Use‑Case Diagram

Main Use Cases

(1) Grant lock permission: enable distributed‑lock usage for a business system, with granularity down to subsystem, module, or function.

(2) Manage lock permission: enable, disable, or query lock usage.

(3) Configure common lock parameters: default timeout, service degradation, exception return values, etc.

(4) Configure business‑specific lock parameters: timeout, degradation, exception handling for particular business, module, or function.

(5) View lock runtime status: monitor locked business functions, lock duration, conflict logs, historical statistics, and other metrics.

Lock Grading – Practical Application

Lock Grading Design

Different business scenarios require different lock scopes and granularity:

Business lock : locks all operations related to a lock value, e.g., locking an order number controls all order‑related processes.

Process lock : locks a specific type of data within a business flow, e.g., Key = orderNo_CREATE during order creation.

Task lock : locks an entire method, such as a scheduled task; example key SendEmailTask.

Optimistic lock : allows concurrent attempts but only one succeeds, suitable for low‑concurrency scenarios requiring strong consistency, e.g., updating an order status from pending to paid.

Lock Service Degradation

When the distributed lock fails, two fallback strategies are recommended:

(1) Database method : use a unique index combined with DB optimistic locking to control access; suitable for low concurrency, with front‑end rate limiting needed for high concurrency.

(2) Zookeeper method : create a temporary sequential node under a locker node when acquiring the lock and delete it upon release; suitable for high concurrency and can serve as a backup to the Redis lock for high availability.

Next Article Preview

Further optimization of the design, service‑oriented implementation, and source code will be provided.