Bài 10: Distributed Lock

Bài 9 kết thúc ở chỗ mọi thứ phụ thuộc vào việc đồng hồ lệch bao nhiêu. Distributed lock là ví dụ trực tiếp nhất: nó là một cơ chế dựa trên giả định về thời gian, và khi giả định đó sai thì hai worker cùng tin mình đang giữ lock — dù Redis hoạt động hoàn toàn đúng và không có lệnh nào lỗi.

Một từ dùng suốt bài cần nói ngay: vùng tới hạn (critical section) là đoạn code mà chỉ được phép có một worker chạy tại một thời điểm — ví dụ đoạn đọc số dư, tính toán, rồi ghi số dư mới. Trong một tiến trình JavaScript đơn luồng bạn gần như không gặp khái niệm này, vì không có gì chạy song song. Nhưng khi có hai tiến trình trên hai máy, nó quay lại — và không còn cách nào bảo vệ nó bằng ngôn ngữ nữa.

Lab của bài này cho hai worker Node thật tranh một lock Redis và đếm số xung đột: số lần có từ hai worker cùng ở trong vùng tới hạn. Kết quả có một con số làm mình phải chạy lại nhiều lần để chắc: một lock được cài đúng chuẩn nhưng có TTL ngắn hơn thời gian xử lý cho 79 xung đột trên 80 lần vào vùng tới hạn — tệ hơn cả việc không dùng lock nào (41/80). Một lock sai còn nguy hiểm hơn không có lock, vì nó cho bạn sự tự tin.

10.1 Hai nhu cầu hoàn toàn khác nhau

Trước khi bàn về cách cài lock, phải phân biệt hai lý do dùng nó. Phần lớn tài liệu gộp chúng làm một, và đó là nguồn gốc của mọi tai nạn liên quan tới distributed lock.

10.2 Ba điều bắt buộc của một Redis lock

Một lock Redis đúng chuẩn cần đúng ba thứ, và thiếu bất kỳ thứ nào cũng sinh ra một lỗi riêng:

/**
 * The three MANDATORY parts of a correct Redis lock (Lesson 10, section 10.2):
 *   NX      only set if the key does not exist — this is the "acquire" part
 *   PX ttl  a TTL is MANDATORY, otherwise a dead holder is a permanent deadlock
 *   token   a random value, so ONLY the owner can delete it (see release)
 */
async function acquire(key, token, ttlMs) {
  const res = await redis.cmd('SET', key, token, 'NX', 'PX', String(ttlMs));
  return res === 'OK';
}

/**
 * Releasing MUST be atomic: check the token and only then DEL, in one command.
 *
 * Why a plain `DEL` is wrong: your lock may already have EXPIRED and someone else may
 * have acquired it. A plain `DEL` would delete THEIR lock, and from there everything
 * breaks in a chain.
 */
const RELEASE_LUA = `
if redis.call('GET', KEYS[1]) == ARGV[1] then
  return redis.call('DEL', KEYS[1])
else
  return 0
end`;

async function release(key, token) {
  return redis.cmd('EVAL', RELEASE_LUA, '1', key, token);
}

Đo thật: lock có làm được việc của nó không?

Hai worker, mỗi worker hoàn thành 40 vùng tới hạn (tổng 80), thời gian xử lý 300 ms. Bộ đếm XUNG ĐỘT tăng mỗi khi có từ hai worker cùng ở trong vùng tới hạn:

Hàng B là điều ta mong đợi: lock hoạt động, 0 xung đột. Hàng C là hàng đáng dừng lại rất lâu. Lock ở hàng C được cài hoàn toàn đúng — có NX, có TTL, có token, giải phóng bằng Lua. Không có GC pause nào, không có clock skew nào. Nó chỉ có một tham số sai: TTL ngắn hơn thời gian xử lý. Và kết quả là 99% — tệ hơn cả không dùng lock.

10.3 Vì sao Redlock gây tranh cãi

Redlock là thuật toán được đề xuất để làm lock phân tán an toàn hơn: giành lock trên đa số trong 5 node Redis độc lập. Nó bị Martin Kleppmann phản biện, và lập luận cốt lõi rất gọn — vấn đề không nằm ở Redis.

Thí nghiệm ở lab tái tạo đúng lập luận đó. Cùng lock đúng chuẩn, cùng TTL 1000 ms dài hơn xử lý 300 ms:

Cơ chế: worker A giành lock, rồi bị dừng 1200 ms — GC stop-the-world, VM bị migrate, container bị throttle CPU, hoặc máy bị swap. Trong lúc đó lock hết hạn ở mốc 1000 ms, worker B giành được một cách hoàn toàn hợp lệ. A tỉnh lại ở mốc 1200 ms và vẫn tin mình đang giữ lock — nó không có cách nào biết rằng thời gian đã trôi qua. Nó ghi. Bây giờ có hai worker ghi.

10.4 Fencing token — lời giải đúng cho nhóm đúng đắn

Nếu lock không thể đảm bảo "chỉ một worker ghi", thì phải chuyển việc kiểm tra sang chỗ khác: chính tài nguyên đích. Lock cấp một số tăng đơn điệu — fencing token — và mọi lệnh ghi phải kèm số đó. Tài nguyên nhớ token lớn nhất nó từng thấy và từ chối mọi token nhỏ hơn.

