ES / CQRS 동시성 처리

최근에 직장에서 적용해야하므로 CQRS / ES로 뛰어 들기 시작했습니다. 많은 문제를 해결할 것이기 때문에 우리의 경우에는 매우 유망한 것으로 보입니다.

ES / CQRS 앱이 간단한 은행 사용 사례 (돈을 인출)에 상황에 맞는 것처럼 보이는 방법에 대한 대략적인 이해를 스케치했습니다.

요약하자면, A 개인이 돈을 인출하면 :

• 명령이 내려졌다
• 검증 / 검증을위한 명령이 전달됨
• 유효성 검증에 성공하면 이벤트가 이벤트 저장소로 푸시됩니다.
• 애그리 게이터는 이벤트를 대기열에서 제거하여 집계에 수정 사항을 적용합니다.

내가 이해 한 바에 따르면, 이벤트 로그는 사실의 원천입니다. FACTS의 로그이므로 이벤트 로그를 투영 할 수 있습니다.

자,이 위대한 계획에서 이해하지 못하는 것은이 경우에 일어나는 일입니다.

• 규칙 : 잔액은 음수 일 수 없습니다
• 사람 A의 잔액은 100e입니다
• 개인 A가 100e의 철회 명령을 발행 함
• 유효성 검사가 통과되고 100e 이벤트의 MoneyWithdrewEvent가 생성됩니다.
• 그 동안 개인 A는 100e의 다른 철회 명령을 발행합니다.
• 첫 번째 MoneyWithdrewEvent가 집계되지 않았으므로 집계에 대한 유효성 검사 (아직 업데이트되지 않은)에 대한 유효성 검사가 이루어지기 때문에 유효성 검사가 통과됩니다.
• MoneyWithdrew100e의 이벤트가 다른 시간에 방출됩니다

==> 잔액이 -100e에 일치하지 않는 상태이며 로그에 MoneyWithdrewEvent가 2 개 있습니다.

이 문제를 해결하기위한 몇 가지 전략이 있습니다.

• a) 이벤트 버전에서 이벤트와 함께 집계 버전 ID를 넣어 수정시 버전이 일치하지 않으면 아무 일도 일어나지 않습니다.
• b) 검증 계층이 어떻게 든 하나를 생성해야 함을 암시하는 일부 잠금 전략을 사용하십시오.

전략과 관련된 질문 :

• a)이 경우, 이벤트 로그는 더 이상 진실의 원천이 아니며 처리 방법은 무엇입니까? 또한 인출을 허용하는 것은 완전히 잘못된 반면 클라이언트로 돌아 왔습니다.이 경우 잠금을 사용하는 것이 더 낫습니까?
• b) 잠금 == 교착 상태, 모범 사례에 대한 통찰력이 있습니까?

전반적으로, 동시성을 처리하는 방법에 대한 이해가 정확합니까?

참고 : 나는 같은 짧은 시간에 돈을 두 번 인출하는 것이 불가능하다는 것을 이해하지만 세부 사항을 잃지 않기 위해 간단한 예를 들었습니다.

ES / CQRS 앱이 간단한 은행 사용 사례 (돈을 인출)에 상황에 맞는 것처럼 보이는 방법에 대한 대략적인 이해를 스케치했습니다.

이것은 이벤트 소스 응용 프로그램의 완벽한 예입니다. 시작하자.

명령이 처리되거나 재 시도 될 때마다 (인내심을 가지고) 다음 단계가 수행됩니다.

