Redis-உடன் விநியோகிக்கப்பட்ட locks எவ்வாறு செயல்படுகின்றன?

Question

Accepted Answer

ஒரு **விநியோகிக்கப்பட்ட lock** பல செயல்முறைகள்/சேவையகங்கள் முழுவதும் பகிரப்பட்ட வளத்திற்கான அணுகலை ஒருங்கிணைக்கிறது, இதனால் ஒரு முறையில் ஒன்று மட்டுமே lock ஐ வைத்திருக்கும். Redis பொதுவாக atomic set-if-not-exists உடன் TTL மூலம் இதற்காகப் பயன்படுத்தப்படுகிறது — இருப்பினும் இதை சரியாகச் செய்ய கவனம் தேவைப்படுகிறது (மற்றும் வரம்புகளைப் புரிந்துகொள்ள).

## ஒரு அடிப்படை Redis lock (SET NX with 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`** ஐப் பயன்படுத்துகிறது: atomic ஆக key ஐ அப்போதுதான் அமைக்கவும் (இதனால் ஒரு client மட்டுமே வெற்றிபெறும்) **TTL** உடன் (இதனால் lock auto-releases ஆகிறது holder crash செய்தால், 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
```

## வரம்புகள் மற்றும் 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 உடன் விநியோகிக்கப்பட்ட locks ஐ புரிந்துகொள்ளுதல் **விநியோகிக்கப்பட்ட அமைப்புகளுக்கு முழுவதும் பகிரப்பட்ட வளங்களுக்கான அணுகலை ஒருங்கிணைப்பதற்கான** மதிப்புள்ளது, எனவே இது பயனுள்ள அறிவு — மற்றும் correctness pit falls ஐ புரிந்துகொள்ளுதல் குறிப்பாக முக்கியமாக இருக்கிறது.

விநியோகிக்கப்பட்ட locks ஒரு உண்மையான தேவையை உணர்த்துகிறது: மல்டி-சர்வர் அமைப்புகளில் ஒரு critical action ஐ ஒரு process/server மட்டுமே செய்ய உறுதிப்படுத்துதல் (duplicate processing, பகிரப்பட்ட வளங்களில் race conditions, அல்லது conflicting operations ஐ தடுத்தல்), மற்றும் Redis இதற்கான பொதுவான tool ஆகும்.

**அடிப்படை mechanism** — `SET key value NX EX` (atomic set-if-not-exists with a TTL) ஐ புரிந்துகொள்ளுதல் இதனால் ஒரு client மட்டுமே lock ஐ பெறுகிறது மற்றும் crash ல் auto-releases ஆகிறது — foundational technique ஆகும்.

நिर्ణायকமாக, **இரண்டு correctness விவரங்களை** புரிந்துகொள்ளுதல் essential ஆகும்: **எப்போதும் TTL ஐப் பயன்படுத்துதல்** (இதனால் crashed holder ன் lock auto-expires ஆகிறது, permanent deadlock ஐ தவிர்க்கிறது) மற்றும் **unique token உடன் matched release ஐப் பயன்படுத்துதல்** (இதனால் உங்கள் TTL expire ஆனால் வேறு client ன் lock ஐ accidentally release செய்ய மாட்டீர்கள் — atomic check-then-delete via a Lua script உடன்).

இந்த விவரங்கள் naive implementations இல் subtle, dangerous bugs ஆ இருக்கின்றன.

Similarly முக்கியமாக **வரம்புகளை** புரிந்துகொள்ளுதல் ஆகும்: single-Redis lock perfectly safe அல்ல (TTL expiry mid-work அல்லது failover இரு clients ஐ hold செய்ய அனுமதி கொடுக்கலாம்), இது **Redlock** algorithm க்கு (பல Redis nodes முழுவதும் acquiring) stronger guarantees க்கு leading — மற்றும் critical correctness க்கு, fencing tokens அல்லது consensus systems (ZooKeeper/etcd) தேவையிருக்கலாம் என்பதை அறிந்துகொள்ளுதல்.

Trade-offs மற்றும் வரம்புகளின் இந்த awareness mature understanding ஐ பிரதிபலிக்கிறது.

Distributed systems இல் பகிரப்பட்ட-வளங்கள் access ஐ ஒருங்கிணைப்பது உண்மையான தேவை என்பதிலிருந்து, மற்றும் Redis விநியோகிக்கப்பட்ட locks பொதுவது ஆனால் careful correct implementation (TTL, unique token, atomic release) மற்றும் அவற்றின் வரம்புகளின் awareness (Redlock, failover risks) தேவைப்படும் என்பதிலிருந்து, விநியோகிக்கப்பட்ட locks உடன் Redis ஐ புரிந்துகொள்ளுதல் — mechanism, correctness விவரங்கள், மற்றும் வரம்புகள் — valuable, practically-relevant அறிவு விநியோகிக்கப்பட்ட ஒருங்கிணைப்புக்கு, ஒரு topic இல் understanding the pitfalls மற்றும் trade-offs basic technique ஐ போல் முக்கியமாக இருக்கிறது.