قفل های توزیع شده

1) چرا (و چه زمانی) قفل توزیع شده مورد نیاز است

• انتخاب رهبر برای وظیفه پس زمینه/شیدر.
• محدودیت یک مجری بر روی یک منبع مشترک (حرکت فایل، مهاجرت طرح، مرحله پرداخت منحصر به فرد).
• پردازش متوالی از مجموع (کیف پول/سفارش) اگر آن را غیر ممکن است برای رسیدن به idempotency/سفارش در غیر این صورت.

• اگر شما می توانید upsert idempotent، CAS (مقایسه و تنظیم) و یا در هر کلید سفارش را.
• اگر منبع اجازه عملیات جابجایی (CRDT، شمارنده) را بدهد.
• اگر مشکل با یک معامله در یک فروشگاه حل شود.

2) مدل تهدید و خواص

• شبکه: تاخیر، پارتیشن، از دست دادن بسته.
• فرآیندها: مکث GC، توقف جهان، سقوط پس از ضبط قفل.
• زمان: رانش ساعت و جابجایی روش TTL.
• تصرف مجدد: روند «زامبی» پس از شبکه ممکن است فکر می کنم آن را هنوز هم صاحب قلعه.

• ایمنی: بیش از یک مالک معتبر (ایمنی).
• بقا: قفل زمانی آزاد می شود که مالک نتواند (زنده بودن).
• عدالت: روزه وجود ندارد.
• استقلال ساعت: صحت به ساعت دیواری بستگی ندارد (یا با نشانه های شمشیربازی جبران می شود).

3) مدل های اصلی

3. 1 اجاره نامه (قفل اجاره)

قفل با TTL صادر می شود. مالک موظف است قبل از انقضای آن (ضربان قلب/keepalive) آن را تمدید کند.

مزایا: سقوط خود جذب.
خطرات: اگر مالک «گیر کرده» باشد و به کار خود ادامه دهد، اما پسوند را از دست داده است، ممکن است مالکیت مضاعف ایجاد شود.

3. 2 نشانه شمشیربازی

با هر ضبط موفقیت آمیز، تعداد یکنواخت رو به رشد صادر می شود. مصرف کنندگان منابع (پایگاه داده، صف، ذخیره سازی فایل) نشانه را بررسی می کنند و عملیات را با شماره قدیمی رد می کنند.
این برای TTL/اجاره نامه و پارتیشن های شبکه بسیار مهم است - آن را در برابر صاحب «قدیمی» محافظت می کند.

3. 3 قفل حد نصاب (سیستم های CP)

توافق توزیع شده استفاده می شود (قایق/Paxos; etcd/ZooKeeper/Consul)، رکورد با ورود به سیستم اجماع همراه است → مغز تقسیم با اکثر گره ها وجود ندارد.

به علاوه: تضمین های امنیتی قوی.
منفی: حساسیت به حد نصاب (زمانی که آن را از دست داده است, بقا لنگ است).

3. 4 قفل AP (در حافظه/حافظه پنهان + تکرار)

به عنوان مثال، یک خوشه قرمز. در دسترس بودن و سرعت بالا، اما بدون تضمین امنیتی قوی برای پارتیشن های شبکه. نیاز به شمشیربازی در کنار کبودی.

4) پلتفرم ها و الگوها

4. 1 etcd/ZooKeeper/کنسول (توصیه می شود برای قفل قوی)

گره های زودگذر (ZK) یا sessions/leases (etcd): کلید در حالی که جلسه زنده است وجود دارد.
جلسه نگهداری ؛ از دست دادن حد نصاب → جلسه منقضی می شود → قفل آزاد می شود.
گرههای توالی (ZK 'EPHEMERAL _ SEQUENTIAL') برای صف انتظار → fair.

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 قرمز (شسته و رفته)

کلاسیک - 'مقدار کلید SET NX PX ttl'.

• تکرار/feilover ممکن است به صاحبان همزمان اجازه دهد.
• 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 هویت مالک

