Redis के साथ distributed locks कैसे काम करते हैं?

Question

Accepted Answer

एक **distributed lock** कई processes/servers में एक shared resource तक पहुँच का समन्वय करता है ताकि एक समय में केवल एक ही lock को धारण करे। Redis का उपयोग आमतौर पर इसके लिए atomic set-if-not-exists के साथ TTL के माध्यम से किया जाता है — हालाँकि इसे सही तरीके से करने के लिए सावधानी की आवश्यकता होती है (और limitations को समझने की)।

## एक basic Redis lock (TTL के साथ SET NX)

```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 को atomically केवल तभी set करें जब वह अनुपस्थित हो (ताकि केवल एक client सफल हो) एक **TTL** के साथ (ताकि holder के crash होने पर lock auto-release हो जाए, deadlock से बचा जा सके)।

## दो महत्वपूर्ण correctness विवरण

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

## Limitations और 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.
```

## यह क्यों महत्वपूर्ण है

Redis के साथ distributed locks को समझना distributed systems में **shared resources तक पहुँच का समन्वय** करने के लिए मूल्यवान है, इसलिए यह उपयोगी ज्ञान है — और correctness pitfalls को समझना विशेष रूप से महत्वपूर्ण है।

Distributed locks एक वास्तविक आवश्यकता को संबोधित करते हैं: multi-server systems में यह सुनिश्चित करना कि एक समय में केवल एक process/server एक critical action करे (duplicate processing, shared resources पर race conditions, या conflicting operations को रोकना), और Redis इसके लिए एक आम tool है।

**Basic mechanism** को समझना — `SET key value NX EX` (TTL के साथ atomic set-if-not-exists) ताकि केवल एक client lock acquire करे और crash पर यह auto-release हो — foundational technique है।

महत्वपूर्ण रूप से, **दो correctness विवरण** को समझना आवश्यक है: **हमेशा TTL का उपयोग करना** (ताकि crashed holder का lock auto-expire हो जाए, स्थायी deadlock से बचा जा सके) और **matched release के साथ unique token का उपयोग करना** (ताकि आप गलती से किसी अन्य client का lock release न करें यदि आपका TTL expire हो गया हो — Lua script के माध्यम से atomic check-then-delete के साथ)।

ये विवरण वहाँ हैं जहाँ naive implementations में सूक्ष्म, खतरनाक bugs होते हैं।

समान रूप से महत्वपूर्ण है **limitations** को समझना: एक single-Redis lock पूरी तरह सुरक्षित नहीं है (mid-work में TTL expiry या failover दो clients को lock धारण करने दे सकता है), जो मजबूत guarantees के लिए **Redlock** algorithm की ओर ले जाता है (कई Redis nodes में acquire करना) — और यह जानना कि critical correctness के लिए fencing tokens या consensus systems (ZooKeeper/etcd) की आवश्यकता हो सकती है।

trade-offs और limitations के प्रति यह जागरूकता परिपक्व समझ को दर्शाती है।

चूँकि distributed systems में shared-resource पहुँच का समन्वय एक वास्तविक आवश्यकता है, और चूँकि Redis distributed locks आम हैं लेकिन सावधानीपूर्वक सही implementation (TTL, unique token, atomic release) और उनकी limitations (Redlock, failover risks) के प्रति जागरूकता की आवश्यकता है, Redis के साथ distributed locks को समझना — mechanism, correctness विवरण, और limitations — distributed coordination के लिए मूल्यवान, व्यावहारिक रूप से प्रासंगिक ज्ञान है, एक ऐसा विषय जहाँ pitfalls और trade-offs को समझना basic technique जितना ही महत्वपूर्ण है।