أقفال موزعة

1) لماذا (ومتى) هناك حاجة إلى أقفال موزعة

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

• إذا كان بإمكانك جعل طلب CAS (مقارنة ومجموعة) أو طلب لكل مفتاح.
• إذا كان المورد يسمح بالعمليات التبادلية (CRDT، العدادات).
• إذا تم حل المشكلة عن طريق معاملة في متجر واحد.

2) نموذج التهديد والممتلكات

• الشبكة: التأخير، التقسيم، فقدان الحزم.
• العمليات: توقف GC مؤقتًا، توقف العالم، تحطم بعد التقاط القفل.
• الوقت: يقترب انجراف الساعة والإزاحة من اقتراب TTL.
• استعادة الملكية: قد تعتقد عملية «الزومبي» بعد الشبكة أنها لا تزال تمتلك القلعة.

• السلامة: لا أكثر من مالك واحد صالح (سلامة).
• البقاء على قيد الحياة: يتم إطلاق القفل عندما يفشل المالك (الحيوية).
• العدالة: لا يوجد صيام.
• استقلال الساعة: لا يعتمد الصواب على ساعة الحائط (أو يتم تعويضه برموز المبارزة).

3) النماذج الرئيسية

3. 1 عقد إيجار (قفل إيجار)

تم إصدار القفل مع TTL. المالك ملزم بتجديده قبل انتهاء الصلاحية (نبضات القلب/الحفظ).

الإيجابيات: تحطيم امتصاص الذات.
المخاطر: إذا كان المالك «عالقًا» واستمر في العمل، لكنه فقد التمديد، فقد تنشأ ملكية مزدوجة.

3. 2 رمز المبارزة

مع كل عملية التقاط ناجحة، يتم إصدار عدد متزايد بشكل رتيب. يقوم مستهلكو الموارد (قاعدة البيانات، قائمة الانتظار، تخزين الملفات) بفحص الرمز ورفض العمليات بالرقم القديم.
هذا مهم للغاية بالنسبة لـ TTL/عقد الإيجار وأقسام الشبكة - فهو يحمي من المالك «القديم».

3. 3 أقفال النصاب (أنظمة CP)

يتم استخدام توافق الآراء الموزع (Raft/Paxos ؛ etcd/ZooKeeper/Consul)، يرتبط السجل بسجل إجماع → لا يوجد انقسام في الدماغ مع معظم العقد.

بالإضافة إلى: ضمانات أمنية قوية.
ناقص: الحساسية للنصاب (عندما يفقد، تكون القدرة على البقاء عرجاء).

3. 4 أقفال AP (داخل الذاكرة/ذاكرة التخزين المؤقت + النسخ المتماثل)

على سبيل المثال، مجموعة Redis. توافر وسرعة عالية، ولكن بدون ضمانات أمنية قوية لتقسيم الشبكة. تطلب سياج على جانب الكدمة.

4) المنصات والأنماط

4. 1 etcd/ZooKeeper/Consul (موصى به للأقفال القوية)

العقد سريعة الزوال (ZK) أو الدورات/عقود الإيجار (etcd): المفتاح موجود أثناء بقاء الدورة على قيد الحياة.
حراسة الجلسة ؛ فقدان النصاب القانوني → تنتهي الدورة → يتم إطلاق القفل.
عقد التسلسل (ZK 'EPHEMERAL _ SEQUERENTIAL') لطابور الانتظار → عادل.

go cli, _:= clientv3. New(...)
lease, _:= cli. Grant(ctx, 10)            // 10s lease sess, _:= concurrency. NewSession(cli, concurrency. WithLease(lease. ID))
m:= concurrency. NewMutex(sess, "/locks/orders/42")
if err:= m. Lock(ctx); err!= nil { / handle / }
defer m. Unlock(ctx)

4. 2 Redis (أنيق)

كلاسيكي - «SET key value NX PX tl».

• قد يسمح التكرار/الخداع للمالكين المتزامنين.
• يقلل Redlock من حالات متعددة من المخاطر، لكنه لا يقضي عليها ؛ مثير للجدل في البيئات ذات الشبكة غير الموثوقة.

من الآمن استخدام Redis كطبقة تنسيق سريعة، ولكن دائمًا ما يكمل رمز السياج في المورد المستهدف.

lua
-- release only if value matches if redis. call("GET", KEYS[1]) == ARGV[1] then return redis. call("DEL", KEYS[1])
else return 0 end

4. 3 أقفال DB

أقفال استشارية PostgreSQL: قفل داخل مجموعة Postgres (العملية/الجلسة).
من الجيد أن تكون جميع الأقسام الحرجة موجودة بالفعل في نفس قاعدة البيانات.

sql
SELECT pg_try_advisory_lock(42); -- take
SELECT pg_advisory_unlock(42); -- let go

4. 4 أقفال الملفات/السحابة

