Бөлүштүрүлгөн блоктор

1) Эмне үчүн (жана качан) бөлүштүрүү кулпу керек

• Лидер (leader election) үчүн фон тапшырмасы/шедулер.
• Бир гана аткаруучуну жалпы ресурска чектөө (файлдарды көчүрүү, схеманы көчүрүү, эксклюзивдүү төлөм кадамы).
• Эгерде демпотенттикке/тартипке башкача жетишүү мүмкүн болбосо, агрегатты ырааттуу иштетүү (wallet/order).

• Эгерде сиз dempotent upsert кыла аласыз, CAS (compare-and-set) же ачкыч кезек (per-key ordering).
• Эгерде ресурс коммутациялык операцияларга жол берсе (CRDT, эсептегичтер).
• Эгерде маселе бир сактагычтагы транзакция менен чечилсе.

2) коркунуч модели жана касиеттери

• Тармак: кечигүү, бөлүү (partition), пакеттерди жоготуу.
• Процесстер: GC тыныгуу, stop-the-world, кулпу алынгандан кийин crash.
• Убакыт: Сааттын жылышы жана жылышы TTL ыкмаларын бузат.
• Кайталап ээлик кылуу: "зомби" - тармактан кийин процесс дагы эле кулпуга ээ деп ойлошу мүмкүн.

• Коопсуздук: бир гана чыныгы ээси (коопсуздук).
• Тиричилик: кулпу ээси бузулганда бошотулат (liveness).
• Адилеттүүлүк: орозо жок.
• саат көз карандысыздыгы: туура wall-clock көз каранды эмес (же жабуу tokens ордун толтурат).

3) Негизги моделдер

3. 1 Lease (ижара сепили)

Кулпу TTL менен берилет. Ээси мөөнөтү аяктаганга чейин узартууга милдеттүү (heartbeat/keepalive).

Артыкчылыктары: crash боюнча өзүн-өзү жөнгө салуу.
Тобокелдик: эгерде ээси "илинип", ишин улантса, бирок узартууну жоготсо, кош ээлик болушу мүмкүн.

3. 2 Fencing токен (Токен тосмо)

Ар бир ийгиликтүү басып алууда монотондуу өсүп жаткан номер берилет. Ресурстун керектөөчүлөрү (DD, кезек, файлдык сактоо) токенди текшерип, эски номер менен операцияларды четке кагышат.
Бул TTL/lease жана тармактык бөлүштүрүү өтө маанилүү болуп саналат - "эски" ээсинен коргойт.

3. 3 Quorum кулпулары (CP системалары)

бөлүштүрүлгөн консенсус (Raft/Paxos; etcd/ZooKeeper/Consul), жазуу консенсус блогуна байланыштуу → көпчүлүк түйүндөрүндө эч кандай бөлүнүү тыныгуу.

Plus: күчтүү коопсуздук кепилдиктери.
Минус: кворумга сезгичтик (аны жоготкондо, жашоого жөндөмдүүлүк аксайт).

3. 4 AP кулпулары (in-memory/кэш + репликация)

Мисалы, Redis-кластер. Жогорку жеткиликтүүлүк жана ылдамдык, бирок тармактык бөлүнүүдө катуу коопсуздук кепилдиктери жок. Алар синк тарабында fencing талап кылат.

4) Платформалар жана үлгүлөр

4. 1 etcd/ZooKeeper/Consul (strong locks үчүн сунушталат)

Эфемер түйүндөр (ZK) же сессиялар/leases (etcd): ачкыч сессия жашап жатканда бар.
Сессия keepalive; кворум жоготуу → сессия аяктайт → кулпу бошотулат.
Катар түйүндөрү (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 колдонуу коопсуз, бирок ар дайым максаттуу ресурста fencing токенди толуктоо.

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 БД кулпулары

PostgreSQL advisory locks: Postgres кластердин алкагында лок (жараян/сессия).
Бардык сынчыл бөлүмдөр жана бир DD болгондо жакшы.

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

4. 4 File/булут "кулпулары"

S3/GCS + "If-Match" (ETag) шарттары менен объект метадерил лок → негизинен CAS.
Бэкап/миграция үчүн ылайыктуу.

5) Коопсуз кулпу дизайн

5. 1 Ээсинин идентификациясы

Сактагыла 'owner _ id' (түйүн #процесс #pid #start_time) + unlock боюнча текшерүү үчүн кокустук токен.
Кайталап unlock башка бирөөнүн кулпусун алып салбашы керек.

5. 2 TTL жана узартуу

TTL <T_fail_detect (мүчүлүштүктөрдү аныктоо убактысы) жана ≥ p99 критикалык бөлүмдүн иши × запасы.
Узартуу - мезгил-мезгили менен (мисалы, ар бир 'TTL/3'), менен deadline.

5. 3 Синка боюнча Fencing токен

Тышкы ресурсту өзгөрткөн бөлүм '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-мамиле: Quorum жок кулпу алуу мүмкүн эмес - жакшы коопсуздук сындырып караганда туруп.
AP-мамиле: бөлүнгөн аралдарда прогресске жол → fencing зарыл.

6) лидерлик (leader election)

etcd/ZK - "лидер" өзгөчө эпемер ачкычы болуп саналат; калгандары өзгөртүүлөргө кол коюлду.
Лидер heartbeats жазган; жоготуу - кайра шайлоо.
Лидердин бардык операциялары fencing token (доордун/ревизиянын номери) менен коштолот.

