როგორ მუშაობს განაწილებული ბლოკირები Redis-ით?

Question

Accepted Answer

**განაწილებული ბლოკირება** კოორდინირებს წვდომას გაზიარებულ რესურსზე რამდენიმე პროცესის/სერვერის მეშვეობით ისე, რომ ერთდროულად მხოლოდ ერთი ფლობს ბლოკირებას. Redis ჩვეულებრივ გამოიყენება ამისთვის ატომური set-if-not-exists-ით TTL-ით — თუმცა სწორად გაკეთება მოითხოვს ფრთხილობას (და შეზღუდვების გაგებას).

## ძირითადი Redis ბლოკირება (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);
  }
}
```

ბლოკირება იყენებს **`SET key value NX EX`**: ატომურად დააყენი გასაღები მხოლოდ თუ ის არ არის (ამიტომ მხოლოდ ერთი კლიენტი წარმატებული ხდება) **TTL**-ით (ისე რომ ბლოკირება ავტომატურად გათავისუფლდება თუ ფლობელი ჩამოვარდება, რაც თავიდან აიცილებს 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.
```

## რატომ აქვს მნიშვნელობა

Redis-ით განაწილებული ბლოკირების გაგება ღირებული ია **გაზიარებულ რესურსებზე წვდომის კოორდინირებისთვის** განაწილებული სისტემების მეშვეობით, ამიტომ ის სასარგებლო ცოდნა — და სისწორის გაფხვიერების გაგება განსაკუთრებით მნიშვნელოვანია.

განაწილებული ბლოკირება რეალურ საჭიროებას მოაგვარებს: უზრუნველყოფს რომ მხოლოდ ერთი პროცესი/სერვერი ასრულებს კრიტიკულ მოქმედებას ერთდროულად (თავიდან აიცილებს დუბლირებულ დამუშავებას, race conditions-ს გაზიარებულ რესურსებზე, ან კონფликტურ ოპერაციებს) მულტი-სერვერ სისტემებში, და Redis ამის ჩვეულებრივი ინსტრუმენტია.

**ძირითადი მექანიზმის** გაგება — `SET key value NX EX` (ატომური set-if-not-exists-ი TTL-ით) რათა მხოლოდ ერთი კლიენტი შეიძენს ბლოკირებას და ის ავტომატურად გათავისუფლდება კრეშის შემთხვევაში — ეს არის საფუძველი ტექნიკა.

კრიტიკულად, **ორი სისწორის დეტალის** გაგება აუცილებელია: **ყოველთვის TTL გამოყენება** (რათა ჩამოვარდული ფლობელის ბლოკირება ავტომატურად მოიშორება, რაც თავიდან აიცილებს მუდმივ deadlock-ს) და **უნიკალური ტოკენის გამოყენება დაკავშირებული გათავისუფლებით** (რათა არ გათავისუფლო შემთხვევით სხვა კლიენტის ბლოკირება თუ თქვენი TTL მოიშორა — ატომური check-then-delete-ით Lua სკრიპტის მეშვეობით).

ეს დეტალები არის ადგილი სადაც ნაივი იმპლემენტაციებს აქვთ დახვეწილი, საშიში ხარვეზები.

თანაბრად მნიშვნელოვანი არის **შეზღუდვების** გაგება: ერთი Redis-ის ბლოკირება არ არის სრულყოფილად უსაფრთხო (TTL ვადის გასვლა სამუშაოს დროს ან failover შეიძლება აშორებდეს ორ კლიენტს რომლებიც ფლობენ მას), რაც იწვევს **Redlock** ალგორითმს (მიღების გაკეთება რამდენიმე Redis კვანძების გაწყობით) უფრო ძლიერი გარანტიებისთვის — და ვიცოდეთ რომ კრიტიკული სისწორისთვის, fencing ტოკენები ან consensus სისტემები (ZooKeeper/etcd) შეიძლება საჭირი იყოს.

ეს ცნობა trade-offs-ისა და შეზღუდვების შესახებ აჩვენებს სიმწიფე გაგებას.

მას შემდეგ რაც გაზიარებული-რესურსის წვდომის კოორდინირება განაწილებული სისტემებში რეალური საჭიროებაა, და რადგან Redis განაწილებული ბლოკირები ხშირი თუმცა მოითხოვს ფრთხილ სწორ იმპლემენტაციას (TTL, უნიკალური ტოკენი, ატომური გათავისუფლება) და ცნობიერების გარანტიას მათი შეზღუდვების შესახებ (Redlock, failover რისკები), Redis-ით განაწილებული ბლოკირების გაგება — მექანიზმი, სისწორის დეტალები, და შეზღუდვები — არის ღირებული, პრაქტიკულად-რელევანტური ცოდნა განაწილებული კოორდინაციისთვის, თემა სადაც hazard-ების და trade-offs-ის გაგება კი ისევე მნიშვნელოვანია როგორც ძირითადი ტექნიკა.