NServiceBus: le transazioni MSMQ non sono BAD?

Question

Sto imparando su NServiceBus e MSMQ. Mi è stato detto che le code transazionali in MSMQ sono BAD e il loro utilizzo è davvero negativo per le prestazioni. Qualcuno sa perché? Immagino che questo derivi dal fatto che usa DTC e tutti sanno che il DTC non è una soluzione veramente scalabile. Mi sembra che ci siano un paio di motivi per cui MSMQ con NServiceBus non è poi così male, ma non so se capisco come funziona completamente. Guardando a questo logicamente, mi viene in mente 3 posti dove NServiceBus potrebbe utilizzare le transazioni al fine di ottenere la consegna garantita:

1. Quando si invia un messaggio attraverso la rete, si potrebbe desiderare di utilizzare una transazione per garantire che il messaggio ha arrivato alla coda remota prima di scartarla.
2. Durante la lettura di un messaggio da una coda locale, è necessario assicurarsi che sia gestito correttamente prima di scartarlo.
3. Quando si pubblica un messaggio per più abbonati, è necessario assicurarsi che raggiunga TUTTI loro prima di scartarlo. (Spero davvero che NON sia quello che fa NServiceBus)

Qualcuno può dirmi come funziona NServiceBus?

Answer 1

Le transazioni Msmq non garantiscono che il destinatario abbia ricevuto il messaggio. La transazione garantisce che il messaggio sia stato ricevuto dall'infrastruttura msmq sulla tua macchina e, se il messaggio è durevole (il valore predefinito in NSB), significa che è stato salvato su disco e sopravviverà al riavvio. Il messaggio verrà quindi consegnato da msmq senza bloccare il chiamante. Questo è meglio conosciuto come "store and forward"

1. Per impostazione predefinita MSMQ garantisce solo che l'infrastruttura MSMQ locale ha ricevuto il messaggio. Nessun requisito che i server riceventi siano online. Questo può essere abilitato (vedi la risposta di Giovanni in basso)

2. Questo è uno dei principali punti vendita di NSB. La capacità di utilizzare le transazioni che abbraccia sia la coda locale che il tuo archivio dati (ossia la transazione distribuita) è fondamentale per garantire la coerenza. Cioè se qualcosa non va a buon fine non viene mantenuto nulla nel vostro archivio dati e il messaggio viene riavviato e riprovato senza che l'utente debba fare nulla.

3. Come il numero 1. L'unica garanzia è che ogni abbonato riceverà il messaggio pubblicato. Non vengono effettuate chiamate di blocco per tutto il tempo in cui si dispone di spazio libero su disco e il server di pubblicazione restituirà immediatamente la chiamata.

Spero che questo aiuti!

Answer 2

Il punto n. 2 è corretto. Non vuoi che un messaggio causi un errore e poi cali attraverso le fessure. Si desidera che il gestore messaggi abbia esito positivo, nel qual caso viene rimosso dalla coda o non riesce e viene ripristinato, in modo che possa essere ritentato o inviato a una coda di errore per l'analisi dopo che è stato raggiunto un numero configurabile di tentativi .

Answer 3

Punto 1: incompleto. I messaggi transazionali ti danno questo IF se usi Live Journalling Negative e Postive con Dead Letter Queues e Timer TTRQ/TTBR. Quindi è possibile determinare esattamente cosa è successo a un messaggio - se è stato rifiutato, se è stato consegnato, se è stato elaborato.