나는 최근 에 이벤트 소싱 에 대해 읽고 있었고 그 뒤에있는 아이디어를 정말로 좋아하지만 다음과 같은 문제가 있습니다.
명령 (예 : 웹 서버)을 수신하고 결과적으로 이벤트를 생성하여 중앙 저장소에 저장하는 N 개의 동시 프로세스가 있다고 가정하십시오. 또한 상점에서 이벤트를 순차적으로 적용하여 모든 임시 애플리케이션 상태가 개별 프로세스의 메모리에 유지된다고 가정하십시오.
이제 다음과 같은 비즈니스 규칙이 있다고 가정하겠습니다. 각 개별 사용자마다 고유 한 사용자 이름이 있어야합니다.
두 프로세스가 동일한 사용자 이름 X에 대한 사용자 등록 명령을 수신하면 둘 다 X가 사용자 이름 목록에 없는지 확인하고 규칙은 두 프로세스 모두에 대해 유효성을 검증하고 둘 다 "사용자 이름 X를 가진 새 사용자"이벤트를 상점에 저장합니다. .
비즈니스 규칙을 위반하여 (일명 사용자 이름이 동일한 두 명의 개별 사용자가 있음) 이제 일관성이없는 글로벌 상태가되었습니다.
기존의 N 서버 <-> 1 RDBMS 스타일 시스템에서 데이터베이스는 이러한 불일치를 방지하는 데 도움이되는 중앙 동기화 지점으로 사용됩니다.
제 질문은 이벤트 소스 시스템이 일반적으로이 문제에 어떻게 접근합니까? 그들은 단순히 모든 명령을 순차적으로 처리합니까 (예 : 상점에 쓸 수있는 프로세스의 양을 1로 제한)?
1
이러한 제한은 코드로 제어됩니까, 아니면 DB 제약입니까? N 이벤트는 순서대로 디스패치 처리되거나 처리되지 않을 수 있습니다 ... N 이벤트는 서로를 구분하지 않고 동시에 유효성 검증을 거칠 수 있습니다. 주문이 중요한 경우 유효성 검사를 동기화해야합니다. 또는 대기열을 사용하여 이벤트를 대기열에
—
넣는
@ 레이브 맞아. 간단하게하기 위해 데이터베이스가없고 모든 상태가 메모리에 있다고 가정했습니다. 대기열을 통해 특정 유형의 명령을 순차적으로 처리하는 것이 옵션 일 수 있지만 어떤 명령이 다른 명령에 영향을 줄 수 있는지 결정하는 것이 복잡 할 수 있다고 생각합니다. 단일 프로세스 처리 명령을 갖는 것과 동일한 대기열에 모든 명령을 넣을 수 있습니다. : / 예를 들어 블로그 게시물에 댓글을 추가하는 사용자가있는 경우 "사용자 삭제", "사용자 일시 중지", "블로그 게시물 삭제", "블로그 게시물 댓글 비활성화"등이 모두 같은 대기열에 있어야합니다.
—
Olivier Lalonde
대기열이나 세마포어로 작업하는 것은 간단하지 않습니다. 동시성 또는 이벤트 소스 패턴으로 작업하지 마십시오. 그러나 기본적으로 모든 솔루션은 시스템의 이벤트 트래픽을 조정합니다. 그러나 그것은 흥미로운 패러다임입니다. Redis와 같은 튜플을 지향하는 외부 캐시도 있습니다.이 캐시는 엔터티의 마지막 상태 캐시 또는 해당 엔터티가 현재 처리되는 경우와 같이 노드 간에이 트래픽을 관리하는 데 도움이 될 수 있습니다. 공유 캐시는 이러한 종류의 개발에서 매우 일반적입니다. 복잡해 보이지만 포기하지는 않습니다 ;-) 매우 흥미 롭습니다
—
Laiv