Distributed lock hoạt động với Redis như thế nào?

Question

IT Interview Practice · Accepted Answer

Một **distributed lock** điều phối truy cập tới một tài nguyên dùng chung qua nhiều process/server để chỉ một cái giữ lock tại một thời điểm. Redis thường được dùng cho việc này qua set-if-not-exists nguyên tử với TTL — dù làm đúng đòi hỏi cẩn thận (và hiểu các hạn chế).

## Một Redis lock cơ bản (SET NX với TTL)

```js
// acquire: SET key lock chỉ khi nó không tồn tại, với TTL (an toàn tự giải phóng)
const token = randomUUID();   // một token duy nhất định danh CHỦ lock NÀY
const acquired = await redis.set("lock:resource", token, "NX", "EX", 30);
// NX = chỉ set nếu chưa tồn tại (nguyên tử); EX 30 = tự hết hạn sau 30s (tránh deadlock)

if (acquired) {
  try {
    // ... làm công việc cần truy cập độc quyền ...
  } finally {
    // chỉ giải phóng nếu CHÚNG TA vẫn giữ nó (kiểm tra token) — dùng Lua script để nguyên tử
    await releaseLock("lock:resource", token);
  }
}
```

Lock dùng **`SET key value NX EX`**: set key một cách nguyên tử chỉ khi vắng mặt (nên chỉ một client thành công) với một **TTL** (nên lock tự giải phóng nếu chủ bị crash, tránh deadlock).

## Hai chi tiết tính đúng đắn cốt yếu

```text
1. ALWAYS set a TTL → if the lock holder crashes, the lock auto-expires
   (otherwise the resource is locked forever — a deadlock)
2. Use a UNIQUE TOKEN + release only if it matches → so you don't release
   SOMEONE ELSE'S lock (e.g. if your TTL expired and another client acquired it).
   Release must be ATOMIC (check-token-then-delete via a Lua script).
```

```lua
-- safe release: delete only if the value matches our token (atomic via Lua)
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end
```

## Các hạn chế và Redlock

```text
⚠️ A single-Redis lock isn't perfectly safe: if the TTL expires mid-work, or with
   failover (the lock not yet replicated), two clients could both hold it.
→ REDLOCK algorithm → acquire the lock across MULTIPLE independent Redis nodes
   (majority) for stronger guarantees (though even Redlock is debated).
→ For critical correctness, combine with fencing tokens or use a system designed for
   consensus (e.g. ZooKeeper/etcd). Know the trade-offs.
```

## Tại sao điều này quan trọng

Hiểu distributed lock với Redis là giá trị để **điều phối truy cập tới tài nguyên dùng chung** qua các hệ thống phân tán, nên đó là kiến thức hữu ích — và hiểu các cạm bẫy tính đúng đắn đặc biệt quan trọng.

Distributed lock giải quyết một nhu cầu thực tế: đảm bảo chỉ một process/server thực hiện một hành động quan trọng tại một thời điểm (ngăn xử lý trùng lặp, race condition trên tài nguyên dùng chung, hoặc các thao tác xung đột) trong các hệ thống nhiều server, và Redis là công cụ phổ biến cho việc này.

Hiểu **cơ chế cơ bản** — `SET key value NX EX` (set-if-not-exists nguyên tử với TTL) để chỉ một client lấy được lock và nó tự giải phóng khi crash — là kỹ thuật nền tảng.

Quan trọng, hiểu **hai chi tiết tính đúng đắn** là thiết yếu: **luôn dùng TTL** (để lock của chủ bị crash tự hết hạn, tránh deadlock vĩnh viễn) và **dùng một token duy nhất với giải phóng khớp** (để bạn không vô tình giải phóng lock của client khác nếu TTL của bạn đã hết — với check-then-delete nguyên tử qua một Lua script).

Các chi tiết này là nơi các triển khai ngây thơ có các lỗi tinh vi, nguy hiểm.

Cũng quan trọng không kém là hiểu các **hạn chế**: một single-Redis lock không hoàn hảo an toàn (TTL hết hạn giữa chừng hoặc failover có thể để hai client cùng giữ lock), dẫn đến thuật toán **Redlock** (lấy lock qua nhiều Redis node) cho đảm bảo mạnh hơn — và biết rằng cho tính đúng đắn cốt yếu, fencing token hoặc các hệ thống consensus (ZooKeeper/etcd) có thể cần.

Nhận thức này về các đánh đổi và hạn chế phản ánh sự hiểu biết chín chắn.

Vì điều phối truy cập tài nguyên dùng chung trong các hệ thống phân tán là nhu cầu thực tế, và vì distributed lock Redis phổ biến nhưng đòi hỏi triển khai đúng cẩn thận (TTL, token duy nhất, giải phóng nguyên tử) và nhận thức về các hạn chế của chúng (Redlock, rủi ro failover), hiểu distributed lock với Redis — cơ chế, các chi tiết tính đúng đắn, và các hạn chế — là kiến thức giá trị, có liên quan về mặt thực hành cho điều phối phân tán, một chủ đề nơi hiểu các cạm bẫy và đánh đổi cũng quan trọng như kỹ thuật cơ bản.

Một Redis lock cơ bản (SET NX với TTL)

Hai chi tiết tính đúng đắn cốt yếu

Các hạn chế và Redlock

Tại sao điều này quan trọng

Câu hỏi liên quan