S3/GCS + قفل البيانات الوصفية للكائن مع ظروف «If-Match» (ETag) → بشكل أساسي CAS.
مناسب للنسخ الاحتياطية/الهجرات.

5) تصميم قفل الأمان

5. 1 هوية المالك

تخزين 'howner _ id' (# process # pid # start _ time node) + رمز عشوائي لفتح التحقق.
يجب ألا يزيل الفتح المتكرر قفل شخص آخر.

5. 2 TTL والتمديد

TTL <T_fail_detect (وقت الكشف عن الأخطاء) و p99 ≥ من عملية القسم الحرج × الاحتياطي.
التجديد - بشكل دوري (على سبيل المثال، كل 'TTL/3')، مع الموعد النهائي.

5. 3 رمز المبارزة على كدمة

يجب أن يمر القسم المعدل للمورد الخارجي «سياج _ رمز».

sql
UPDATE wallet
SET balance = balance +:delta, last_token =:token
WHERE id =:id AND:token > last_token;

5. 4 طابور الانتظار والعدالة

في ZK - «EPHEMERAL _ SEQUERENTIAL» والمراقبون: العميل ينتظر إطلاق سراح أقرب سلف.
في ما يلي: المفاتيح مع التنقيح/النسخ ؛ أمر من 'mod _ revision'.

5. 5 سلوك الدماغ المنقسم

نهج CP: بدون النصاب القانوني، لا يمكنك أخذ قفل - من الأفضل الوقوف بدلاً من كسر الأمان.
نهج AP: يُسمح بالتقدم في الجزر المنقسمة → السياج مطلوب.

6) انتخاب الزعيم

في etcd/ZK، «القائد» هو مفتاح أوبائي حصري ؛ يتم تسجيل الباقي للتغييرات.
القائد يكتب نبضات القلب ؛ الخسارة - إعادة الانتخاب.
رافق جميع عمليات القائد برمز سياج (رقم عصر/مراجعة).

7) الأخطاء ومعالجتها

أخذ العميل القفل، ولكن تحطم للعمل → القاعدة، لن يعاني أحد ؛ ستصدر TTL/session.

• الرقابة الإلزامية: إذا فشل التمديد، قاطع القسم الحرج وتراجع/عوض.
• لا يوجد «إنهاء لاحقًا»: بدون قفل، لا يمكن استمرار القسم الحرج.

توقف طويل (GC/stop-the-world) → لم يحدث التمديد، اتخذ الآخر القفل. يجب أن يكتشف سير العمل فقدان الملكية (قناة الحفظ) وإجهاض.

8) ديدلوكي، الأولويات والانعكاس

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

9) إمكانية الملاحظة

• 'lock _ acquire _ total {status = ok' timeout' خطأ '
• 'lock _ hold _ seconds {p50, p95, p99}'
• «سياج _ رمز _ قيمة» (رتابة)
• «إيجار _ تجديد _ فشل _ المجموع»
• «split _ brain _ prevented _ total» (عدد المحاولات المرفوضة بسبب عدم اكتمال النصاب القانوني)
• «الإعفاءات _ المجموع»، «الانتظار _ قائمة الانتظار _ لين»

• «lock _ name», «owner _ id',» token «,» tl «,» treaty «,» wait _ time _ ms', «path» (для ZK), «mod _ revision» (etcd).
• يمتد «الحصول → قسم مهم → الإفراج» مع النتيجة.

• النمو «عقد إيجار _ تجديد _ فشل _ إجمالي».
• «lock _ hold _ seconds {p99}»> SLO.
• أقفال «يتيم» (بدون دقات قلب).
• قوائم انتظار منتفخة.

10) دراسات حالة

10. 1 قفل Redis آمن مع سياج (زائف)

1. نقوم بتخزين العداد الرمزي في متجر موثوق (على سبيل المثال، Postgres/etcd).
2. إذا نجحت «SET NX PX»، فإننا نقرأ/نزيد الرمز المميز ونجري جميع التغييرات على المورد مع تسجيل الرمز في قاعدة البيانات/الخدمة.

python acquire token = db. next_token ("locks/orders/42") # monotone ok = redis. set("locks:orders:42", owner, nx=True, px=ttl_ms)
if not ok:
raise Busy()

critical op guarded by token db. exec("UPDATE orders SET... WHERE id=:id AND:token > last_token",...)
release (compare owner)

10. 2 Etcd Mutex + Watchdog (Go)

go ctx, cancel:= context. WithCancel(context. Background())
sess, _:= concurrency. NewSession(cli, concurrency. WithTTL(10))
m:= concurrency. NewMutex(sess, "/locks/job/cleanup")
if err:= m. Lock(ctx); err!= nil { /... / }

// Watchdog go func() {
<-sess. Done ()//loss of session/quorum cancel ()//stop working
}()

