MassTransit의 PubSub 예제

Question

MassTransit의 pub/sub 프로젝트 샘플을 읽은 후 내 머리를 긁적니다.

예제에서 클라이언트 응용 프로그램은 구독자 응용 프로그램에 가상의 사용자의 암호를 업데이트하라는 요청을 게시합니다. 이 샘플 코드는 정상적으로 작동하며이 프로젝트의 튀는 공을 따라 가기 쉽습니다. 실제 환경에서

HOWEVER--

는 (내 이해) 출판/하위의 목적은 많은 수의 가입자와 상호 작용 출판사의 수가 적은 것입니다. 어떤 종류의 CRUD 작업을 수행하는 가입자의 경우, 통신 패턴이 둘 이상의 가입자가 메시지를 처리하지 못하게해야합니까? 20 명의 구독자가 동일한 데이터베이스 레코드를 업데이트하려고 시도하는 것이 바람직하지 않습니다.

이 문제는 잘못된 샘플 프로젝트의 경우입니까?

CRUD 작업에 pub/sub를 사용할 수 있다면 하나의 구독자 만 작업을 수행 할 수 있도록 프레임 워크를 구성하는 방법은 무엇입니까?

나는 술집/잠수함의 목적에 대한 몇 가지 기본 정보를 놓치고 있습니까? 제공되는 설명에 대한

감사합니다 ...

데이비드

Answer 1

당신이 참조 시나리오는 일반적으로 '경쟁 소비자'이라고하며, 술집/하위 상당히 대표적이다.

각 소비자의 큐 이름이 고유하면 각 소비자는 자신의 메시지 복사본을 받게됩니다.

또한, 소비자가 같은 큐 이름을 공유하는 경우, 소비자 행동을 경쟁 얻기 위해, 각 메시지 (각각의 메시지는 한 번만받을 것)

Answer 2

에 대한 소비자 간의 경쟁이있을 것이다 당신은 N을 가질 수 있습니다 여러 게시자 또는 모든 게시자/하위 시스템의 구독자에게 적용됩니다. 주어진 메시지에 얼마나 많은 액터가 응답해야하는지가 중요합니다.

샘플 프로젝트가 좋지 않을 수도 있지만 상황을 보여주는 것으로 느껴집니다. 그러나 실제 상황에서는 CRUD 유형 동작에 사용할 수 있습니다. 그러나 그것은 같은 데이터의 응답을 요청하는 미들웨어 (캐시)에 "로드 데이터"유형의 메시지를 보내는 많은 프론트 엔드의 라인을 따라 더 가깝습니다. 데이터가 어떻게 든 프론트 엔드에서 업데이트되면, 여러 미들웨어 조각이 캐시 (캐쉬, 백엔드 저장소 등)를 업데이트해야한다는 메시지를 게시해야합니다. [CQRS]

일반적으로 메시징은 연결이 끊어진 시스템에 대한 작업입니다. 귀하의 특정 세계는 소비자와 출판사의 구조에 관한 것입니다. 나는 MassTransit의 구현을 보았습니다. 대부분의 경로는 정적이고 실제로는 pub/sub가 아니었지만 시스템의 알려진 지형도를 따라 많은 보냅니다. 개념을 정말로 이해하면 내가 아는 최고의 책은 Enterprise Service Bus: Theory in Practice입니다.

도움이 되었기를 바랍니다.

편집 : 또한 documentation을 참조하십시오. 일부 개념은 거기에서 다루어집니다.