كيف تعمل الأقفال الموزعة مع Redis؟

Question

Accepted Answer

يقوم **القفل الموزع** بتنسيق الوصول إلى مورد مشترك عبر عمليات/خوادم متعددة بحيث يحتفظ به واحد فقط في كل مرة. يُستخدم Redis بشكل شائع لهذا الغرض عبر set-if-not-exists ذري مع TTL — لكن القيام به بشكل صحيح يتطلب عناية (وفهم القيود).

## قفل Redis أساسي (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);
  }
}
```

يستخدم القفل **`SET key value NX EX`**: تعيين المفتاح بشكل ذري فقط إذا كان غائباً (بحيث ينجح عميل واحد فقط) مع **TTL** (بحيث يتم تحرير القفل تلقائياً إذا انهار المالك، مما يتجنب الجمود).

## تفاصيل صحة حرجة

```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 مفيد لـ **تنسيق الوصول إلى الموارد المشتركة** عبر الأنظمة الموزعة، لذا فهي معرفة مفيدة — وفهم مخاطر الصحة بشكل خاص مهم جداً.

تعالج الأقفال الموزعة احتياجاً حقيقياً: التأكد من أن عملية/خادم واحد فقط ينفذ إجراءً حرجاً في كل مرة (منع المعالجة المكررة أو حالات تنافس الموارد المشتركة أو العمليات المتضاربة) في الأنظمة متعددة الخوادم، و Redis هو أداة شائعة لهذا.

فهم **الآلية الأساسية** — `SET key value NX EX` (تعيين ذري إذا كان غير موجود مع TTL) بحيث يكتسب عميل واحد فقط القفل ويتم تحريره تلقائياً عند الانهيار — هي التقنية الأساسية.

بشكل حرج، فهم **تفاصيل الصحة الاثنتين** ضروري: **استخدام TTL دائماً** (بحيث ينتهي قفل المالك المنهار تلقائياً، مما يتجنب الجمود الدائم) و**استخدام رمز فريد مع تحرير متطابق** (بحيث لا تحرر عن طريق الخطأ قفل عميل آخر إذا انتهت صلاحية TTL — مع فحص ذري ثم حذف عبر سكريبت Lua).

هذه التفاصيل هي حيث تحتوي التطبيقات الساذجة على أخطاء دقيقة وخطيرة.

من المهم بنفس القدر فهم **القيود**: قفل Redis الواحد ليس آمناً تماماً (انتهاء TTL أثناء العمل أو المفاضلة يمكن أن يسمح لعميلين بالاحتفاظ به)، مما يؤدي إلى **خوارزمية Redlock** (الحصول عليها عبر عقد Redis متعددة) لضمانات أقوى — ومعرفة أنه للصحة الحرجة، قد تكون هناك حاجة إلى رموز الحد من الأضرار أو أنظمة الإجماع (ZooKeeper/etcd).

هذا الوعي بالمقايضات والقيود يعكس فهماً ناضجاً.

نظراً لأن تنسيق الوصول إلى الموارد المشتركة في الأنظمة الموزعة احتياج حقيقي، وبما أن أقفال Redis الموزعة شائعة لكنها تتطلب تطبيقاً صحيحاً دقيقاً (TTL، رمز فريد، تحرير ذري) والوعي بقيودها (Redlock، مخاطر المفاضلة)، فهم الأقفال الموزعة مع Redis — الآلية وتفاصيل الصحة والقيود — معرفة قيمة وعملية لتنسيق النظام الموزع، وهو موضوع حيث يكون فهم المخاطر والمقايضات مهماً مثل التقنية الأساسية.