갈등 감지 및 해결
1) 갈등으로 간주되는 것
충돌은 둘 이상의 변경 소스가 동일한 엔티티, 리소스 또는 불변의 호환되지 않는 상태를 주장하는 상황입니다.
구문: 하나의 파일/키로 겹치는 변경 사항 (Git의 병합 충돌, Kustomize의 패치 충돌).
시맨틱: 체계에 따라 정확한 문서가 비즈니스 불변량을 위반합니다 (직불 금액, 신용 한도 초과).
운영/시간: 인종 쓰기/읽기, 중복 이벤트, 원인 결과 불일치.
도메인: 리소스에 대한 경쟁 작업 (이중 티켓 판매, 오버 북 상품).
과제: 가능한 한 빨리 충돌을 감지하고 원인을 설명하고 자동 복구, 재 트레이, 합병, 보상, 에스컬레이션 등 행동 중 하나를 안전하게 선택하십시오.
2) 탐지 메커니즘
2. 1 버전 및 상태 비교
REST의 ETag/If-Match, DB의 rowversion/xmin-업데이트 감지가 손실되었습니다.
3 방향 병합 (기본, 우리, 그들의 것) -호환되지 않는 편집을 강조 표시합니다.
필드/문서 별 스케일/해시-저렴한 비교.
2. 2 시간 및 인과 라벨
램 포트 시계: 총 순서 "대략적인 시간".
2. 불변량과 구속 조건 3 개
계획 및 유효성 검사기 (JSON Schema/OpenAPI) - 구문 유효성.
불변량: 독창성, 비 부정성, 균형, ACL 규칙.
무결성 검사: FK/UNIQUE/EXCLUDE 인덱스, 부분 제약 조건.
도메인은 코드/정책 (OPA/Kyverno/Conftest) 에서 주장합니다.
2. 4 이벤트 스트림에서의 탐지
Idempotency Key/Dedup Store (예: TTL을 사용한 Redis/DB): 테이크 거부.
스트리밍에서 거래/정확하게 한 번: 거래 ID, 프로듀서 epoch, consummer-offset.
시퀀스 갭 감지: 갭, 반복 (n, n + 1, n + 1).
2. 5 관찰 및 알람
오류/충돌/재 트레이 프로메트릭.
3) 해결 전략
3. 1 완전 자동 (정의에 따라 안전)
CRDT (충돌없는 복제 데이터 유형): G- 카운터, PN- 카운터, OR-Set, LWW- 등록, 맵/그래프 CRDT.
조정없이 수렴을 보장; 손실/보존 의미론의 선택이 중요합니다.
정류 작업: 모든 순서 (증분, 로그 부속기) 로 적용됩니다.
Idempotent 처리기: 반복으로 결과가 변경되지 않습니다 (키에 따라 결석, 결석).
구조의 낙관적 인 병합: 결정 론적 순서와 '딥 병합 + 정책'.
3. 2 반자동 (정책 포함)
3 방향 병합 + 배열 규칙 ('추가' uniqueBy (키) | patchBy (키) ').
LWW (Last-Write-Wins): 단순하지만 인과 관계 정확성 상실 위험.
소스의 우선 순위는 "파일> 기본값에서 대화식 입력> 설정" 입니다.
비즈니스 규칙: "한도를 초과하면 부분 확인/보상".
3. 3 조정
OCC/MVCC (낙관적 차단/다중 버전): 버전 조정, 재 트레이.
비관적 인 자물쇠: 'SELECT... 업데이트 ', 분산 잠금 장치 (Redlock/DB-lock/etcd).
합의 (Raft/Paxos): 한 지도자가 질서를 결정합니다. 충돌이 적고 가격은 대기 시간입니다.
3. 4 인칭 루프 (HITL)
수동 합병/중재를위한 UI (특히 컨텐츠, 관세, 카탈로그).
디파 미리보기, 정책 설명, 버튼: "우리/그들의 것을 받아들입니다", "병합 필드", "보상 생성".
4) 아키텍처 계층별 패턴
4. 1 API/REST/gRPC
낙관적 인 동시성: 'If-Match: <etag>', 충돌의 경우 409/412 → 클라이언트가 새로운 ETag를 고려하여 수축합니다.
POST (지불/주문) 의 Idempotency-Key.
시맨틱 409: 이유를 알리고 행동을 제안하십시오.
4. 데이터웨어 하우스 2 개
RDBMS: MVCC (스냅 샷 격리), 고유 인덱스, 부분 인덱스.
KV/Doc 스토어: 버전/개정 (rev), 비교 및 교환 (CAS).
멀티 마스터 복제: 중요한 엔티티에 대해서만/CRDT 사용 또는 리더에게 쓰기.
4. 3 대기열/스트리밍
정확히 한 번 (실제로- "실제로 한 번"): 거래 생산자 + 원자 쓰기 싱크.
콘솔에 데드 업: 마지막 N id, upsert/merge 로직 저장.
전송/받은 편지함 패턴: 일관된 이벤트 게시.
4. 4 가지 구성 및 IaC
사용하기 전에 정책 게이트 (OPA/Kyverno) 인 GitOps에 3 방향 병합.
Kustomize/Helm: 결정 론적 병합 전략 및 "알 수없는 키" 금지.
테라 폼: "드리프트 대 원하는" 충돌 신호로서의 플랜 디프.
5) 알고리즘 및 예
5. 1 3 방향 병합 (단순화)
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 hunks5. REST 리소스 용 OCC 2 개
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"}클라이언트는 델타를 다시 읽고 현재 상태에 적용하며 반복합니다.
5. 3 시맨틱 갈등 (불변)
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 (스케치)
요소는 특정 태그에 대해 고유 한 태그, 삭제와 함께 추가됩니다.
"추가 대 제거" 충돌은 제거 태그를 사용하여 가시적 인 추가 태그 만 제거하여 해결됩니다.
6) 해결 정책: 공식화하는 방법
건축 교리를 설명하십시오
1. 우선 순위 체인.
2. 데이터 유형별 전략: 스칼라/객체/어레이/멀티미디어.
3. 인과 모델: 버전, Lamport, 벡터 시계를 사용합니까?
4. 손실 의미론: 합의가 필요한 LWW에서 잃을 수있는 것.
5. 시간 창: 중복 제거를위한 TTL, demempotency 창.
6. 확대: 자동 해상도가 금지되면 UI/승인 요구 사항.
7. 보상: 불변량을 재 조립하기위한 SAGA 전략 "취소/보상".
7) 측정 및 SLO
(PHP 3 = 3.0.6, PHP 4)
(PHP 3 = 3.0.6, PHP 4)
(PHP 3 = 3.0.6, PHP 4)
(PHP 3 = 3.0.6, PHP 4)
demempotency _ hit _ rate-작동하는 Idempotency 키의 비율.
발산 _ 깊이는 복제 발산 (버전 벡터) 의 깊이입니다.
SLO 예: "구문 충돌의 99% 이상이 5 초 안에 자동으로 해결되고 HITL과 15 분 안에 의미 충돌이 발생합니다".
8) 실제 시나리오
8. 1 지불
키: Idempotency-Key, 균형에 관한 OCC, 가역적 단계에 대한 SAGA.
충돌: 이중 대차 대조표 → 대차 대조표 버전 확인 → 부분 보상.
8. 인벤토리/티켓 2 개
옵션: 비관적 슬롯/시트 차단; TTL이 만료되는 낙관적 예약; 비교 및 예약 대기열.
8. 콘텐츠/카탈로그 3 개
3 방향 병합 + HITL: 편집기는 총계를 선택합니다. "안전한" 필드에 대한 자동 규칙 (가격에 영향을 미치지 않는 SEO 태그)
8. 4 GitOps/Kubernetes
적용 전 렌더 및 검증; 알 수없는 키에 대한 거부; 검토하지 않고 "-강제" 금지.
드리프트 감지 및 정책 시행 롤백.
9) 반 패턴
어디에서나 LWW: 인과 관계 손실의 대가로 단순성.
demempotency가없는 숨겨진 retrays: 눈사태와 같은 복제본.
명시적인 배열 정책이 없습니다-구성 지점의 자동 손실.
네트워크 위의 글로벌 뮤텍스: SPOF 및 긴 잠금 장치.
원인 감사없이 "맹인" 보상: 반복적 인 충돌.
10) 구현 점검표
- 도메인 충돌 유형 및 불변량을 정의하십시오.
- 버전화 메커니즘 (ETag/xmin/vector clock) 을 선택하십시오.
- 중요한 POST/명령에서 dem 등급을 사용하십시오.
- 데이터 유형 (스칼라/어레이/객체) 별로 병합 정책을 설정하십시오.
- 스키마 유효성 검사 및 사전 커밋 도메인 검사를 사용하십시오.
- 충돌 및 경고 메트릭 설정.
- 중요한 실체-리더/컨센서스 또는 CRDT.
- HITL 흐름 및 UX (diff, 의견, 감사 로그) 를 해결하십시오.
- 문서 SLO 및 보상 절차 (SAGA).
11) FAQ
Q: CRDT를 언제 선택하고 언제 합의를 선택해야합니까?
A: CRDT는 최종 일관성이 허용되고 높은 가용성/로컬 항목이 중요 할 때 적합합니다. 합의-엄격한 불변량과 엄격한 운영 순서 (현금 잔액, 액세스 권한) 의 데이터에 대한 데이터.
Q: LWW가 충분합니까?
A: 캐시, 지표 및 2 차 지수의 경우 종종 그렇습니다. 사용자 데이터와 돈의 경우 거의 항상 그렇지 않습니다.
Q: 중복 제거 창을 어떻게 선택합니까?
A: 예상되는 최대 재전송 지연 + 네트워크 지터에 중점을두고 3-5 × 항목 99의 마진을 추가하십시오.
Q: 항상 HITL을해야합니까?
A: 아니요. 분쟁/가치 충돌에 대한 HITL을 자동화하고 나머지는 기록하십시오.
12) 총계
효과적인 충돌 감지 및 해결은 적절한 알고리즘 (CRDT/OT/OCC/MVCC/컨센서스) 과 관찰 가능성으로 보완 된 버전, 인과 레이블, 불변 및 명확한 정책의 조합입니다. 갈등이 "정상적인" 상황 인 시스템은 접근 가능하고 예측 가능합니다. 충돌이 "예외" 인 시스템은 최악의 시간에 분해됩니다. 모델을 선택하고 규칙을 공식화하고 결과를 측정하십시오.