Coda messaggi. Database vs MQ dedicato

Sono in cerca di consigli riguardo l'accodamento dei messaggi. Abbiamo requisiti per "lavori" da pubblicare in una coda di messaggi.

Il suggerimento originale era solo quello di utilizzare un'istanza di SQL Server e di elaborare i messaggi da quello. Tutto ciò che ho letto su Internet suggerisce che l'uso di un database per una coda di messaggi non è una soluzione scalabile. Per questo motivo, è stata suggerita l'idea di utilizzare RabbitMQ o altri MQ di terze parti.

L'altra cosa da tenere in considerazione è che il requisito di "elaborazione del lavoro" non sarà inferiore a 30 secondi, quindi il processo che esegue il lavoro eseguirà il polling del database ogni 30 secondi. Per me, questo non sembra così male e probabilmente funzionerebbe bene senza aggiungere un grande carico al database.

Abbiamo già un database in atto sui nostri clienti che potremmo usare per questo, quindi non aggiungerà molto supporto extra richiesto ai nostri clienti, mentre se aggiungessimo un MQ di terze parti ci sarebbe un supporto extra per la configurazione della rete, ecc. notevole dato che ci sono molti utenti.

L'altra opzione che stavo prendendo in considerazione era consentire agli utenti di scegliere tra entrambi. Se sono un piccolo utente, allora la soluzione SQL Server andrà bene, ma se sono un utente più grande, consentiremo loro di configurare una soluzione MQ di terze parti.

Non sono venduto su nessuna soluzione, mi chiedo se qualcuno ha qualcosa che dovrei considerare o consigliare.

Tutto ciò che ho letto su Internet suggerisce che l'uso di un database per una coda di messaggi non è una soluzione scalabile.

La realtà spesso ignorata dalla folla " non usare X perché non ridimensiona " (il link contiene un linguaggio che alcuni potrebbero trovare discutibili) è che la scala non è sempre importante. Andrei fino al punto di dire che se guardi tutte le applicazioni sulla faccia del pianeta in aggregato, la scala è raramente importante.

Il tuo commento cita una frequenza di 20.000 messaggi al giorno, il che significa che dovresti cercare di supportare una frequenza media di 0,23 messaggi al secondo (uno ogni 4,3 secondi). Se il tuo progetto risulta avere due ordini di grandezza più riusciti del previsto, le tue esigenze passano all'elaborazione di 23 messaggi al secondo, un compito che mi farebbe molto comodo dare al mio cellulare di quattro anni o un Raspberry Pi. Questa non è ancora un'applicazione su larga scala anche se si affronta un'altra coppia di ordini di grandezza.

Ho guardato (fortunatamente, a margine) i progetti finiscono male perché o hanno trascorso troppo tempo troppo presto a ossessionare la scala che non sarebbe accaduta o non avevano tempo su di essa e sono stati schiacciati dalla scala che alla fine ha fatto. Come tutto il resto, c'è un mezzo felice. Se ritieni che il ridimensionamento di grandi dimensioni per la tua applicazione sia una possibilità realistica, non dovrebbe essere difficile creare un caso aziendale per fare la piccola quantità di lavoro extra per creare un'astrazione sufficiente attorno a parti non scalabili che sono poco costose da distribuire ora . Ciò significa che in seguito , se dovesse sorgere la necessità di una scala, si ha un modo (e possibilmente le entrate) di effettuare la sostituzione all'ingrosso di tali parti senza dover ripensare l'intero sistema.

Mentre il volume dei messaggi della tua applicazione non farà sudare un database o un sistema di accodamento dei messaggi anche su hardware modesto, probabilmente hai altri requisiti su come vengono gestite le tue transazioni di messaggi che rendono l'una o l'altra una scelta migliore. Tali requisiti sono ciò che dovresti valutare.

Le code dei messaggi diventano davvero proprie quando ne hai molte e instrada i messaggi tra di loro, si dirige verso più di un consumatore ecc.

Se hai solo una "coda di lavoro" di cose che vuoi elaborare "off line", una tabella SQL andrà bene.

Non dimenticare di assicurarti di avere un modo per contrassegnare i lavori in corso, pulire quelli vecchi e avvisare quando il sistema si ferma. Ma per una singola coda la gestione manuale di queste cose richiederà meno lavoro rispetto al mantenimento di una soluzione di accodamento separata.

Come altri hanno già detto, la scala non è probabilmente importante qui. Il problema con l'utilizzo di due diversi meccanismi di archiviazione è l'integrità transazionale.

Se si utilizza una coda di messaggi dedicata, è necessario scegliere una delle seguenti opzioni in caso di errore.

1. Consenti che i dati possano essere su mb ma non su db
2. Consenti che i dati possano essere in db ma non in mb
3. Impostare il commit in due fasi o le transazioni distribuite tra db e mq che possono essere complicate

Tutti questi problemi scompaiono se si salvano i dati in un solo posto utilizzando una normale transazione. Per questo motivo l'uso di db come coda di attività è una soluzione perfettamente valida.

Per praticità, i motivi principali per cui utilizzo una coda di messaggi sono:

• Non ho dovuto reinventare la ruota. Progettare anche la coda di messaggi più semplice utilizzando il database richiede almeno un paio d'ore di riflessione, alcune ore di programmazione e così via. Rispetto all'implementazione di una coda di messaggi, il tempo necessario per configurare e / o automatizzare la configurazione è banale
• Le code dei messaggi hanno un'interfaccia chiara e piacevole per produttore e consumatore. Questa è probabilmente la cosa più importante nella scrittura dell'applicazione. Senza l'interfaccia, le code dei messaggi sono fondamentalmente solo una raccolta di dati
• Le code dei messaggi offrono più funzionalità che potrebbero essere necessarie in futuro

Per quanto riguarda consentire agli utenti di scegliere, si tratta in realtà di un dettaglio di implementazione di cui gli utenti non dovrebbero preoccuparsi. Gli utenti dovrebbero ottenere la stessa interfaccia e non dovrebbero esserci differenze per gli utenti se si utilizza la coda di messaggi o di database. Una volta impostato un singolo progetto, una probabile scelta per gli utenti è il numero di nodi che devono essere distribuiti per soddisfare le loro esigenze.

Ho creato una soluzione di coda messaggi Mssql in grado di gestire 20k operazioni al secondo, secondo un test delle prestazioni, e abbiamo bisogno di 10 / sec il più delle volte. Penso che il fatto che tu possa effettivamente avere la priorità integrata sia una caratteristica che manca alla coda dei messaggi dedicata. E questo era un requisito fondamentale nel mio caso.