사가 및 분산 거래

사가는 장기적인 비즈니스 거래로 다양한 서비스/리포지토리에 걸쳐 일련의 로컬 단계로 분류됩니다. 각 단계에는 부분 장애시 단계 효과를 롤백하는 보상 동작이 있습니다. 2PC/3PC와 달리 사가는 글로벌 잠금 장치를 보유하지 않으며 최종 일관성이 허용되는 마이크로 서비스, 다중 영역 및 높은 하중에 적합합니다.

1) 사가 선택시기 (및 그렇지 않은 경우)

• 장기/다단계 비즈니스 프로세스 (주문 → 결제 → 예약 → 배송).
• 공통 트랜잭션이없는 다른 도메인 및 리포지토리.
• 높은 가용성과 스케일 아웃이 필요합니다.

• 견고한 ACID 원자가 중요합니다 (예: 동일한 레지스트리 내에서 많은 양을 전송).
• 명확한 보상 가능성이 없습니다 (효과를 "예약" 하거나 취소 할 수 없음).
• 법적/규제 제한에는 엄격한 격리와 "즉각적인" 불변이 필요합니다.

2) 사가스 모델

1. Saga Orchestrator-중앙 코디네이터는 단계와 보상을 관리합니다.

장점: 명시 적 흐름, 오류 제어, 단순화 된 원격 측정.
단점: 중앙 집중화 지점, "지방" 코디네이터의 위험.

2. 안무 (안무): 이벤트에 의해 중심-단계가 시작되지 않습니다 ("서비스 A did X → 서비스 B가 반응했습니다").

장점: 연결성이 약하고 스케일링이 간단합니다

단점: 흐름을 추적/디버깅하기가 더 어렵습니다. 규칙의 "스프롤" 위험이 있습니다.

3. TCC (시도/취소) -각 단계는 "시도" 한 다음 확인 또는 취소입니다.

장점: 의사 2 상 프로토콜에 더 가깝고 관리 된 리소스.
단점: 인터페이스 구현에 더 비싸다. "시도" 홀더 타임 아웃이 필요합니다.

3) 피치 및 보상 디자인

불변량: 단계에서 "전후/후에" 진실해야 할 사항을 명확하게 명시합니다 (예: "나머지 3").
보상 방향 트랜잭션: 이는 비즈니스 효과를 취소하는 논리적 조치 (환불, 릴리스, 복원) 입니다.
이데올로기: 단계와 보상기 모두 안전하게 반복해야합니다 ('operation _ id').
타임 아웃: 각 단계에는 마감일이 있습니다. 지연은 보상을 유발합니다.
비 반환 효과: 별도로 기록하고 (알림, 이메일) "최선의 노력" 을 허용하십시오.

4) 일관성과 질서

최종 일관성: 사용자는 시간 불일치를 볼 수 있습니다. UX - "대기 "/스피너/상태.
키별로 주문-비즈니스 키 (order _ id) 별로 전환 단계를 그룹화하여 이벤트를 주문하십시오.
중복 제거-TTL로 처리 로그 ('operation _ id' → 상태) 를 저장하십시오.

5) 운송 및 신뢰성

보내기 패턴은 동일한 트랜잭션 내에서 이벤트를 로컬 아웃 박스 테이블로 작성한 다음 비동기식으로 버스에 게시합니다.
받은 편지함/이념성 저장소: 소비자 측-이미 처리 된 메시지 로그.
정확히 한 번 효과적으로: "Outbox + demempotent 소비자" 는 실용적인 "정확히 한 번" 을 제공합니다.
DLQ: 풍부한 메타 정보와 안전한 재 구동 기능을 갖춘 "유독 한" 메시지.

6) 오류, 재 트레이, 백오프 정책

우리는 dempotent 단계 만 반복합니다. 'Idempotency-Key' 로 작성 작업.
지수 백오프 + 지터; 사가의 시도와 요약 마감일 제한.
체계적인 성능 저하-서킷 브레이커와 우아한 성능 저하 (예: 사가의 2 차 소설 부분을 취소).
비즈니스 충돌 ('409') -조정 후 재 시도 또는 보상 및 종료.

7) 오케스트레이터: 책임과 구조

• 사가의 상태 추적: 'PENDING → RUNNING → COMPENSATING → DONE/FAILED'.
• 계획 단계, 마감일, 타임 아웃, 퇴각.
• 이벤트 라우팅 및 보상 시작.
• 코디네이터 운영의 이념성 (명령 로그).
• 관찰 가능성: 로그/추적/메트릭의 'saga _ id' 상관 관계.

• 표는 'saga', 'saga _ step', '명령', 'outbox' 입니다.
• 'saga _ id', 'business _ key', 'state', 'nethern _ run _ at' 에 색인이 있습니다.

8) 안무: "눈덩이" 에 대한 규칙 및 보호

이벤트 계약: 체계 및 버전 지정 (Avro/Proto/JSON Schema).
명확한 의미론: "이벤트 사실" 대 "명령".
체인 중지: 불일치가 감지 된 서비스는 '실패 '/' 보상' 이벤트를 게시합니다.
"끝없는 고리" 에 대한 경보 및 경고.

9) TCC: 실용적인 세부 사항

