Come implementare la soluzione di Accodamento messaggi

Question

Ho uno scenario in cui circa 10 messaggi diversi dovranno essere accodati e quindi rimossi dalla coda/elaborati. Un abbonato avrà bisogno di tutti e 10 i messaggi, ma un altro avrà solo bisogno di 8 dei 10 messaggi. Sto cercando di capire quale sia il modo migliore per configurare questo tipo di architettura. Crei una coda per ogni tipo di messaggio in modo che gli abbonati possano semplicemente iscriversi alle code pertinenti o li scarichi tutti nella stessa coda e ignorare i messaggi che non sono rilevanti per quell'iscritto? Voglio assicurare la soluzione è flessibile/scalabile, ecc

processo:

1. 10 diversi messaggi XML saranno accodati ad un server IBM WebSphere MQ.
2. Utilizzeremo .Net (Probabilmente WCF da quando WebSphere MQ 7.1 è stato aggiunto nel supporto WCF)
3. Elimineremo i messaggi e li caricheremo in un altro DB di back-end (molto probabilmente SQL Server).
4. La soluzione deve scalare bene perché elaboreremo un numero molto elevato di messaggi e questo potrebbe aumentare (probabilmente 40-50.000/ora). Almeno una grande quantità per noi.

Come sempre apprezzare molto le informazioni.

-S

Answer 1

OK, in base ai commenti, ecco un suggerimento che si ridimensionerà e non richiede molti cambiamenti sulle app.

Per quanto riguarda il produttore, copiare i criteri di selezione dei messaggi in una proprietà del messaggio e quindi pubblicare il messaggio in un argomento. L'unica modifica richiesta qui all'app è la proprietà message. Se per qualche motivo non vuoi renderlo pubblico utilizzando la funzionalità nativa, puoi definire un alias su un argomento. L'app pensa che stia inviando messaggi ma in realtà sono pubblicazioni.

Per quanto riguarda il consumatore, ci sono un paio di scelte. Uno è quello di creare abbonamenti amministrativi per ogni app e utilizzare un selettore nella sottoscrizione. I messaggi vengono quindi canalizzati in una coda dedicata per utente, in base ai criteri di selezione. Le app pensano che stiano semplicemente consumando messaggi.

In alternativa l'app può semplicemente iscriversi all'argomento. Questo ti dà la possibilità di una sottoscrizione dinamica che non riceve messaggi quando l'app è disconnessa (se in realtà lo volevi) o una sottoscrizione duratura che è funzionalmente equivalente all'abbonamento amministrativo.

Questa soluzione è facilmente scalabile in base ai volumi citati. Un'altra opzione è che il produttore non usa le proprietà.Qui, l'applicazione consumer consuma tutti i messaggi, interrompe il carico utile del messaggio su ciascuno e decide se elaborare o ignorare il messaggio. In questa soluzione il produttore pubblica ancora su un argomento. Qualsiasi soluzione implicante la messa in coda diretta costringe il produttore a conoscere tutte le destinazioni. Aggiungi un altro consumatore, cambia il produttore. Inoltre, c'è un PUT per ogni destinazione.

Il caso peggiore è un produttore che mette più messaggi e un consumatore che deve leggere ognuno per decidere se verrà ignorato. Questa opzione potrebbe avere problemi di ridimensionamento, a seconda di quanto sia profondo il carico utile nel campo dei criteri di selezione. Espressione XPath veramente lunga = prestazioni scadenti e nessun modo per regolare WMQ per compensare poiché la latenza è tutta nell'applicazione in quel punto.

Nel caso migliore, il produttore imposta una proprietà messaggio e pubblica. I consumatori selezionano sulla proprietà nel loro abbonamento o un abbonamento amministrativo fa questo per loro. Se questa soluzione utilizza sottoscrizioni o abbonamenti amministrativi non fa alcuna differenza per quanto riguarda la scalabilità.

Answer 2

Creazione di code è relativamente 'a buon mercato' dal punto di vista delle risorse, più sì, è meglio usare una coda per ogni scopo specifico, quindi è probabilmente meglio in questo caso la loro separazione client di destinazione se possibile. Utilizzare una coda per estrarre i messaggi in modo selettivo in base a determinati criteri (ID di correlazione o qualche altra cosa) è in genere una cattiva idea. Lo scenario più performante nella messaggistica è il più semplice: basta trascinare i messaggi dalla coda non appena arrivano, piuttosto che sbirciare e ricevere selettivamente.

Per quanto riguarda il ridimensionamento, non posso parlare per Websphere MQ o altri prodotti IBM, ma 40-50K messaggi all'ora non sono particolarmente difficili da gestire per MSMQ su Windows Server, quindi presumo che IBM possa farlo anche. Solitamente il collo di bottiglia non è la stessa piattaforma di accodamento, ma piuttosto il processo di eliminazione e elaborazione dei singoli messaggi.