განაწილებული ბლოკირება

1) რატომ (და როდის) საჭიროა განაწილებული ბლოკირება

• ლიდერობა ფონის ამოცანისთვის/შადულერისთვის.
• ერთადერთი კონტრაქტორის შეზღუდვა საერთო რესურსზე (ფაილების გადაადგილება, სქემის მიგრაცია, ექსკლუზიური გადახდის ნაბიჯი).
• დანაყოფის თანმიმდევრული დამუშავება (wallet/რიგის) თუ შეუძლებელია idempotent- ის/მოწესრიგების სხვაგვარად მიღწევა.

• თუ შეგიძლიათ გააკეთოთ idempotent upsert, CAS (compare and set) ან გასაღები (per-key ordering).
• თუ რესურსი საშუალებას აძლევს კომუტატორულ ოპერაციებს (CRDT, მრიცხველები).
• თუ პრობლემა მოგვარებულია ერთ საცავში გარიგებით.

2) მუქარისა და თვისებების მოდელი

• ქსელი: შეფერხებები, განცალკევება, პაკეტების დაკარგვა.
• პროცესები: GC პაუზა, stop-the-world, crash ციხის დაჭერის შემდეგ.
• დრო: საათების დრიფტი და გადაადგილება არღვევს TTL მიდგომებს.
• ხელახალი მფლობელობა: ქსელის შემდეგ „ზომბები“ პროცესმა შეიძლება იფიქროს, რომ ის კვლავ ფლობს საკეტს.

• უსაფრთხოება: არაუმეტეს ერთი რეალური მფლობელი.
• გადარჩენა: ციხე თავისუფლდება მფლობელის ჩამოგდების დროს.
• სამართლიანობა: არ არის მარხვა.
• დამოუკიდებლობა საათებიდან: სისწორე არ არის დამოკიდებული wall-clock- ზე (ან ანაზღაურდება fencing tokens).

3) ძირითადი მოდელები

3. 1 ხე (ქირავნობის ციხე)

ციხე გაიცემა TTL- ით. მეპატრონე ვალდებულია გააგრძელოს იგი გასვლამდე (heartbeat/keepalive).

დადებითი: თვითნაკეთი კრეშით.
რისკები: თუ მეპატრონე „შეჩერებულია“ და აგრძელებს მუშაობას, მაგრამ გაფართოება დაკარგა, შეიძლება ორმაგი საკუთრება წარმოიშვას.

3. 2 Fencing token (ღობეების ნიშანი)

თითოეული წარმატებული დაპყრობით გაიცემა ერთფეროვანი მზარდი ნომერი. რესურსის მომხმარებლები (BD, რიგები, ფაილური საცავი) ამოწმებენ ნიშანს და უარყოფენ ოპერაციებს ძველი ნომრით.
ეს ძალზე მნიშვნელოვანია TTL/Lease და ქსელის განყოფილებებში - ის იცავს „ძველი“ მფლობელისგან.

3. 3 Érum საკეტები (CP სისტემები)

გამოიყენება განაწილებული კონსენსუსი (Raft/Paxos; etcd/ZooKeeper/Consul), ჩანაწერი უკავშირდება კონსენსუსის ლოგოს - კვანძების უმეტეს ნაწილში არ არსებობს სპლიტი.

პლუს: უსაფრთხოების ძლიერი გარანტიები.
მინუსი: მგრძნობელობა კვორუმის მიმართ (მისი დაკარგვით, გადარჩენა კოჭლი ხდება).

3. 4 AP საკეტები (მეხსიერება/ქეში + რეპლიკაცია)

მაგალითად, Redis მტევანი. მაღალი წვდომა და სიჩქარე, მაგრამ ქსელის განყოფილებებში უსაფრთხოების მკაცრი გარანტიების გარეშე. მათ სინქსის მხარეს ფენტეზი სჭირდებათ.

4) პლატფორმები და ნიმუშები

4. 1 etcd/ZooKeeper/Consul (რეკომენდებულია strong locks- ისთვის)

ეფემერული კვანძები (ZK) ან სესიები/სესიები (etcd): გასაღები არსებობს, სანამ სხდომა ცოცხალია.
სესიის კეპალივი; კვორუმის დაკარგვა - სესია იწურება, ციხე თავისუფლდება.
სერიული კვანძები (ZK 'EPHEMERAL _ SEQUENTIAL') სამართლიანობის მოლოდინში.

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 ttl'.

• რეპლიკაცია/ფეილოვერი შეიძლება დაიშვას ერთდროული მფლობელების მიერ.
• რამდენიმე ინსტანციის 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 BD საკეტები

PostgreSQL Advisory locks: Lock, როგორც 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 მფლობელის ვინაობა