1. 명령이 명령 핸들러, 즉의 서비스에 도달합니다 Application layer.
2. 명령 핸들러 Aggregate는 저장소를 식별하여 저장소에서로드합니다 (이 경우로드는 인스턴스 를 new호출 Aggregate하고이 집계에서 이전에 생성 된 모든 이벤트를 가져 와서 집계 자체에 다시 적용하여 수행됨) . 나중에 사용; 이벤트가 적용된 후 집계는 최종 상태에 있습니다 (즉, 현재 계정 잔액은 숫자로 계산 됨)
3. 명령 핸들러는에 적절한 방법을 호출 Aggregate처럼, Account::withdrawMoney(100)그리고 굴복 이벤트, 즉 수집 MoneyWithdrewEvent(AccountId, 100); 계좌에 돈이 충분하지 않으면 (잔액 <100) 예외가 발생하고 모든 것이 중단됩니다. 그렇지 않으면 다음 단계가 수행됩니다.
4. 명령 핸들러는 Aggregate저장소 를 유지하려고 시도 합니다 (이 경우 저장소는 Event Store). 그것은에 새 이벤트를 추가하여이를 Event stream경우에만 경우 version의가 Aggregate여전히이 때 있던 일입니다 Aggregate로드합니다. 버전이 동일하지 않으면 명령이 재 시도 됩니다. 1 단계로 이동하십시오 . 이 version동일하면 이벤트가에 추가되고 Event stream클라이언트에 Success상태 가 제공됩니다 .

이 버전 확인을 낙관적 잠금 이라고 하며 일반적인 잠금 메커니즘입니다. 다른 메커니즘 중 하나는 현재 쓰기가 완료 될 때까지 다른 쓰기가 차단 될 때 비관적 잠금 입니다.

이 용어 Event stream는 동일한 집계에서 생성 된 모든 이벤트에 대한 추상화입니다.

Event store이는 최종 상태뿐만 아니라 집계에 대한 모든 변경 사항이 저장되는 또 다른 종류의 지속성 이라는 것을 이해해야합니다 .

a)이 경우, 이벤트 로그는 더 이상 진실의 원천이 아니며 처리 방법은 무엇입니까? 또한 인출을 허용하는 것은 완전히 잘못된 반면 클라이언트로 돌아 왔습니다.이 경우 잠금을 사용하는 것이 더 낫습니까?

이벤트 저장소는 항상 진실의 원천입니다.

b) 잠금 == 교착 상태, 모범 사례에 대한 통찰력이 있습니까?

낙관적 잠금을 사용하면 잠금이없고 명령 재 시도 만 가능합니다.

어쨌든, 잠금! = 교착 상태

ES / CQRS 앱이 간단한 은행 사용 사례 (돈을 인출)에 상황에 맞는 것처럼 보이는 방법에 대한 대략적인 이해를 스케치했습니다.

닫기. 문제는 "집계"를 업데이트하기위한 논리가 이상한 장소에 있다는 것입니다.

보다 일반적인 구현은 명령 핸들러가 메모리에 유지하는 데이터 모델과 이벤트 저장소의 이벤트 스트림이 동기화 된 상태로 유지되는 것입니다.

설명하기 쉬운 예는 명령 핸들러가 이벤트 저장소에 동기 쓰기를 작성하고 이벤트 저장소에 대한 연결이 쓰기 성공을 표시하는 경우 모델의 로컬 사본을 업데이트하는 경우입니다.

명령 핸들러가 내부 모델이 상점의 모델과 일치하지 않기 때문에 이벤트 저장소와 재 동기화해야하는 경우, 상점에서 히스토리를로드하고 자체 내부 상태를 다시 빌드하여이를 수행합니다.

다시 말해, 화살표 2 & 3 (있는 경우)은 일반적으로 집계 저장소가 아닌 이벤트 저장소에 연결됩니다.

이벤트 버전에서 이벤트와 함께 집계 버전 ID를 넣습니다. 수정시 버전이 일치하지 않으면 아무 일도 일어나지 않습니다.

이벤트 스트림의 스트림에 추가 하는 것이 아니라 일반적으로 스트림 의 특정 위치에 PUT 을 적용합니다. 해당 작업이 저장소 상태와 호환되지 않으면 쓰기가 실패하고 서비스는 적절한 실패 모드 (클라이언트 실패, 재시도, 병합 ...)를 선택할 수 있습니다. dem 등원 쓰기를 사용하면 분산 메시징의 여러 문제가 해결되지만 i 등원 쓰기를 지원하는 저장소가 있어야합니다.