Deteksiya və münaqişələrin həlli

1) Münaqişə hesab etmək nədir

Münaqişə iki və ya daha çox dəyişiklik mənbəyinin eyni mahiyyət, resurs və ya invariantın uyğun olmayan vəziyyətlərini iddia etdiyi bir vəziyyətdir.

Sintaktik: bir fayl/açarın üst-üstə düşən dəyişiklikləri (Git-də merge conflict, Kustomize-də patch toqquşmaları).
Semantik: sxem üzrə düzgün sənəd biznes invariantını pozur (kredit ≠ debet məbləği, limit aşılıb).
Əməliyyat/müvəqqəti: səsyazma/oxu yarışı, təkrarlanan hadisələr, səbəb-nəticə əlaqələrinin uyğunsuzluğu.
Domen: resurs üzərində rəqabətli əməliyyatlar (ikiqat bilet satışı, mal overbook).

Məqsəd: münaqişəni mümkün qədər tez aşkar etmək, onun səbəbini izah etmək və hərəkətlərdən birini təhlükəsiz seçmək: avtomobil bərpası, retraj, birləşmə, kompensasiya, eskalasiya.

2) Deteksiya mexanizmləri

2. 1 Version və vəziyyətlərin müqayisəsi

ETag/If-Match in REST, rowversion/xmin in DB - lost update aşkarlanması.
3-way merge (base, ours, theirs) - uyğun olmayan düzəlişlərin işıqlandırılması.
Sahə/sənəd üzrə Checksum/Hash - ucuz müqayisə.

2. 2 Müvəqqəti və səbəb işarələri

Lamport clock: ümumi sifariş «təxminən vaxt».

2. 3 Invariantlar və məhdudiyyətlər

Sxemlər və validatorlar (JSON Schema/OpenAPI) - sintaktik validlik.
İnvariantlar: unikallıq, mənfi olmayan, balans, ACL qaydaları.
Bütövlük yoxlamaları: FK/UNIQUE/EXCLUDE indeksləri, partial constraints.
Domen assert 'kodu/siyasətləri (OPA/Kyverno/Conftest).

2. 4 Hadisə axınlarında deteksiya

Idempotency Key/Dedup Store (məsələn, Redis/TTL ilə DB): dublların rədd edilməsi.
Transactional/Exactly-once: transactional id, producer epoch, konsumer-ofset.
Sequence gap detection: keçid, təkrar (n, n + 1, n + 1).

2. 5 Müşahidə və siqnalizasiya

Səhvlərin/münaqişələrin/retrajların prometrikası.

3) Həll strategiyaları

3. 1 Tam avtomatik (tərifinə görə təhlükəsiz)

CRDT (Conflict-free Replicated Data Types): G-Counter, PN-Counter, OR-Set, LWW-Register, Map/Graph CRDT.

Koordinasiya olmadan yaxınlaşma zəmanəti; zərərlərin/qənaət semantikasının seçilməsi vacibdir.
Kommutativ əməliyyatlar: hər hansı bir qaydada tətbiq olunur (inkrementlər, log-appendlər).
Idempotent handlers: təkrarlama nəticəni dəyişmir (açar upsert, put-if-absent).
Strukturların optimist birləşməsi: 'deep merge + policy' determinant qaydada.

3. 2 Yarı avtomatik (siyasətlə)

3-way merge + massiv qaydaları ('replace' append 'uniqueBy (key) | patchBy (key)').
LWW (Last-Write-Wins): sadə, lakin səbəb düzgünlüyünü itirmək riski.
Mənbələrin prioritetləri: «interaktiv giriş> > defoltlar».
Biznes qaydaları: «limit aşarsa - qismən təsdiq/kompensasiya».

3. 3 Koordinasiya

OCC/MVCC (optimist kilidləmə/çox versiyalı): versiyaların müqayisəsi, retraj.
Pessimist bloklama: 'SELECT... FOR UPDATE ', paylanmış loki (Redlock/DB-lock/etcd).
Konsensus (Raft/Paxos): bir lider qaydanı həll edir; daha az münaqişə, qiymət - gizli.

3. 4 Kontur adam (HITL)