შეინახეთ 'owner _ id' (კვანძი # pid # start _ time) + შემთხვევითი შერჩევის ნიშანი.
განმეორებითი unlock არ უნდა ამოიღოს სხვისი ციხე.

5. 2 TTL და გაფართოება

TTL <T _ fail _ detect (გაუმართაობის გამოვლენის დრო) და კრიტიკული განყოფილების p99 მუშაობა × რეზერვი.
გაფართოება - პერიოდულად (მაგალითად, ყოველი 'TTL/3'), deadline.

5. 3 ცისფერი ტოკენი

სექცია, რომელიც ცვლის გარე რესურსს, უნდა გადაეცეს 'fencing _ token ".

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

5. 4 ლოდინი და სამართლიანობა

ZK- ში - 'EPHEMERAL _ SEQUENTIAL "და დამკვირვებლები: კლიენტი ელოდება უახლოესი წინამორბედის განთავისუფლებას.
etcd- ში - გასაღებები გადასინჯვით/ვერსიით; რიგითობა 'mod _ revision'.

5. 5 ქცევა split brain

CP მიდგომა: კვორუმის გარეშე შეუძლებელია საკეტის აღება - უმჯობესია დგომა, ვიდრე უსაფრთხოების დარღვევა.
AP მიდგომა: ნებადართულია წინსვლა განცალკევებულ კუნძულებზე, საჭიროა fencing.

6) ხელმძღვანელობა

Etcd/ZK - „ლიდერი“ არის ექსკლუზიური ეპემერული გასაღები; დანარჩენი გაფორმებულია ცვლილებებისთვის.
ლიდერი წერს heartbeats; ზარალი - ხელახალი არჩევა.
ლიდერის ყველა ოპერაციას თან ახლავს fencing token (ეპოქის/აუდიტის ნომერი).

7) შეცდომები და მათი დამუშავება

კლიენტმა აიღო საკეტი, მაგრამ კრეში, სანამ მუშაობდნენ, არავინ დაზარალდება; TTL/სესია გაათავისუფლებს.

• Watchdog სავალდებულოა: თუ გახანგრძლივება წარუმატებლად დასრულდა, შეაჩერეთ კრიტიკული განყოფილება და გამოტოვეთ/ანაზღაურება.
• მოგვიანებით არ დასრულებულა: ციხის გარეშე, კრიტიკული მონაკვეთის გაგრძელება შეუძლებელია.

გრძელი პაუზა (GC/stop-the-world), გაფართოება არ მომხდარა, მეორემ ციხე აიღო. სამუშაო პროცესმა უნდა გამოავლინოს საკუთრების დაკარგვა (keepalive არხი) და შეწყვიტოს.

8) დედლოკი, პრიორიტეტები და ინვერსია

განაწილებულ სამყაროში ბაბუები იშვიათია (ციხე, როგორც წესი, ერთია), მაგრამ თუ რამდენიმე საკეტი არსებობს, დაიცავით ერთი რიგის დაჭერა.
პრიორიტეტების ინვერსია: დაბალი პრიორიტეტული მფლობელი ინახავს რესურსს, ხოლო მაღალი პრიორიტეტები ელოდება. გადაწყვეტილებები: TTL ლიმიტები, პრემია (თუ ბიზნესი დაუშვებს), ნაგვის რესურსი.
მარხვა: გამოიყენეთ მოლოდინის ხაზები (ZK საწინააღმდეგო კვანძები) სამართლიანობისთვის.

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).
• Spans „acquire - critical section - release“ შედეგით.

• ზრდა 'lease _ renew _ fail _ total'.
• `lock_hold_seconds{p99}` > SLO.
• „ორფის“ საკეტები (heartbeat- ის გარეშე).
• ლოდინის ხაზები.

10) პრაქტიკული მაგალითები

10. 1 უსაფრთხო Redis Castle fencing (ფსევდო)

1. ჩვენ შევინახავთ ნიშნის მრიცხველს საიმედო ნაკადში (მაგალითად, Postgres/etcd).
2. წარმატებული 'SET NX PX- ით, ჩვენ ვკითხულობთ/ვაყენებთ ნიშანს და რესურსს ყველა ცვლილებას ვაკეთებთ ნიშნის შემოწმებით BD/სერვისში.

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, Curator)

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

10. 4 Postgres Advisory lock ვადა (SQL + app)

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

11) Playbooks (თამაშის დღეები)