7) Каталар жана аларды иштетүү

Кардар кулпуну алды, бирок иш → нормага чейин, эч ким зыян тартпайт; TTL/сессия бошотулат.

• Милдеттүү watchdog: узартуу ийгиликсиз болсо - сындуу бөлүмүн үзгүлтүккө учуратып ,/ордун толтуруу.
• Эч кандай "кийин бүтүрүү": кулпусуз критикалык секцияны улантуу мүмкүн эмес.

Узак тыныгуу (GC/stop-the-world) → узартуу болгон жок, башка кулпу алды. Иш процесси ээлик жоготууну (keepalive каналы) аныктап, үзгүлтүккө учуратышы керек.

8) Dedlock, артыкчылыктар жана инверсия

бөлүштүрүлгөн дүйнөдө Dedlock сейрек (кулпу, адатта, бир), бирок бир нече кулпулар болсо - алуу үчүн бирдиктүү тартибин кармануу (lock ordering).
Артыкчылыктардын өзгөрүшү: төмөн артыкчылыктуу ээси жогорку артыкчылыктуу күтүп жатканда ресурсту кармап турат. Solutions: TTL-лимиттери, preemption (бизнес жол берсе), ресурстук бөлүшүү.
Орозо: адилеттүүлүк үчүн күтүү кезектерин (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).
• Span "acquire → critical section → release" натыйжасы менен.

• Өсүү 'lease _ renew _ fail _ total'.
• `lock_hold_seconds{p99}` > SLO.
• "Жетим" кулпулары (heartbeat жок).
• Толкунданып кезек күтүүлөр.

10) Практикалык мисалдар

10. 1 Коопсуз Redis-кулпу менен fencing (psevdo)

1. Токен эсептегичти ишенимдүү сактайбыз (мисалы, Postgres/etcd).
2. Ийгиликтүү 'SET NX PX' токенди окуйбуз/инкременттейбиз жана бардык ресурстук өзгөрүүлөрдү DB/кызматта токенди текшерүү менен жасайбыз.

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, Куратор)

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) Test Playbook (Оюн күндөрү)

Quorum жоготуу: өчүрүү 1-2 түйүндөр ETCD → кулпуну алуу аракети өтпөшү керек.
GC-тыныгуу/stop-the-world: жасалма ээсинин агымын кармап → watchdog ишин үзгүлтүккө учуратып жатканын текшерүү.
Split-brain: ээси менен кулпу тараптардын ортосундагы тармактык бөлүнүүнү эмуляциялоо → жаңы ээси жогорку чектөөчү токенди алат, эски - синк тарабынан четке кагылат.
Clock skew/drift: саат ээсинен (Redis/lease үчүн) → тактык токендер/текшерүүлөр менен камсыз болушун камсыз кылуу.
Crash before бошотуу: түшүү жараяны → кулпу TTL/сессия боюнча бошотулат.

12) Анти-үлгүлөрү

Таза TTL-кулпу тышкы ресурсту жетүү менен fencing жок.
тактык үчүн жергиликтүү убакыт таянуу (HLC/fencing жок).
Кулпуларды бир Redis мастер аркылуу Failover менен чөйрөдө жана эч кандай ырастоосуз бөлүштүрүү.
Чексиз сын бөлүгү (TTL "кылымдар бою").
"Башка бирөөнүн" кулпусун 'owner _ id '/token салыштыруусуз алып салуу.
Жок backoff + jitter → "бороон" аракет.
Бирдиктүү Global Castle "бардык" - чыр-чатак баштык; ачкычы жакшы.

13) Киргизүү чек-тизмеси

• Ресурстун түрү аныкталган жана CAS/кезек/демпотенттик менен күрөшүүгө болобу.
• Тандалган механизм: CP үчүн etcd/ZK/Consul; Redis/кэш - гана fencing менен.
• ишке ашырылган: 'owner _ id', TTL + узартуу, watchdog, туура unlock.
• Тышкы ресурс чектөөчү токенди (монотондук) текшерет.
• лидерлик жана failover стратегиясы бар.
• Орнотулган метрика, Алерт, Логин жана текшерүү.
• backoff + jitter жана acquire боюнча таймауттар каралган.
• өткөрүлгөн game days: quorum, split-brain, GC-тыныгуулар, clock skew.
• Бир нече кулпуларды алуу тартибин документтештирүү (талап кылынса).
• Деградация планы (brownout): кулпу жеткиликсиз болгондо эмне кылуу керек.

14) FAQ

Q: жетиштүү Redis-кулпу 'SET NX PX'?
A: Ресурс fencing token текшерет гана. Болбосо, тармактык бөлүнүүдө эки ээси болушу мүмкүн.

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) натыйжалары

Ишенимдүү бөлүштүрүлгөн блоктор lease + keepalive менен кворум стокторуна (etcd/ZK/Consul) курулган жана өзгөрүлмө ресурстун деңгээлинде fencing токени сөзсүз түрдө толукталат. тосмосу жок ар кандай TTL/Redis-ыкмалары - split-breen коркунучу. Адегенде каузалдуулук жана демпотенттик жөнүндө ойлонуңуз, аларсыз мүмкүн болбогон жерде кулпуларды колдонуңуз, өлчөңүз, баш тартуу режимдерин сынаңыз - жана сиздин "критикалык секцияларыңыз" окуялардын саны боюнча эмес, мааниси боюнча гана маанилүү бойдон калат.