Nhờ vậy worker "zombie" quay lại sau GC pause bị chặn — không phải vì nó biết mình đã mất lock, mà vì tài nguyên biết đã có người mới hơn.

// Fencing token: a MONOTONICALLY INCREASING number, issued by Redis via INCR (atomic).
// Taken AFTER acquiring the lock, so token order matches lock-acquisition order.
const fence = USE_FENCE ? Number(await redis.cmd('INCR', 'lab:fence:seq')) : 0;

/**
 * Write to the "resource", with fencing-token checking (Lesson 10, section 10.4).
 *
 * This is the crux: the target resource itself rejects any token LOWER than the highest
 * one it has seen. That is how a "zombie" worker returning from a GC pause — still
 * believing it holds the lock — gets blocked AT THE RESOURCE LAYER rather than by the
 * lock. If the resource does not check, the fencing token is just a decorative number.
 */
const FENCED_WRITE_LUA = `
local seen = tonumber(redis.call('GET', KEYS[1]) or '0')
local tok  = tonumber(ARGV[1])
if tok < seen then
  redis.call('INCR', KEYS[3])          -- count the REJECTED writes
  return 0
end
redis.call('SET', KEYS[1], tok)
redis.call('INCR', KEYS[2])            -- count the ACCEPTED writes
return 1`;

// In the worker: only do the work if the resource ACCEPTED the token.
let accepted = true;
if (USE_FENCE) accepted = (await fencedWrite(fence)) === 1;
if (accepted) await sleep(WORK_MS);

Cùng cấu hình gây hỏng ở thí nghiệm D — TTL 1000 ms, GC pause 1200 ms — nhưng bật fencing:

10.5 Tránh lock hoàn toàn — thường là câu trả lời tốt nhất

Sau bốn mục trên, kết luận thực dụng là: distributed lock đúng thì khó, và ngay cả khi đúng nó vẫn không cho đảm bảo mà nhóm "đúng đắn" cần. Nên trong phần lớn trường hợp, câu hỏi tốt hơn không phải "cài lock thế nào" mà là "có cách nào không cần lock?"

Tự làm lại các phép đo

cd blog/sysdesign/sysdesign-lab
docker compose --profile lock up -d redis

# ./tools/lock-test.sh <LOCK> <FENCE> <PAUSE_MS> <TTL> <ROUNDS> <WORK_MS>
# The number that matters most is CONFLICTS: how often TWO OR MORE workers were
# inside the critical section at the same time.

./tools/lock-test.sh off 0 0    1000 40 300   # A: no lock         -> 41/80
./tools/lock-test.sh on  0 0    1000 40 300   # B: correct lock    ->  0/80
./tools/lock-test.sh on  0 0     200 40 300   # C: TTL < work time -> 79/80 (!)
./tools/lock-test.sh on  0 1200 1000 40 300   # D: GC pause > TTL  -> 31/80
./tools/lock-test.sh on  1 1200 1000 40 300   # E: + fencing -> 15 writes REJECTED

# A NOTE ON EXPERIMENT DESIGN: WORK_MS must be long enough relative to PAUSE_MS.
# Otherwise the other worker has already left the critical section by the time the
# "zombie" wakes up, and you measure 0 conflicts even though the lock really did fail.
# The first version of this lab made exactly that mistake.

Tóm lại

Phải phân biệt lock cho hiệu quả (hỏng thì tốn CPU) và lock cho đúng đắn (hỏng thì mất tiền). Distributed lock chỉ đủ cho nhóm thứ nhất, và toàn bộ mục 10.3 là bằng chứng bằng số cho điều đó.

Một lock Redis đúng cần đủ ba thứ: NX, TTL, và token ngẫu nhiên với lệnh giải phóng atomic. Nhưng cài đúng vẫn chưa đủ — phát hiện mạnh nhất của bài này là hàng C: lock đúng chuẩn với TTL 200 ms ngắn hơn thời gian xử lý 300 ms cho 79 xung đột trên 80, tệ hơn cả không dùng lock (41/80). Vì lock đã đồng bộ hoá hai worker để chúng trùng nhau một cách có hệ thống thay vì ngẫu nhiên.

Với GC pause dài hơn TTL, xung đột là 31/80 — và không một lệnh Redis nào lỗi. Đó là lý do thêm node Redis không sửa được: giả định sai nằm ở phía client. Fencing token là lời giải, nhưng phải đọc đúng: nó không ngăn xung đột (vẫn 15/80), nó ngăn thiệt hại — 15 lệnh ghi bị tài nguyên từ chối. Và nó chỉ có tác dụng nếu tài nguyên thật sự kiểm token.

Thực dụng nhất: tránh lock. Thao tác atomic, optimistic concurrency, phân vùng theo key, transaction — tất cả đều không phải trả lời câu hỏi "TTL bao nhiêu là đủ", một câu hỏi thường không có câu trả lời đúng.

Bài 11 đi vào cách tránh lock mạnh nhất trong danh sách đó: idempotency. Nếu làm hai lần cũng cho cùng kết quả thì không cần ngăn lần thứ hai — và đó cũng là câu trả lời cho một câu hỏi mà mọi hệ thống phân tán phải đối mặt: khi client nhận timeout, nó không thể biết request đã được xử lý hay chưa.