BLOB 데이터를 저장하는 이벤트 소스 응용 프로그램에서 2 단계 커밋을 피하십시오

Question

UserPortraitImage 및 Contract이 PDF 파일 인 누적 값이 User이라고 가정합시다. 전용 문서 기반 저장소에 파일을 저장하고 이벤트에서 프로세스 관련 데이터를 보유하기를 원합니다 (BLOB 데이터에 대한 링크 포함).

그러나 파일을 저장하고 새 이벤트를 저장할 때 2 단계 커밋을 방지하려면 어떻게해야합니까?

처음에는 문서를 저장 한 다음 이벤트를 저장합니다. 첫 번째 트랜잭션이 실패해도 문제가되지 않으면 명령이 실패합니다. 두 번째 트랜잭션이 실패하면 상점에 불량 파일이 생성 되더라도 상관 없습니다. 명령은 실패합니다. 롤백을 적용 할 수도 있습니다. 하지만 추가 문제가있을 수 있습니까?

다음 질문은 집계 및 이벤트를 디자인하는 방법입니다. 집계가 BLOB 저장소에 대한 참조 만 보유하고있는 경우 SignUp 명령이 호출 된 후 프로세스는 무엇입니까?

SignUpCommand ==> 문서를 저장 (UserPortraitImage 및 Contract) ==> 지정된 BLOB 저장 참조 새로운 User 집계를 작성하고 보관?

BLOB 데이터가 다른 상점에 저장되었다는 것을 모으는 집계를 해치지 않는 더 나은 디자인이 있습니까? 누가 BLOB 데이터를 저장하고 집계에 대한 참조를 전달할 책임이 있습니까?

Answer 1

AtomPub media-entry/media-link-entry과 비슷한 것으로 들리는 것 같습니다. BLOB이 데이터 저장소로 들어가고 메타 데이터가 집계 기록에 복사됩니다.

그러나 파일을 저장하고 새 이벤트를 저장할 때 2 단계 커밋을 방지하려면 어떻게해야합니까?

실제로는 그렇지 않을 수도 있습니다.

즉, BLOB 저장소와 집계 저장소가 동일한 데이터베이스 일 경우 동일한 트랜잭션에서 둘 다 업데이트 할 수 있습니다. 그건 두 가게를 연결하고 저장소의 선택에 꽤 강한 제약을 추가하지만, 그것은 가능합니다.

또 다른 가능성은 사용자가 변경 한 두 가지가 서로 분리되어 있으며 일정 기간 동안 두 저장소가 서로 일치하지 않는다는 사실을 받아 들일 수 있다는 것입니다.

이 두 번째 경우는 the saga pattern이며 찾고자하는 것입니다. 두 번째 작업이 실패 할 경우 수행 할 보상 작업과 첫 번째 작업을 쌍으로 만듭니다. 그래서 "수동"롤백.

아니, 말하자면 - git 객체 데이터베이스는 2 단계 커밋을 사용합니다. 개체가 개체 저장소로 복사 된 다음 트리가 업데이트되고 나면 필요없는 개체를 폐기하기 위해 커밋 ... 가비지 수집이 나옵니다.

누가 BLOB 데이터를 저장하고 집계에 대한 참조를 전달합니까?

궁극적으로 인프라 문제입니다. 귀하의 모델이 실제로 문서와 상호 작용해야합니까, 아니면 나중에 교환 할 수있는 claim check을 가지고있을뿐입니다?

Answer 2

처음에는 문서를 저장 한 다음 이벤트를 저장합니다. 첫 번째 트랜잭션이 실패해도 문제가되지 않으면 명령이 실패합니다. 두 번째 트랜잭션이 실패하면 상점에 데드 파일을 생성하더라도 문제가되지 않습니다. 심지어 롤백을 적용 할 수도 있습니다. 그러나 추가 문제가있을 수 있습니까?

불필요한 디스크 공간을 제외하고 생각할 수 있습니다. 분산 트랜잭션을 피하려는 경우 나 두 가지 유형의 데이터 저장소에서 사용할 수없는 경우 일반적으로 그렇게합니다. 흔히 두 작업 중 하나가 덜 중요하므로 나중에 마스터 작업이 실패하더라도 작업을 완료 할 수 있습니다.

예외 처리, 대역 외 프로세스 또는 @VoiceOfUnreason이 설명한 사가 (Saga)의 일부로 잘못된 시도를 정리할 수 있습니다.

SignUpCommand ==> 문서를 저장 (UserPortraitImage 및 계약) ==> 새로운 사용자 지정된 BLOB 저장 참조가 집계 및 가게를 만드시겠습니까?

예. 일반적으로 응용 프로그램 계층 구성 요소 (귀하의 경우 명령 처리기)는 서로 다른 데이터 저장소 사이의 조정자 역할을하며 다른 저장소 나 도메인과 통신하기 전에 한 저장소에서 알아야 할 모든 것을 되돌립니다.