Dovrei usare MSMQ o SQL Service Broker per le transazioni?

Question

Il mio team leader mi ha chiesto di esaminare MSMQ come opzione per la nuova versione del nostro prodotto. Usiamo SQL Service Broker nella nostra versione attuale. Ho fatto la mia giusta parte di sperimentazione e google per trovare quale prodotto è migliore per le mie esigenze, ma ho pensato di chiedere il miglior sito che conosco per le risposte di programmazione.

Alcuni dettagli:

• Il nostro client è il codice .NET 1.1 e 2.0; questo è da dove verrà inviato il messaggio.
• La destinazione in un'istanza di SQL Server 2005. Tutti i messaggi finiscono per essere aggiornamenti o inserimenti di database.
• Invieremo diversi aggiornamenti che devono essere trattati come una transazione.
• Dobbiamo avere una perfetta recuperabilità dei messaggi; nessun messaggio può essere perso.
• Dobbiamo essere asincroni e in grado di accettare i messaggi anche quando il server SQL di destinazione è inattivo.
• Lo sviluppo della nostra soluzione di accodamento non è un'opzione; siamo una piccola squadra.

Cose che ho scoperto finora:

• Sia MSMQ che SQL Service Broker possono fare il lavoro.
• Sembra che il broker di servizi sia più veloce per i messaggi transazionali.
• Service Broker richiede un server SQL in esecuzione da qualche parte, mentre MSMQ necessita di qualsiasi macchina Windows configurata in esecuzione da qualche parte.
• MSMQ sembra essere migliore / più veloce / più facile da configurare / eseguire nei cluster.

Mi sto perdendo qualcosa? C'è un chiaro vincitore qui? Eventuali pensieri, esperienze o collegamenti sarebbero valutati. Grazie!

EDIT: abbiamo finito con il broker di servizi perché abbiamo un framework DB personalizzato utilizzato in alcuni dei nostri codici client (gestiamo meglio le transazioni). Quel codice ha catturato SQL per le transazioni, ma non. Il codice client era anche tutto versione 1.1 di .NET, quindi avremmo dovuto aggiornare tutto il codice client. Grazie per il tuo aiuto!

Answer 1

Avendo appena migrato la mia applicazione da Service Broker a MSMQ, avrei dovuto votare per l'utilizzo di MSMQ. Esistono diversi fattori da tenere in considerazione, ma la maggior parte dei quali ha a che fare con il modo in cui stai utilizzando i tuoi dati e dove vive l'elaborazione.

• Se l'elaborazione viene eseguita nel database? Service Broker
• Se si tratta solo di spostare i dati? Service Broker
• L'elaborazione viene eseguita nel codice .NET / COM? MSMQ
• Sono necessarie transazioni distribuite remote (ad esempio, l'elaborazione su una casella diversa da SQL)? MSMQ
• Devi essere in grado di inviare messaggi mentre la destinazione è inattiva? MSMQ
• Vuoi usare nServiceBus, MassTransit, Rhino-ESB, ecc.? MSMQ

Aspetti da considerare indipendentemente da ciò che si sceglie

• Come conosci la salute della tua coda? Entrambe le opzioni gestiscono il failover in modo diverso. Ad esempio, Service Broker disabiliterà la tua coda in determinati scenari che possono rimuovere l'applicazione.
• Come eseguirai i rapporti? Se usi già le tabelle SQL nei tuoi rapporti, Service Broker può facilmente adattarsi perché è solo un'altra tabella dinamica. Se stai già utilizzando Performance Monitor MSMQ potrebbe andare meglio. Service Broker ha molti contatori delle prestazioni, quindi non lasciare che questo sia il tuo unico fattore.
• Come si misura il tempo di attività? Si sta semplicemente assicurando di non perdere transazioni o è necessario rispondere in modo sincrono? Trovo che la natura distribuita di MSMQ consenta di aumentare i tempi di attività perché la coda principale può andare offline e non perdere nulla. Considerando che con Service Broker il database deve essere online o altrimenti si perde.
• Hai già esperienza con una di queste tecnologie? Entrambi hanno molti dettagli di implementazione che possono tornare e morderti.
• Non importa quale scelta fai, quanto è facile cambiare la tecnologia di Accodamento sottostante? Consiglio di avere un'interfaccia IQueue generica su cui scrivere un'implementazione concreta. In questo modo la scelta che fai può essere facilmente modificata in seguito se scopri di aver fatto quella sbagliata. Dopotutto, una coda è solo una coda e non dovrebbe bloccarti in un'implementazione specifica.

Answer 2

Ho usato MSMQ in precedenza e l'unico elemento che aggiungerei al tuo elenco è un controllo dei prerequisiti per il controllo delle versioni. Ho riscontrato un problema in cui un sito aveva Win 2000 Server e quindi MSMQ v.2, rispetto a Win 2003 Server e MSMQ v3. Tutto il mio codice .NET ha come target v.3 e non sono compatibili ... o almeno non facilmente.

Solo una considerazione se segui la rotta MSMQ.

Answer 3

La limitazione della dimensione del messaggio in MSMQ ha interrotto la mia ricerca in quella direzione. Sto imparando Service Broker per il progetto.

Answer 4

  

Devi essere in grado di inviare messaggi mentre la destinazione è inattiva? MSMQ

Non capisco perché? SSB può inviare messaggi a destinazione disconnessa senza alcun problema. Tutti questi messaggi vanno alla coda di trasmissione e verrebbero recapitati quando la destinazione rimane raggiungibile.