Code contro tabelle nei sistemi di messaggistica [chiuso]

Question

Ho sperimentato i lati positivi e negativi dei sistemi di messaggistica in ambienti di produzione reali e devo ammettere che una tabella o uno schema di tabelle ben organizzati batte semplicemente ogni volta che qualsiasi altra forma di coda di messaggistica, perché:

1. I dati vengono archiviati in modo permanente su una tabella. Ho visto così tante applicazioni java (jms) che perdono o svaniscono i messaggi sulla loro strada per eccezioni non rilevate o altri bug.
2. Le code tendono a riempirsi. Lo spazio di archiviazione Db è invece praticamente infinito.
3. Le tabelle sono facilmente accessibili, mentre devi usare strumenti esotici per leggere da una coda.

Qual è la tua opinione su ciascun approccio?

Answer 1

La frase batte ogni volta dipende totalmente dalle esigenze iniziali. Certamente non batterà ogni volta per tutti.

Se stai costruendo un singolo sistema che sta già utilizzando un database, non hai requisiti di throughput di prestazioni molto elevate e non devi comunicare con altri team o sistemi, probabilmente hai ragione.

Per roba semplice, a basso input, principalmente a thread singolo, il database è un'alternativa totalmente valida alle code dei messaggi.

Il punto in cui brilla una coda di messaggi è quando