კვორუმის დაკარგვა: გამორთეთ 1-2 etcd კვანძი - ციხის აღების მცდელობა არ უნდა გაიაროს.
GC პაუზა/stop-the-world: ხელოვნურად შეაჩერეთ მფლობელის ნაკადი, შეამოწმეთ, რომ watchdog წყვეტს მუშაობას.
Split-brain: ქსელის განცალკევების ემულაცია ციხესიმაგრის მფლობელსა და გუშაგებს შორის - ახალი მფლობელი იღებს უფრო მაღალ ფენტეზი ტოკენს, ძველს - უარყოფილია ლურჯი.
Clock skew/drift: აიღეთ საათი მფლობელისგან (Redis/lease- ისთვის), რომ დარწმუნდეთ, რომ სისწორე უზრუნველყოფილია დენებით/შემოწმებებით.
Crash before release: პროცესის ვარდნა - ციხე თავისუფლდება TTL/სესიის მიხედვით.

12) ანტი შაბლონები

სუფთა TTL ციხე fencing გარეშე გარე რესურსზე წვდომისას.
დაეყრდნო ადგილობრივ დროს სისწორისთვის (HLC/fencing გარეშე).
ციხესიმაგრეების განაწილება ერთი Redis ოსტატის მეშვეობით, საშუალოდ, ფეილოვერთან და რეპლიკების დადასტურების გარეშე.
გაუთავებელი კრიტიკული განყოფილება (TTL „საუკუნეების განმავლობაში“).
„უცხო“ ციხის ამოღება „owner _ id “/token- ის შერწყმის გარეშე.
backoff + jitter- ის არარსებობა არის მცდელობების „ქარიშხალი“.
ერთი გლობალური ციხე „ყველაფრისთვის“ - კონფლიქტების ჩანთა; გასაღები უკეთესია.

13) განხორციელების შემოწმების სია

• განისაზღვრება რესურსის ტიპი და შესაძლებელია თუ არა CAS/რიგის/imempotence.
• შეირჩა მექანიზმი: etcd/ZK/Consul for CP; Redis/kesh - მხოლოდ fencing.
• ხორციელდება: 'owner _ id', TTL + გაფართოება, watchdog, სწორი unlock.
• გარე რესურსი ამოწმებს ტოკენის ფიქსაციას (ერთფეროვნება).
• არსებობს ხელმძღვანელობის სტრატეგია და სამართლიანი.
• განლაგებულია მეტრიკა, ალერტა, ნიშნები და გადასინჯვები.
• გათვალისწინებულია backoff + jitter და acquire timauts.
• გაიმართა თამაშის დღეები: კვორუმი, split-brain, GC პაუზები, clock skew.
• რამდენიმე საკეტის აღების პროცედურის დოკუმენტაცია (საჭიროების შემთხვევაში).
• დეგრადაციის გეგმა: რა უნდა გავაკეთოთ ციხის მიუწვდომლობით.

14) FAQ

Q: საკმარისია Redis Castle 'SET NX PX?
A: მხოლოდ იმ შემთხვევაში, თუ რესურსი ამოწმებს ტოკენს. წინააღმდეგ შემთხვევაში, ქსელის დაყოფით შესაძლებელია ორი მფლობელი.

Q: რა უნდა აირჩიოთ ნაგულისხმევი?
A: მკაცრი გარანტიებისთვის - etcd/ZooKeeper/Consul (CP). მსუბუქი დავალებებისთვის, ერთი DD - Advisory locks Postgres. Redis - მხოლოდ fencing.

Q: რა TTL დაყენება?
A: 'TTL - კრიტიკული განყოფილების ხანგრძლივობის p99 × 2' და საკმაოდ მოკლეა „ზომბების“ სწრაფი გაწმენდისთვის. გაფართოება - ყოველი 'TTL/3'.

Q: როგორ ავარიდოთ თავი შიმშილს?
A: მოლოდინის ხაზი (ZK sequential) ან fairness ალგორითმი; მცდელობების ლიმიტი და სამართლიანი დაგეგმვა.

Q: საჭიროა დროის სინქრონიზაცია?
A: სისწორისთვის - არა (გამოიყენეთ fencing). ოპერაციული პროგნოზირებისთვის - დიახ (NTP/PTP), მაგრამ ნუ დაეყრდნობით wall-clock- ს ციხის ლოგიკაში.

15) შედეგები

საიმედო განაწილებული ბლოკები აგებულია კვორუმის ნაკეცებზე (etcd/ZK/Consul) lease + keepalive- ით და ტოკენი აუცილებლად ავსებს ცვლადი რესურსის დონეზე. ნებისმიერი TTL/Redis მიდგომები ღობის გარეშე არის სპლიტ-ბრეინის რისკი. პირველ რიგში, იფიქრეთ კაუზალობასა და იდემპოტენტობაზე, გამოიყენეთ დაბლოკვა, სადაც მათ გარეშე შეუძლებელია, გაზომეთ, შეამოწმეთ უკმარისობის რეჟიმები - და თქვენი „კრიტიკული სექციები“ კრიტიკულად დარჩება მხოლოდ მნიშვნელობით და არა ინციდენტების რაოდენობით.