Store 'owner _ id' (# process # pid # start _ time node) + توکن تصادفی برای باز کردن قفل تأیید.
تکرار باز کردن قفل نباید قفل شخص دیگری را از بین ببرد.

5. 2 TTL و گسترش

TTL <T_fail_detect (زمان تشخیص خطا) و p99 ≥ عملیات بخش بحرانی × یدکی.
تجدید - به صورت دوره ای (به عنوان مثال، هر 'TTL/3')، با مهلت.

5. 3 نشانه شمشیربازی بر روی کبودی

بخش اصلاح منابع خارجی باید «fencing _ token» را منتقل کند.

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

5. ۴ صف انتظار و عدالت

در ZK - 'EPHEMERAL _ SEQUENTIAL' و ناظران: مشتری منتظر انتشار نزدیکترین سلف است.
در etcd - کلید با تجدید نظر/نسخه ؛ دستور توسط 'mod _ revision'.

5. 5 رفتار تقسیم مغز

روش CP: بدون حد نصاب، شما نمی توانید قفل کنید - بهتر است ایستاده از شکستن ایمنی.
رویکرد AP: پیشرفت در جزایر تقسیم شده مجاز است → شمشیربازی مورد نیاز است.

6) انتخاب رهبر

در etcd/ZK، «رهبر» یک کلید منحصر به فرد است ؛ بقيه براي تغييرات ثبت نام کردن.

رهبر ضربان قلب می نویسد ؛ باخت - انتخاب مجدد

همراه با تمام عملیات رهبر با یک نشانه شمشیربازی (تعداد دوره/تجدید نظر).

7) خطاها و پردازش آنها

مشتری در زمان قفل، اما سقوط به کار → هنجار، هیچ کس رنج می برند ؛ TTL/جلسه منتشر خواهد شد.

• نظارت اجباری: اگر پسوند نتواند، بخش بحرانی را قطع کنید و عقب/جبران کنید.
• هیچ «پایان بعد»: بدون قفل، بخش بحرانی را نمی توان ادامه داد.

یک مکث طولانی (GC/stop-the-world) → پسوند اتفاق نیفتاد، دیگری قفل را گرفت. گردش کار باید از دست دادن مالکیت (کانال keepalive) و لغو را تشخیص دهد.

8) ددلوکی، اولویت ها و وارونگی

ددلوکی در یک جهان توزیع شده نادر است (معمولا یک قلعه وجود دارد)، اما اگر چندین قلعه وجود داشته باشد، به یک نظم واحد (نظم قفل) پایبند باشید.
معکوس کردن اولویت: مالک کم اولویت یک منبع را نگه می دارد در حالی که اولویت های بالا صبر می کنند. راه حل: محدودیت TTL، پیشگیری (اگر کسب و کار اجازه می دهد)، sharding از منابع.
روزه: استفاده از صف های انتظار (گره های ZK-sub-order) برای عدالت.

9) قابلیت مشاهده

• 'lock _ acquire _ total {status = ok' timeout 'error}'
• 'lock _ hold _ seconds {p50, p95, p99}'
• 'fencing _ token _ value' (یکنواختی)
• 'lease _ renew _ fail _ total'
• 'split _ brain _ prevented _ total' (تعداد تلاشهای رد شده به دلیل عدم حد نصاب)
• 'preemptions _ total', 'wait _ queue _ len'

• 'lock _ name', 'owner _ id', 'token', 'ttl', 'attempt', 'wait _ time _ ms', 'path' (для ZK), 'mod _ revision' (etcd).
• «به دست آوردن → بخش بحرانی → انتشار» طول می کشد با نتیجه.

• رشد 'اجاره _ تجدید _ شکست _ مجموع'.
• SLO 'lock _ hold _ seconds {p99}'.
• «یتیم» قفل (بدون ضربان قلب).
• لیست های انتظار پر از نفخ

10) مطالعات موردی