• vuoi un bilanciamento del carico altamente performante, altamente concorrente e scalabile in modo da poter elaborare decine di migliaia di messaggi al secondo contemporaneamente su molti server / processi (usando una tabella di database saresti fortunato ad elaborare alcune centinaia al secondo e l'elaborazione con più thread è piuttosto difficile poiché un processo tenderà a bloccare la tabella delle code dei messaggi)
• è necessario comunicare tra sistemi diversi utilizzando database diversi (quindi non è necessario distribuire l'accesso in scrittura al database dei sistemi ad altre persone in diversi team, ecc.)

Per sistemi semplici con un unico database, team e requisiti di prestazione abbastanza modesti, utilizzare sicuramente un database. Usa lo strumento giusto per il lavoro ecc.

Tuttavia, dove le code dei messaggi brillano è nelle grandi organizzazioni in cui ci sono molti sistemi che devono comunicare tra loro (e quindi non si desidera che un database aziendale sia un punto centrale di errore o luogo dell'inferno della versione) o quando si hanno requisiti di prestazione elevati.

In termini di prestazioni, una coda di messaggi batterà sempre una tabella di database - poiché le code di messaggi sono progettate specificatamente per il lavoro e non si basano su blocchi pessimistici della tabella (necessari per l'implementazione del database di una coda) per eseguire bilanciamento del carico) e buone code di messaggi eseguiranno un caricamento entusiasta dei messaggi nelle code per evitare il sovraccarico della rete di un database .

Allo stesso modo - non useresti mai un database per eseguire il bilanciamento del carico delle richieste HTTP tra i tuoi server Web - dato che sarebbe troppo lento - se avessi requisiti di prestazioni elevate per il tuo bilanciamento del carico, non utilizzeresti nemmeno un database .

Answer 2

Prima ho usato le tabelle, poi ho fatto il refactoring in una vera e propria coda di msg quando (e se) c'è ragione - il che è banale se il tuo design è ragionevole.

I maggiori vantaggi sono a.) è più semplice (b. è una pista di controllo migliore perché hai le altre tabelle a cui unirti, c.) se conosci gli strumenti del database davvero bene, sono più facili da usare rispetto al Strumenti di Accodamento messaggi, d.) In genere è un po 'più semplice impostare un ambiente test / dev in un contesto già esistente per la tua app (se si applica la stessa familiarità).

Oh, ed e.) forse per te e gli altri, non è un altro prodotto da imparare, installare, configurare, amministrare e supportare.

IMPE, è altrettanto affidabile, disconnettibile e puoi convertirlo se ha bisogno di più scalabile.

Answer 3

1. I dati sono memorizzati in modo permanente su una tabella. Ho visto così tante applicazioni java (jms) che perdono o svaniscono i messaggi sulla loro strada per eccezioni non rilevate o altri bug.

   Quale implementazione JMS? Sun vende una coda affidabile che non può perdere messaggi. Forse hai appena acquistato un prodotto scadente conforme a JMS. IBM MQ è estremamente affidabile e ci sono librerie JMS per accedervi.

2. Le code tendono a riempirsi. Lo spazio di archiviazione Db è invece praticamente infinito.

   Ummm ... Se la coda si riempie, sembra che qualcosa sia rotto. Se le tue app si bloccano, non è una buona cosa e le code hanno poco a che fare con questo. Se hai acquistato un'implementazione JMS davvero scadente, posso vedere dove potresti non essere soddisfatto. È un mercato competitivo. Trova un gestore code migliore. JCAPS di Sun ha un ottimo gestore code, in precedenza la coda dei messaggi SeeBeyond.

3. Le tabelle sono facilmente accessibili, mentre devi usare strumenti esotici per leggere da una coda.

   Non si adatta alla mia esperienza. Le tabelle sono accessibili tramite questa peculiare "altra lingua" (SQL) e richiede di essere a conoscenza dei mapping della struttura dalle tabelle agli oggetti e dei mapping dei tipi di dati da VARCHAR2 a String. Inoltre, devo usare una sorta di livello di accesso (JDBC o un ORM che utilizza JDBC). Sembra molto, molto complesso. È possibile accedere a una coda tramite MessageConsumers e MessageProducers utilizzando semplici invii e ricevute.

Answer 4

Sembra che i problemi che hai riscontrato non siano inerenti alla messaggistica, ma piuttosto sono artefatti di sistemi di messaggistica mal implementati. Costruire sistemi di messaggistica è più difficile che costruire sistemi di database? Sì, se tutto ciò che fai è creare sistemi di database.

• Perdere messaggi per eccezioni non rilevate? Non è certo colpa della coda dei messaggi. Le applicazioni che stai utilizzando sono progettate male. Stanno rimuovendo i messaggi dalla coda prima del completamento dell'elaborazione. Non stanno utilizzando transazioni o journaling.
• Le code dei messaggi si riempiono mentre lo spazio di archiviazione del DB è "virtualmente infinito"? Parli come se la gestione dello spazio su disco fosse qualcosa che i database non richiedevano. I server delle code dei messaggi richiedono amministrazione, proprio come i server di database.
• Strumenti esoterici da leggere da una coda? Forse se trovi metodi asincroni esoterici. Forse se trovi la serializzazione e la deserializzazione esoteriche. (Almeno, queste sono le cose che ho trovato esoterico quando stavo imparando la messaggistica. Come molte tecnologie apparentemente esoteriche, in realtà sono piuttosto banali una volta che le capisci e comprenderle è una parte importante dell'educazione degli sviluppatori esperti.)

Aspetti della messaggistica che lo rendono superiore ai database:

• Elaborazione asincrona. Le code dei messaggi avvisano i processi di attesa all'arrivo di nuovi messaggi. Per realizzare questa funzionalità in un database, i processi in attesa devono eseguire il polling del database.
• Separazione delle preoccupazioni. Il canale di comunicazione è disaccoppiato dai dettagli di implementazione del contenuto del messaggio. Solo il mittente e il destinatario devono sapere qualcosa sul formato del flusso di dati all'interno di un determinato messaggio.
• Fault-tolleranza. . La messaggistica può funzionare quando le connessioni tra i server sono intermittenti. Le code dei messaggi possono archiviare i messaggi localmente e inoltrarli ai server remoti solo quando la connessione è attiva.
• Integrazione di sistemi. Nel mondo Windows, almeno, la messaggistica è integrata nel sistema operativo. Utilizza il modello di sicurezza del sistema operativo, è gestito tramite gli strumenti del sistema operativo, ecc.

Se non hai bisogno di queste cose, probabilmente non hai bisogno di messaggistica.

Ecco un semplice esempio di un'applicazione per la messaggistica: sto costruendo un sistema in questo momento in cui gli utenti, distribuiti su più reti, stanno inserendo serie abbastanza complesse di transazioni utilizzate per produrre output stampati. La generazione di output è computazionalmente costosa e non fa parte del loro flusso di lavoro; cioè agli utenti non importa quando viene generato l'output, solo che lo fa.

Quindi serializziamo le transazioni in un messaggio e lo rilasciamo in una coda. Un processo in esecuzione su un server prende i messaggi dalla coda, produce l'output e archivia l'output in un sistema di imaging.

Se utilizzassimo un database come archivio di messaggi, dovremmo elaborare uno schema per memorizzare un formato di transazione che al momento interessa solo il mittente e il destinatario, dovremmo assicurarci che tutte le workstation sul la rete aveva connessioni permanenti permanenti al server di database, non avremmo la capacità di distribuire questo carico di transazione su più server e il nostro server di output dovrebbe interrogare il database migliaia di volte al giorno in attesa di vedere se c'erano nuovi lavori da elaborare .

Answer 5

Le code forniscono messaggi affidabili. La natura disconnessa e disconnessa del servizio di accodamento lo rende molto più scalabile rispetto ai database, per non dire più robusto.

E le code non dovrebbero davvero essere usate per l'archiviazione permanente delle informazioni - è meglio pensarle come caselle di posta temporanee, a differenza dei database.