Manual merj/arbitraj üçün UI (xüsusilə - məzmun, tariflər, kataloqlar).
Diffanın ön görünüşü, siyasətin izahı, düymələr: «ours/theirs almaq», «sahələri birləşdirmək», «kompensasiya yaratmaq».

4) Memarlıq təbəqələrinə görə nümunələr

4. 1 API/REST/gRPC

Optimistic concurrency: 'If-Match: <etag>', 409/412 münaqişə zamanı → müştəri təzə ETag nəzərə retrait.
Idempotency-Key üçün POST (ödənişlər/sifarişlər).
Semantik 409: səbəb və təklif olunan hərəkətləri bildirin.

4. 2 Məlumat anbarları

RDBMS: MVCC (snapshot isolation), unikal indekslər, qismən indekslər.
KV/Doc stores: versiyalar/reviziyalar (rev), compare-and-swap (CAS).
Multimaster replikasiyası: kritik varlıqlar üçün/CRDT və ya «write to leader only» versiyalarını tətbiq edin.

4. 3 Növbələr/axın

Exactly-once (praktiki olaraq - «effektiv bir dəfə»): əməliyyat prodüseri + atom write-to-sink.
Konsumerdə dedup: son N id, upsert/merge məntiqi saxlamaq.
Outbox/Inbox deseni: hadisələrin razılaşdırılmış nəşri.

4. 4 Konfiqurasiya və IaC

3-way merge GitOps, tətbiq əvvəl policy-gates (OPA/Kyverno).
Kustomize/Helm: determinant merj strategiyaları və «naməlum açarların» qadağan edilməsi.
Terraform: «drift vs desired» münaqişə siqnalı kimi plan-diff.

5) Alqoritmlər və nümunələr

5. 1 3-way merge (sadələşdirilmiş)

text resolve(base, ours, theirs):
diff1 = delta(base, ours)
diff2 = delta(base, theirs)
if independent(diff1, diff2): return apply(base, diff1 ⊕ diff2)
if conflictsOnlyInArrays: return arrayPolicyMerge(...)
else:
return CONFLICT with hunks

5. REST resursu üçün 2 OCC

http
Client reads
GET /accounts/42 -> ETag: "v17", body: {balance: 100}

Trying to write off
PUT /accounts/42
If-Match: "v17"
{balance: 50}

If someone has managed before
HTTP/1. 1 412 Precondition Failed
{error: "version_mismatch", currentEtag: "v18"}

Müştəri yenidən oxuyur, deltanı mövcud vəziyyətə tətbiq edir və təkrarlayır.

5. 3 Semantik münaqişə (invariant)

pseudo on Debit(accountId, amount):
current = read(accountId)
if current. balance - amount < 0:
return REJECT ("insufficient _ funds") # write early detection (accountId, version = current. version+1, balance=current. balance - amount)

5. 4 CRDT: OR-Set (eskiz)

Elementlər unikal tag ilə əlavə edilir, çıxarılması - xüsusi tag ilə.
«add vs remove» münaqişəsi etiketlər sayəsində həll olunur: remove yalnız görünən add etiketlərini silir.

6) Həll siyasəti: necə rəsmiləşdirmək

1. Mənbə sırası (priority chain).

2. Məlumat növləri üzrə strategiyalar: skalyarlar/obyektlər/massivlər/multimedia.

3. səbəb model: Siz versiyası istifadə edib, Lamport, vector clocks.

4. Zərərin semantikası: konsensus lazım olan LWW-də nə itirilə bilər.

5. Müvəqqəti pəncərələr: Deduplikasiya üçün TTL, idempotentlik pəncərələri.

6. Eskalasiya: avto icazə qadağan olunduqda, UI/approval tələbləri.

7. Kompensasiya: İnvariantların yenidən seçilməsi üçün «cancel/compensate» SAGA strategiyası.

7) Metrika və SLO

conflicts_total{type} - növlərə görə tezlik.
conflicts_resolved_auto_ratio - avto-icazələrin payı.
mean_time_to_resolution - həll üçün orta vaxt.
lost_update_incidents - itirilmiş yeniləmə hadisələri.
idempotency_hit_rate - işləmiş Idempotency açarlarının payı.
divergence_depth - replikaların (versiya vektorlarının) uyğunsuzluq dərinliyi.

