distributed lock ทำงานอย่างไรเมื่อใช้กับ Redis?

Question

IT Interview Practice · Accepted Answer

**Distributed lock** ทำหน้าที่ประสานการเข้าถึงทรัพยากรที่ใช้ร่วมกันข้ามหลายโพรเซส/เซิร์ฟเวอร์ เพื่อให้มีเพียงตัวเดียวที่ถือ lock อยู่ในแต่ละช่วงเวลา Redis มักถูกใช้เพื่อการนี้ผ่านการ set-if-not-exists แบบ atomic พร้อม TTL — แม้ว่าการทำให้ถูกต้องจะต้องอาศัยความระมัดระวัง (และเข้าใจข้อจำกัดของมัน)

## Redis lock พื้นฐาน (SET NX พร้อม TTL)

```js
// acquire: SET the lock key only if it doesn't exist, with a TTL (auto-release safety)
const token = randomUUID();   // a unique token identifying THIS lock holder
const acquired = await redis.set("lock:resource", token, "NX", "EX", 30);
// NX = set only if not exists (atomic); EX 30 = auto-expire in 30s (avoid deadlock)

if (acquired) {
  try {
    // ... do the work that needs exclusive access ...
  } finally {
    // release ONLY if WE still hold it (check the token) — use a Lua script for atomicity
    await releaseLock("lock:resource", token);
  }
}
```

Lock นี้ใช้ **`SET key value NX EX`**: ตั้งค่า key แบบ atomic เฉพาะเมื่อยังไม่มีอยู่ (เพื่อให้มีไคลเอนต์เพียงตัวเดียวที่สำเร็จ) พร้อม **TTL** (เพื่อให้ lock ปลดล็อกอัตโนมัติหากผู้ถือ crash จึงหลีกเลี่ยง deadlock)

## รายละเอียดความถูกต้องที่สำคัญสองข้อ

```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
```

## ข้อจำกัดและ 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.
```

## ทำไมจึงสำคัญ

การเข้าใจ distributed lock กับ Redis มีค่าสำหรับการ **ประสานการเข้าถึงทรัพยากรที่ใช้ร่วมกัน** ข้ามระบบแบบกระจาย จึงเป็นความรู้ที่มีประโยชน์ — และการเข้าใจกับดักด้านความถูกต้องก็สำคัญเป็นพิเศษ

Distributed lock ตอบโจทย์ความต้องการที่มีอยู่จริง: การรับประกันว่ามีเพียงโพรเซส/เซิร์ฟเวอร์เดียวที่ทำการกระทำสำคัญในแต่ละช่วงเวลา (ป้องกันการประมวลผลซ้ำซ้อน, race condition บนทรัพยากรที่ใช้ร่วมกัน หรือการดำเนินการที่ขัดแย้งกัน) ในระบบหลายเซิร์ฟเวอร์ และ Redis เป็นเครื่องมือที่พบบ่อยสำหรับงานนี้

การเข้าใจ **กลไกพื้นฐาน** — `SET key value NX EX` (set-if-not-exists แบบ atomic พร้อม TTL) เพื่อให้มีไคลเอนต์เพียงตัวเดียวที่ได้ lock และมันปลดล็อกอัตโนมัติเมื่อ crash — คือเทคนิคพื้นฐาน

ที่สำคัญ การเข้าใจ **รายละเอียดความถูกต้องสองข้อ** เป็นเรื่องจำเป็น: **การตั้ง TTL เสมอ** (เพื่อให้ lock ของผู้ถือที่ crash หมดอายุอัตโนมัติ หลีกเลี่ยง deadlock ถาวร) และ **การใช้ token ที่ไม่ซ้ำพร้อมการปลดล็อกแบบจับคู่** (เพื่อไม่ให้คุณปลดล็อกของไคลเอนต์อื่นโดยไม่ตั้งใจหาก TTL ของคุณหมดอายุไปแล้ว — ด้วยการ check-then-delete แบบ atomic ผ่าน Lua script)

รายละเอียดเหล่านี้คือจุดที่การใช้งานแบบไร้เดียงสามักมีบั๊กที่ละเอียดอ่อนและอันตราย

สิ่งที่สำคัญพอกันคือการเข้าใจ **ข้อจำกัด**: lock บน Redis ตัวเดียวไม่ปลอดภัยอย่างสมบูรณ์ (TTL หมดอายุระหว่างทำงานหรือ failover อาจทำให้ไคลเอนต์สองตัวถือ lock พร้อมกัน) นำไปสู่อัลกอริทึม **Redlock** (การ acquire ข้ามหลาย Redis node) เพื่อการรับประกันที่แข็งแกร่งกว่า — และรู้ว่าสำหรับความถูกต้องที่สำคัญยิ่ง อาจต้องใช้ fencing token หรือระบบ consensus (ZooKeeper/etcd)

ความตระหนักในข้อแลกเปลี่ยนและข้อจำกัดนี้สะท้อนความเข้าใจที่เป็นผู้ใหญ่

เนื่องจากการประสานการเข้าถึงทรัพยากรร่วมในระบบกระจายเป็นความต้องการที่มีอยู่จริง และเนื่องจาก distributed lock ของ Redis พบบ่อยแต่ต้องอาศัยการใช้งานที่ถูกต้องอย่างระมัดระวัง (TTL, token ที่ไม่ซ้ำ, การปลดล็อกแบบ atomic) และความตระหนักในข้อจำกัด (Redlock, ความเสี่ยงจาก failover) การเข้าใจ distributed lock กับ Redis — กลไก รายละเอียดความถูกต้อง และข้อจำกัด — จึงเป็นความรู้ที่มีค่าและเกี่ยวข้องในทางปฏิบัติสำหรับการประสานงานแบบกระจาย ซึ่งเป็นหัวข้อที่การเข้าใจกับดักและข้อแลกเปลี่ยนมีความสำคัญพอ ๆ กับเทคนิคพื้นฐาน

Redis lock พื้นฐาน (SET NX พร้อม TTL)

รายละเอียดความถูกต้องที่สำคัญสองข้อ

ข้อจำกัดและ Redlock

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง