Wykrywanie i rozwiązywanie konfliktów

1) Co jest uważane za konflikt

Konflikt jest sytuacją, w której dwa lub więcej źródeł zmian twierdzi niezgodne ze wspólnym rynkiem stany tego samego podmiotu, zasobu lub niezmienne.

Syntaktyka: nakładanie się zmian na jeden plik/klucz (konflikt scalania w Git, kolizja plastrów w Kustomize).
Semantyczne: dokument poprawny zgodnie z systemem narusza niezmienną działalność gospodarczą (kwota debetowa, kredyt, przekroczony limit).
Operacyjne/czasowe: wyścigi zapisu/odczytu, duplikaty zdarzeń, rozbieżności przyczynowo-skutkowe.
Domena: konkurencyjne operacje na zasób (podwójna sprzedaż biletów, towary za książką).

Zadanie: jak najszybciej wykryć konflikt, wyjaśnić jego przyczynę i bezpiecznie wybrać jedno z działań: automatyczne odzyskiwanie, przekwalifikowanie, połączenie, odszkodowanie, eskalacja.

2) Mechanizmy wykrywania

2. 1 Wersioning i porównanie stanu

ETag/If-Match in REST, rowversion/xmin in DB - lost update detection.
3-way fuzja (baza, nasza, ich) - podkreślając niezgodne edycje.
Checksum/Hash według pola/dokumentu - tanie porównanie.

2. 2 Etykiety czasowe i przyczynowe

Zegar Lamport: całkowite zamówienie „przybliżone w czasie”.

2. 3 Niezmienne i ograniczenia

Schematy i walidatory (JSON Schema/OpenAPI) - ważność syntaktyczna.
Niezmienne: wyjątkowość, brak negatywności, równowaga, zasady ACL.
Kontrola integralności: indeksy FK/UNIQUE/EXCLUDE, ograniczenia częściowe.
Testy domeny w kodzie/zasadach (OPA/Kyverno/Conftest).

2. 4 Wykrywanie w strumieniach zdarzeń

Idempotence Key/Dedup Store (np. Redis/DB z TTL): odrzucenie odbioru.
Transactional/Dokładnie raz w strumieniowaniu: identyfikator transakcyjny, epoka producenta, consummer-offset.
Wykrywanie szczeliny sekwencji: luki, powtórzenia (n, n + 1, n + 1).

2. 5 Obserwowalność i alarm

Błąd/kolizja/Retray Prometrics.

3) Strategie restrukturyzacji i uporządkowanej likwidacji

3. 1 W pełni automatyczny (z definicji bezpieczny)

CRDT (wolne od konfliktów typy danych replikowanych): licznik G, licznik PN, zestaw LUB, rejestr LWW, mapa/wykres CRDT.

zapewnienie konwergencji bez koordynacji; wybór semantyki utraty/retencji jest ważny.
Operacje komutacyjne: stosowane w dowolnej kolejności (przyrosty, dodatki dziennika).
Idempotent handlers: powtórzenie nie zmienia wyniku (upsert by key, put-if-absent).
Optymistyczne połączenie struktur: „głębokie połączenie + polityka” z deterministycznym porządku.

3. 2 Półautomatyczne (z polityką)

Trójdrożne scalanie + reguły tablicowe („zastąpić” dodać „ujednolicone Przez (klucz) | patchBy (klucz)”).
LWW (Last-Write-Wins): proste, ale ryzyko utraty poprawności przyczynowej.
Priorytety źródeł to „interaktywne wejście> config z pliku> domyślne”.
Zasady prowadzenia działalności: „w przypadku przekroczenia limitu - częściowe potwierdzenie/odszkodowanie”.

3. 3 Koordynacja

OCC/MVCC (optymistyczne blokowanie/wielopoziomowe): pojednanie wersji, retray.
Zamki pesymistyczne: 'SELECT... DLA AKTUALIZACJI ', blokady rozproszone (Redlock/DB-lock/etcd).
Konsensus (Raft/Paxos): jeden lider decyduje o zamówieniu; jest mniej konfliktów, ceną jest opóźnienie.

3. 4 Osoba w pętli (HITL)

Interfejs dla Manual Fuzje/Arbitrażowe (zwłaszcza Zawartość, Taryfy, Katalogi).
Podgląd diffa, wyjaśnienie zasad, przyciski: „zaakceptuj nasze/ich”, „połączyć pola”, „stwórz odszkodowanie”.

4) Wzory według warstw architektury

4. 1 API/REST/gRPC

Optymistyczne współistnienie: „If-Match: <etag>”, 409/412 w przypadku konfliktu → wycofania klienta z uwzględnieniem świeżego ETag.
Idempotency-Key in POST (płatności/zlecenia).
Semantyczne 409: Informowanie o przyczynach i proponowanych działaniach.

4. 2 Magazyny danych

RDBMS: MVCC (izolacja migawek), unikalne indeksy, indeksy częściowe.
Sklepy KV/Doc: wersje/wersje (rev), porównanie-i-swap (CAS).
Replikacja wielopoziomowa: Użyj/CRDT lub napisz do lidera tylko dla podmiotów krytycznych.

4. 3 kolejki/Streaming

Dokładnie raz (praktycznie - „skutecznie raz”): producent transakcyjny + atomowy write-to-sink.
Dedup na konsoli: przechowywanie ostatniego N id, upsert/merge logic.
Wzorzec skrzynki odbiorczej/skrzynki odbiorczej: konsekwentne publikowanie wydarzeń.

4. 4 Konfiguracje i IaC

3-sposób połączenia w GitOps, bramki polityki (OPA/Kyverno) przed użyciem.
Kustomize/Helm: deterministyczne strategie łączenia i zakaz „nieznanych kluczy”.
Terraform: plan-diff jako „drift vs wanted” sygnał konfliktu.

5) Algorytmy i przykłady

5. 1 trójstronne połączenie (uproszczone)

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. 2 OCC dla zasobów REST

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"}

Klient powtarza, stosuje deltę do bieżącego stanu i powtarza.

5. 3 Konflikt semantyczny (niezmienny)

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 (szkic)

Elementy są dodawane z unikalnym znacznikiem, usuwanie - dla określonego znacznika.
Konflikt „add vs remove” jest rozwiązywany za pomocą znaczników usuwania, aby usunąć tylko widoczne znaczniki dodawania.

6) Polityka restrukturyzacji i uporządkowanej likwidacji: jak sformalizować

1. Łańcuch priorytetowy.

2. Strategie według typu danych: skalary/obiekty/tablice/multimedia.

3. Model przyczynowy: używasz wersji, Lamport, zegary wektorowe.

4. Semantyka strat: co można stracić w LWW, gdzie potrzebny jest konsensus.

5. Okna czasowe: TTL do deduplikacji, okna idempotencji.

6. Eskalacja: gdy zabroniona jest automatyczna rozdzielczość, wymagania dotyczące interfejsu użytkownika/zatwierdzenia.

7. Rekompensaty: strategie SAGA „anulować/zrekompensować” za ponowne składanie stałych.

7) Mierniki i SLO

conflicts_total{type} to częstotliwość według typu.
conflicts_resolved_auto_ratio - udział auto-pozwoleń.
mean_time_to_resolution jest średni czas rozliczenia.
lost_update_incidents - Przypadki utraty aktualizacji.
idempotency_hit_rate - odsetek kluczy Idempotence, które działały.
divergence_depth jest głębokość dywergencji repliki (wektory wersji).

Przykład SLO: „≥ 99% konfliktów syntaktycznych rozwiązuje się automatycznie w ≤ 5 sekund, konflikty semantyczne w ≤ 15 minut z HITL”.

8) Scenariusze praktyczne

8. 1 Płatności

Klucz: Idempotency-Key, OCC on balance, SAGA dla odwracalnych kroków.
Konflikt: podwójne umorzenie → kontrola dedup + wersja bilansowa → częściowa rekompensata.

8. 2 Zapasy/bilety

Opcje: pesymistyczne blokowanie gniazda/siedzenia; optymistyczna rezerwacja z wygaśnięciem TTL; kolejka porównawcza i rezerwowa.

8. 3 Zawartość/katalogi

3-way merge + HITL: edytor wybiera łącznie; Zasady auto dla „bezpiecznych” pól (znaczniki SEO, które nie wpływają na cenę)

8. 4 gitopy/kubernety

renderowanie i walidacja przed złożeniem wniosku; odrzucić nieznane klucze; zakaz „--force” bez przeglądu.
Wykrywanie dryfów i wymuszanie polityki.

9) Anty-wzory

LWW wszędzie: prostota kosztem utraty przyczynowości.
Ukryte przekładki bez idempotencji: duplikaty przypominające lawinę.
Brak wyraźnych zasad tablicy - cicha utrata punktów konfiguracyjnych.
Globalne muteksy na szczycie sieci: SPOF i długie zamki.
„Ślepe” odszkodowania bez kontroli przyczyny: powtarzające się konflikty.

10) Lista kontrolna wdrażania

• Zdefiniuj typy konfliktów domen i niezmienne.
• Wybierz mechanizm wersji (ETag/xmin/wektor zegar).
• Włącz idempotencję w krytycznym POST/poleceniach.
• Ustaw politykę scalania według typu danych (skalary/tablice/obiekty).
• Włączanie walidatorów schematów i wstępne kontrole domen.
• Konfiguracja liczników zderzeń i alarmów.
• W przypadku podmiotów krytycznych - lider/konsensus lub CRDT.
• Wypracuj przepływ HITL i UX (diff, komentarze, dziennik audytu).
• Dokumenty SLO i procedury kompensacyjne (SAGA).

11) FAQ

P: Kiedy wybrać CRDT i kiedy wybrać konsensus?
Odp.: CRDT jest odpowiednia, gdy możliwa jest ewentualna konsystencja i ważna jest wysoka dostępność/lokalne wpisy. Konsensus - dla danych ze sztywnymi stałymi i ścisłym porządkiem operacji (salda gotówkowe, prawa dostępu).

P: Czy wystarczy LWW?
Odp.: Dla buforów, mierników i indeksów wtórnych - często tak. Dla danych użytkowników i pieniędzy, prawie zawsze nie.

P: Jak wybrać okno deduplikacji?
Odp.: Skoncentruj się na maksymalnym oczekiwanym opóźnieniu w ponownej dostawie + jitter sieciowy, dodaj margines 3-5 × pozycja 99.

P: Czy zawsze powinieneś robić HITL?
Odp.: Nie. Pozostaw HITL dla konfliktów spornych/wartości zautomatyzować i zalogować resztę.

12) Kwoty całkowite

Skuteczne wykrywanie i rozwiązywanie konfliktów to połączenie wersji, etykiet przyczynowych, niezmiennych i jasnych polityk uzupełnionych odpowiednimi algorytmami (CRDT/OT/OCC/MVCC/consensus) oraz obserwowalności. systemy, w których konflikt jest sytuacją „normalną”, pozostają dostępne i przewidywalne; systemy, w których konflikt jest „wyjątkiem”, rozpadają się w najgorszym możliwym czasie. Wybierz model, sformalizuj zasady i zmierz wynik.