doCritical (ctx )//must respond to ctx. Done()
_ = m. Unlock(context. Background())
_ = sess. Close()

10. 3 القيادة في ZK (جاوة، أمين)

java
LeaderSelector selector = new LeaderSelector(client, "/leaders/cron", listener);
selector. autoRequeue();
selector. start(); // listener. enterLeadership() с try-finally и heartbeat

10. 4 قفل استشاري Postgres مع الموعد النهائي (تطبيق SQL +)

sql
SELECT pg_try_advisory_lock(128765); -- attempt without blocking
-- if false --> return via backoff + jitter

11) كتب اللعب التجريبية (أيام اللعبة)

فقدان النصاب: تعطيل عقد 1-2 etcd → لا ينبغي أن تمر محاولة أخذ القفل.
GC-pause/stop-the-world: تأخير تدفق المالك بشكل مصطنع → التحقق من أن هيئة الرقابة تقطع العمل.
تقسيم الدماغ: محاكاة فصل الشبكة بين المالك وجانب القلعة → يحصل المالك الجديد على رمز أعلى للمبارزة، ويرفض الأزرق القديم.
انحراف الساعة/الانجراف: خذ الساعة بعيدًا عن المالك (لـ Redis/elase) → تأكد من ضمان الصواب من خلال الرموز/الشيكات.
الانهيار قبل الإصدار: يتم إصدار قفل → تحطم العملية عبر TTL/الجلسة.

12) الأنماط المضادة

قفل TTL نظيف بدون سياج عند الوصول إلى مورد خارجي.
الاعتماد على الوقت المحلي من أجل الصواب (لا HLC/المبارزة).
توزيع الأقفال من خلال جهاز Redis Master واحد في بيئة مع feilover ودون تأكيد النسخ المتماثلة.
القسم الحرج اللانهائي (TTL «للأعمار»).
إزالة قفل شخص آخر دون التحقق من «المالك _ معرف »/رمز مميز.
عدم التراجع + النبض → عاصفة المحاولات.
قفل عالمي واحد «لكل شيء» - كيس من الصراعات ؛ قشور المفاتيح أفضل.

13) قائمة التنفيذ المرجعية

• نوع الموارد المحددة ويمكن الاستغناء عن CAS/queue/idempotency.
• الآلية المختارة: etcd/ZK/Consul for CP; Redis/cache - فقط مع السياج.
• نفذ: «مالك _ معرف»، امتداد TTL +، مراقب، فتح صحيح.
• يتحقق المورد الخارجي من رمز السياج (الرتابة).
• هناك استراتيجية قيادة وفشل.
• المقاييس والتنبيهات ورموز قطع الأشجار والمراجعات المكونة.
• يتم توفير Backoff + jitter والحصول على مهلات.
• تقام أيام اللعبة: النصاب، انقسام الدماغ، توقف GC، انحراف الساعة.
• وثائق إجراءات أخذ عدة أقفال (إذا لزم الأمر).
• خطة البني - ماذا تفعل عندما يكون القفل غير متاح.

14) الأسئلة الشائعة

س: هل قفل Redis 'SET NX PX' كافٍ ؟

ج: فقط إذا فحص المورد رمز المبارزة. خلاف ذلك، مع تقسيم الشبكة، يمكن لمالكين اثنين.

س: ماذا تختار «افتراضيًا» ؟

ج: للحصول على ضمانات صارمة - etcd/ZooKeeper/Consul (CP). للمهام السهلة داخل قاعدة بيانات واحدة - أقفال استشارية Postgres. Redis - فقط مع السياج.

س: أي TTL يجب وضعه ؟

ج: "TTL ≥ p99 مدة القسم الحرجة × 2" وقصيرة بما يكفي لإزالة "الزومبي بسرعة. "التجديد - كل" TTL/3 ".

س: كيف تتجنب الصيام ؟

ج: طابور الانتظار بالترتيب (تسلسل ZK) أو خوارزمية الإنصاف ؛ الحد من المحاولات والتخطيط العادل.

س: هل أحتاج إلى تزامن الوقت ؟

ج: للصحة - لا (استخدام السياج). للقدرة على التنبؤ التشغيلي، نعم (NTP/PTP)، لكن لا تعتمد على ساعة الحائط لمنطق القفل.

15) المجاميع

يتم بناء الأقفال الموزعة الموثوقة على مستويات النصاب (etcd/ZK/Consul) مع عقد إيجار + keepalive، ويتم استكمالها بالضرورة برمز سياج على مستوى المورد الذي يتم تغييره. أي نهج TTL/Redis بدون سياج هو خطر انقسام الدماغ. فكر أولاً في السببية والغباء، واستخدم الأقفال حيث يكون ذلك مستحيلًا بدونها، وقم بقياس أوضاع فشل الاختبار - وستظل «أقسامك الحرجة» حاسمة فقط في المعنى، وليس في عدد الحوادث.