10. 1 قفل مجدد امن با شمشیربازی (شبه)

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 + نگهبان (برو)

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/lease) → اطمینان حاصل کنید که صحت توسط نشانه ها/چک ها تضمین شده است.
Crash before release: process crash → lock از طریق TTL/session منتشر میشود.

12) ضد الگوهای

هنگام دسترسی به یک منبع خارجی، قفل TTL را بدون شمشیربازی تمیز کنید.
تکیه بر زمان محلی برای صحت (بدون HLC/شمشیربازی).
توزیع قفل از طریق یک استاد Redis در یک محیط با feilover و بدون تایید کپی.
بخش انتقادی بی نهایت (TTL «برای سنین»).
از بین بردن قفل شخص دیگری بدون چک کردن «owner _ id »/token.
عدم عقب نشینی + jitter → طوفان تلاش.
یک قفل جهانی واحد «برای همه چیز» - یک کیسه درگیری ؛ کلید بهتر است.

13) چک لیست پیاده سازی

• نوع منبع تعریف شده و می تواند CAS/صف/idempotency با dispensed.
• مکانیسم انتخاب شده: etcd/ZK/کنسول برای CP ؛ Redis/cache - فقط با شمشیربازی.
• اجرا شده: 'owner _ id'، پسوند TTL +، دیده بان، باز کردن صحیح.
• منبع خارجی بررسی نشانه شمشیربازی (یکنواختی).
• یک استراتژی رهبری و شکست وجود دارد.
• معیارهای پیکربندی شده، هشدارها، ورود به سیستم نشانه ها و تجدید نظر.
• عقب نشینی + jitter و به دست آوردن زمان ارائه شده است.
• روز بازی برگزار شد: حد نصاب, تقسیم مغز, GC مکث, ساعت انحراف.
• مستندات روش برای گرفتن چند قفل (در صورت لزوم).
• طرح قهوه ای - چه کاری باید انجام دهید زمانی که قفل در دسترس نیست.

14) سوالات متداول

س: آیا قفل Redis 'SET NX PX' به اندازه کافی قفل شده است ؟

A: فقط اگر منبع علامت شمشیربازی را بررسی کند. در غیر این صورت، با پارتیشن بندی شبکه، دو مالک امکان پذیر است.

س: چه چیزی را انتخاب کنید «به طور پیش فرض» ؟

A: برای تضمین دقیق - etcd/ZooKeeper/Consul (CP). برای کارهای آسان در داخل یک پایگاه داده - قفل مشاوره Postgres. Redis - فقط با شمشیربازی.

س: کدام TTL برای قرار دادن ؟

A: 'TTL ≥ p99 مدت زمان بخش بحرانی × 2' و به اندازه کافی کوتاه به سرعت پاک "زامبی. "تجدید - هر" TTL/3 ".

س: چگونه برای جلوگیری از ناشتا ؟

A: صف انتظار به ترتیب (ZK متوالی) یا الگوریتم انصاف ؛ محدود کردن تلاش ها و برنامه ریزی عادلانه

س: آیا به هماهنگ سازی زمان نیاز دارم ؟

A: برای صحت - نه (استفاده از شمشیربازی). برای قابلیت پیش بینی عملکرد، بله (NTP/PTP)، اما برای منطق قفل به ساعت دیواری تکیه نکنید.

15) مجموع

قفل های توزیع شده قابل اعتماد در سطح quorum (etcd/ZK/Consul) با اجاره + keepalive ساخته می شوند و لزوما با علامت شمشیربازی در سطح منابع تغییر می کنند. هر روش TTL/Redis بدون شمشیربازی یک خطر تقسیم مغز است. ابتدا در مورد علیت و بی نظمی فکر کنید، از قفل ها استفاده کنید که بدون آنها غیرممکن است، اندازه گیری، حالت های شکست تست - و «بخش های بحرانی» شما فقط در معنی، نه در تعداد حوادث، باقی خواهد ماند.