Esempio PubSub in MassTransit

Question

Dopo aver letto l'esempio del progetto pub/sub in MassTransit, mi ha lasciato la testa grattata.

Nell'esempio, l'applicazione client pubblica una richiesta per l'applicazione di sottoscrizione per aggiornare la password di un utente fittizio. Questo codice di esempio funziona bene ed è facile seguire la palla rimbalzante di questo progetto.

HOWEVER--

In un ambiente reale, al fine di pub/sub (nella mia comprensione) è quella di avere un piccolo numero di editori che interagiscono con un gran numero di abbonati. Nel caso in cui un sottoscrittore esegua qualsiasi tipo di operazione CRUD, il modello di comunicazione non dovrebbe impedire a più utenti di gestire il messaggio? Ad esempio, non sarebbe auspicabile che venti abbonati tentino di aggiornare lo stesso record del database.

Si tratta solo di un progetto di esempio errato?

Se pub/sub può essere utilizzato per le operazioni CRUD, come si configura il framework per consentire solo a un abbonato di eseguire un'operazione?

Mi mancano alcune informazioni di base sullo scopo di pub/sub?

Grazie per qualsiasi chiarimento fornito ...

David

Answer 1

Lo scenario si fa riferimento è di solito indicato come consumatori concorrenti ', ed è abbastanza tipico dei pub/sub.

Se ciascun utente ha il proprio nome di coda univoco, ciascun utente riceverà la propria copia dei messaggi.

In alternativa, per ottenere in competizione il comportamento dei consumatori, se i consumatori condividono il nome di coda stesso, ci sarà concorrenza tra i consumatori per ogni messaggio (in modo che ogni messaggio sarà ricevuto solo una volta)

Answer 2

Si può avere n -a-n, molti-a-pochi, o pochi-a-molti editori per gli abbonati in qualsiasi pub/sottosistema. È davvero una questione di quanti attori vuoi che rispondano a un determinato messaggio.

Il progetto di esempio potrebbe non essere il migliore, ma riteniamo che mostri cosa sta succedendo. Tuttavia, nei casi reali, può essere utilizzato per comportamenti di tipo CRUD; tuttavia è più lungo la linea di molti front-end che inviano messaggi di tipo "load data" al middleware (cache) che richiede una risposta degli stessi dati. Se i dati vengono aggiornati sul front-end in qualche modo, devono pubblicare alcuni messaggi che indicano che e più parti del middleware devono essere aggiornate (cache, backend store, ecc.). [vedi CQRS]

La messaggistica in generale riguarda più il funzionamento con i sistemi disconnessi. Il tuo mondo specifico riguarda più la struttura dei consumatori e degli editori. Ho visto implementazioni di MassTransit in cui la maggior parte delle rotte erano statiche e non erano affatto pub/sub, ma solo un sacco di matrici lungo una topografia nota di sistemi. Comprendendo veramente i concetti, il miglior libro che conosca è Enterprise Service Bus: Theory in Practice.

Spero che questo aiuti!

Modifica: vedi anche il nostro documentation, alcuni dei concetti vengono toccati lì.