시도: TTL의 리소스 예약.
확인: 커밋, 임시 잠금 해제.
취소: 롤백 예약 (부작용없이).
쓰레기 수거: TTL 이후에 자동으로 취소하십시오 (dem 등원 취소).
dempotent를 확인/취소: 반복이 안전합니다.

10) 예 (단어 체계) - "지불 및 배송으로 주문"

1. CreateOrder (로컬) → 아웃 박스: 'OrderCreated'.
2. 지불 서비스: '시도' 예비 (TCC); → 'PaymentReserved' 가 성공하면 'PaymentFailed' → 실패하면.
3. InventoryService: 제품 매장량; → 'InventoryFailed' 에서.
4. 배송 서비스-배송 슬롯 만들기 (취소 가능).
5. '실패한' 단계 → 인 경우 오케 스트레이터는 역순으로 보상을 시작합니다: 'CancelShipping' → 'ReleaseInventory' → 'PaymentCancle'.
6. 모든 확인 → 'Payment확인' → '주문 확인' 인 경우.

11) 오케스트레이터 의사 코드

pseudo startSaga(saga_id, order_id):
steps = [ReservePayment, ReserveInventory, BookShipment, ConfirmPayment]
for step in steps:
res = execWithRetry(step, order_id)
if!res.ok:
compensateInReverse(steps_done(order_id))
return FAIL return OK

execWithRetry(step, key):
for attempt in 1..MAX:
try:
return step.run(key)    # идемпотентно catch RetryableError:
sleep(backoff(attempt))
catch NonRetryableError:
return FAIL return FAIL

compensateInReverse(done_steps):
for step in reverse(done_steps):
step.compensate()       # идемпотентно

12) 관찰 및 운영 SLO

추적: 단일 'saga _ id', 주석 '단계', '시도', '결정' (실행/보상/건너 뛰기).

• 사가의 성공/오류 (%), 평균 지속 시간, p95/p99.
• 보상 된 사가의 비율, 보상의 가장 큰 이유.
• 대기열/아웃 박스가 지연되고 단계적으로 배상됩니다.
• 로그/감사: 오케 스트레이터 솔루션, 리소스 식별자, 비즈니스 키.

13) 테스트와 혼돈

타임 아웃, '5xx', 비즈니스 충돌과 같은 각 단계에 오류를 주입합니다.
순서가 맞지 않는 이벤트, 중복, 삭제.
대기 시간이 길다 → 마감일 및 보상 확인.
대량 사가 → "헤드 라인 차단" 이없는 대기열에서 WFQ/DRR 및 캡을 확인합니다.
단계와 전체 사가에서 DLQ에서 다시 작성하십시오.

14) 다중 임대, 지역, 규정 준수

태그 '테넌트 _ id/계획/지역' 이벤트 및 사가 리포지토리.
거주지: 데이터/이벤트는 해당 지역을 떠나지 않습니다. 지역 간 사가는 지역 사가 + 집계 이벤트의 연합으로 설계되었습니다.
우선 순위: VIP 사가는 할당량 가중치가 더 높습니다. 세입자 당 근로자 격리.

15) 사전 판매 점검표

• 각 단계에는 명확한 보상기가 있으며 둘 다 demmpotent입니다.
• 템플릿 선택: 오케스트레이션/안무/TSS; 책임 제한이 설명됩니다.
• 전송/받은 편지함 구현, 'operation _ id' 에 의한 중복 제거.
• 재 트레이 정책: 지터와의 반발, 시도 제한 및 전반적인 사가 마감일.
• 이벤트 계약은 다양하며 계획의 유효성이 있습니다.
• DLQ 및 보안 릴리스가 구성됩니다.
• 원격 측정: 측정, 추적, 상관 관계 'saga _ id'.
• 운영 플레이 북: 수동 취소/강제 확인, "매달린" 사가 잠금 해제.
• 카오스 및로드 테스트가 통과되고 SLO/오류 예산이 정의됩니다.

16) 전형적인 오류

보상기가 없거나 "부정한" 상태입니다 (부작용이 있음).
상태의 복식과 "스윙" 이라는 dempotence/dedup은 없습니다.
명시적인 경계가없는 "Saga in Saga" - 사이클 및 상호 잠금.
마감일 → "영원한" 사가 및 자원 유출은 없습니다.
오케 스트레이터는 안정적인 저장소없이 상태를 "메모리에" 저장합니다.
원격 측정 센터가없는 안무 → "보이지 않는" 실패.
Opaque UX: 사용자는 중간 상태를 볼 수 없습니다.

17) 빠른 레시피

SaaS 클래식: 오케스트레이션 + 아웃 박스/받은 편지함, 지수 백오프, DLQ, UI의 사가 상태.
강력한 리소스 불변: 예비 TTL 및 GC 취소 기능이있는 TCC.
대량/부하: 이벤트 안무 + 엄격한 dempotency 및 주요 측정 항목.
다중 지역: 로컬 사가 + 최종 집계; 글로벌 잠금 장치를 피하십시오.

결론

Sagas는 글로벌 잠금 장치없이 분산 시스템에서 예측 가능한 일관성을 얻는 방법입니다. 명확한 보상기, demotence, 안정적인 배송 (아웃 박스/받은 편지함), 타임 아웃 및 재 트레이 훈련, 원격 측정 및 플레이 북은 점점 더 많은 부하, 서비스 및 지역으로 복잡한 비즈니스 프로세스를 안정적으로 읽을 수 있도록하는 열쇠입니다.