저는 시스템을 재 구축하려는 경우 매우 유용 할 수있는 이벤트 소싱 패턴에 대해 읽었습니다. 그러나 새로운 수신 요청을 처리하는 동안 이벤트 재 작성을 실행해야하는 경우에는 어떻게해야합니까? 해당 시나리오에 대한 특정 패턴이나 모범 사례가 있습니까? 그래서 시스템 가동 중지 시간을 예약하는 대신 시스템에서 이벤트 동기화 및 시퀀스가 중요하기 때문에 새로운 수신 요청이 재생되는 동안 시스템을 망칠 염려가 없도록하려면 어떻게해야합니까? 이벤트 순서에 의존하는 DB 레코드를 업데이트하는 작업이 포함됩니다. 이견있는 사람?이벤트 소싱 - 이벤트 재생
설명 된 제약 조건으로 라이브 0에서 다시 빌드하는 것이 계획의 일부가 될 수 없습니다. 대신 A/B 설정을 할 수 있으며, 그 시점에서 오프라인 상태 인 새 시스템의 이벤트를 통해 재생 한 다음 새로운 시스템으로 전환하면 전환 할 수 있습니다. 핵심은 이전 시스템과 새 시스템이 동시에 이벤트 스트림을 튜닝 할 수 있다는 것입니다.
이벤트의 하위 집합에 가입 한 시스템이 여러 개인 경우 해당 하위 시스템 중 하나에 대한 이벤트 만 재생하면 해당 하위 시스템이 작동하지 않아도 동기화/시퀀스 요구 사항을 충족 할 수 있습니다.
이벤트 순서 번호를 데이터에 포함시키고 이벤트를 아직 보지 못한 경우 시퀀스 종속 서비스 지연 처리를 사용하면 더 이상 사용되지 않는 정보에 대한 조치를 방지 할 수 있습니다.
감사합니다. 새로운 시스템이 모든 추격을 완료했는지 확인하기 위해 작은 가동 중지 시간을 예약하고 오래된 시스템을 끄고 더 이상 새로운 데이터가 이전 시스템으로 흘러 들지 않도록해야합니다. 그런 다음 새 시스템이 완료되면 확인한 후 새 시스템을 켜야합니다. 데이터의 정확성을 보장하기 위해 서비스 중단 시간을 계획해야합니다. 내가 틀렸다면 나를 바로 잡습니다. – Nyamnyam
나는 당신이 오해하고 있다고 생각합니다. 이벤트 로그는 이벤트 소싱에서의 진실의 원천이며 다른 모든 시스템은 이벤트 소비자입니다.중단 시간은 필요하지 않습니다. 그러한 전환 과정에서 이벤트가 항상 처리되는 방식에 만족하는지 확인해야합니다. – rep
이벤트를 읽기 모델에 투영하려면 EventStore에서 제공하는 것과 같은 일종의 캐치 업 구독을 사용해야합니다. 이 경우 새 이벤트가 상점에 저장되지만 즉시 투사되지는 않습니다.
그러나 사용자는 일관성없는 읽기 모델을 기반으로 부실 데이터를 많이보고 조치를 취해야한다는 것을 인식해야합니다. 차라리이 문제를 피하고 시스템을 재구성하게하십시오.
예전 버전을 업데이트하고 특정 시점에 전환하는 것과 동시에 새 읽기 모델을 작성하려는 첫 번째 대답에 동의합니다. 모든 사용자가 처음에는 그렇지 않을 수도 있습니다.
가능하면 이벤트 재생을 위해 타사 라이브러리를 사용하지 않는 것이 좋습니다. – Nyamnyam
EventStore는 라이브러리가 아닙니다. http://www.geteventstore.com –
비슷한 경우 CQRS + ES를 사용했습니다. 준비된 데이터로 프로젝션을 만들었습니다. 업데이트 만 할 수는 있지만 다시 만들 수는 없습니다. 그리고 모든 쿼리에서이 결과 정보를 신속하게 작성했습니다.
DB에서의 업데이트와 같이 일부 긴 작업을 실행해야하는 경우 sagas를 사용하십시오. saga가 끝나고 event2가 생성 된 후에 event -> saga -> projection을 업데이트하십시오.
물론 이벤트 수입과 예상 업데이트 사이에는 약간의 지연이 있습니다.
시스템에 대해 자세히 알아보고 그러한 변형이 사용자에게 충분하면 매우 흥미 롭습니다.
그것은 내 비슷한 질문입니다. http://stackoverflow.com/questions/38197712/event-sourcing-avoid-projects-duplicated-events-while-replaying-events-and-list – martinezdelariva