SLO nümunəsi: «Sintaktik konfliktlərin 99% ≥ avtomatik olaraq HITL ilə ≤ 5 saniyədə, semantik konfliktlər ≤ 15 dəqiqədə həll olunur».

8) Praktik ssenarilər

8. 1 Ödənişlər

Açar: idempotentlik (Idempotency-Key), balansda OCC, geri dönən addımlar üçün SAGA.
Münaqişə: ikiqat silinmə → deadup + balans versiyasının yoxlanılması → qismən kompensasiya.

8. 2 Inventar/biletlər

Seçimlər: pessimist slot/yer kilidi; bitən TTL ilə optimist sifariş; «compare-and-reserve» növbəsi.

8. 3 Məzmun/kataloqlar

3-way merge + HITL: redaktor nəticəni seçir; «təhlükəsiz» sahələr üçün avtomatik qaydalar (qiymətə təsir etməyən SEO etiketləri).

8. 4 GitOps/Kubernetes

Tətbiq edilməzdən əvvəl render və validasiya; reject on unknown keys; qadağa «--force» ağlamadan.
Drift-deteksiya və policy-enforced geri dönüş.

9) Anti-nümunələr

LWW hər yerdə: səbəbiyyət itkisi bahasına sadəlik.
İdempotentlik olmadan gizli retrajlar: uçqun təkrarları.
Massivlərin açıq siyasətinin olmaması: konfiqurasiya nöqtələrinin «sakit» itkisi.
SPOF və uzun bloklama: Şəbəkə üzərindəki qlobal myutekslər.
«Kor» heç bir səbəb audit kompensasiya: təkrar münaqişələr.

10) Giriş çek siyahısı

• Domen konfliktləri və invariantları müəyyən edin.
• Version mexanizmini seçin (ETag/xmin/vector clock).
• Kritik POST/commands-da idempotentliyi daxil edin.
• Məlumat növlərinə (skalyarlar/massivlər/obyektlər) görə merj siyasətini təyin edin.
• Sxem validatorları və domen yoxlamalarını commit-ə daxil edin.
• Konfliktlərin metriklərini və alarmları konfiqurasiya edin.
• Kritik varlıqlar üçün - lider/konsensus və ya CRDT.
• HITL flow və UX (diff, şərhlər, audit log) işləyin.
• SLO və kompensasiya prosedurlarını (SAGA) sənədləşdirin.

11) FAQ

Q: CRDT nə vaxt seçilir və konsensus nə vaxt?
A: CRDT eventual consistency və yüksək mövcudluğu/yerli qeydlər vacib olduqda uyğundur. Konsensus - sərt invariantlar və əməliyyatların ciddi qaydası (pul balansları, giriş hüquqları) olan məlumatlar üçün.

Q: LWW kifayət edirmi?
A: caches, metrik və ikincil indekslər üçün - tez-tez bəli. İstifadəçi məlumatları və pul üçün - demək olar ki, həmişə yoxdur.

Q: duplikasiya pəncərəsini necə seçmək olar?
A: Maksimum gözlənilən təkrar çatdırılma gecikməsinə diqqət yetirin + şəbəkə jitter, 3-5 × p99 ehtiyat əlavə edin.

Q: həmişə HITL etmək lazımdır?
A: Yox. HITL mübahisəli/dəyər münaqişələri üçün tərk edin; qalanları avtomatlaşdırın və loqolun.

12) Nəticələr

Effektiv deteksiya və münaqişələrin həlli uyğun alqoritmlərlə (CRDT/OT/OCC/MVCC/konsensus) və müşahidə olunma qabiliyyəti ilə tamamlanmış versiya, səbəb işarələri, invariantlar və aydın siyasətin birləşməsidir. Münaqişənin «normal» vəziyyət olduğu sistemlər əlçatan və proqnozlaşdırıla bilən olaraq qalır; münaqişənin «istisna» olduğu sistemlər ən əlverişsiz anda qırılır. Model seçin, qaydaları rəsmiləşdirin və nəticəni ölçün.