Ho cercato e utilizzato per inviare messaggi tra 2 sistemi.
Ma perché? Perché non dovresti usare solo un Database?
Ci deve essere qualche caratteristica ActiveMQche Databasesnon ha?
Risposte:
Viene utilizzato per comunicare in modo affidabile tra due processi distribuiti.
Sì, potresti memorizzare i messaggi in un database per comunicare tra due processi, ma, non appena il messaggio viene ricevuto, dovresti farlo DELETEsul messaggio, Ciò significa una riga INSERTe DELETEper ogni messaggio.
Quando si tenta di ridimensionarlo comunicando migliaia di messaggi al secondo, i database tendono a cadere .
ActiveMQD'altro canto, il middleware orientato ai messaggi [MOM] è costruito per gestire questi casi d'uso.
Presumono che i messaggi in un sistema integro verranno eliminati molto rapidamente e possono eseguire ottimizzazioni per evitare il sovraccarico .
Può anche inviare messaggi ai consumatori invece di un consumatore che deve eseguire il polling per il nuovo messaggio eseguendo una query SQL.
Ciò riduce ulteriormente la latenza coinvolta nell'elaborazione dei nuovi messaggi inviati nel sistema.
ActiveMQo in generale tutte le implementazioni MOM (Message Oriented Middleware) sono progettate allo scopo di inviare messaggi tra due applicazioni o due componenti all'interno di un'applicazione.
In sostanza, MOM e database condividono una base comune in quanto forniscono l'archiviazione dei dati transazionale e persistente da cui leggere e scrivere.
La grande differenza è il modello di utilizzo: dove i database sono molto generici e ottimizzati per ricerche complesse su più tabelle, MOM è ottimizzato per leggere i messaggi, uno alla volta, in un modo FIFO come [Queue].
JMS, che è un'API implementata da ActiveMQ, è una pietra angolare importante nelle applicazioni Java Enterprise. In questo modo i messaggi condividono un formato e una semantica piuttosto comuni, il che rende più facile l'integrazione tra diverse applicazioni.
Naturalmente, ci sono un sacco di funzioni più dettagliati che sono solo in ActiveMQ, protocolli di filo come OpenWire, STOMPe MQTT, JMS, EIPinsieme ad Apache Camel, modelli di messaggio come "richiesta / risposta" e "publish / subscribe", JMS Bridging, di clustering (" network of brokers "), che consentono il ridimensionamento e le distribuzioni, ecc.
Dovresti documentarti un po 'su questi argomenti se sei interessato poiché sono piuttosto grandi.
ActiveMQha un ottimo supporto per lo scheduler , il che significa che puoi programmare l'invio del tuo messaggio da consegnare in un determinato momento .
Abbiamo utilizzato questa funzione per inviare promemoria sui farmaci ai pazienti che caricano i dettagli dei loro farmaci in uno scenario di assistenza sanitaria.
Scheduled Jobsper gli stessi scopi.
Con RDBMS, quando si elabora una riga di dati, in genere si aggiorna un flag che indica che la riga è stata elaborata in modo che l'elaborazione non venga ripetuta.
Tuttavia, con Message Queue, devi solo riconoscere un messaggio e il consumatore successivo elaborerà quello successivo.
La differenza è che l' UPDATEaffermazione in un RDBMS è un'operazione molto lenta rispetto acknowledgeall'attivmeq.
vorrei sottolineare quanto segue:
Disaccoppiato : i sistemi sono in grado di comunicare senza essere collegati. La coda si trova tra i sistemi, un errore di sistema non influirà mai su un altro poiché la comunicazione avviene tramite Queue. I sistemi continuano a funzionare quando sono attivi.
Supporto per il recupero : i messaggi in Queues persistevano. I messaggi possono essere ripristinati in seguito se la coda non riesce.
Comunicazione affidabile : considera un sistema che elabora le richieste dei client. In casi normali il sistema riceve 100 richieste al minuto. Questo sistema non è affidabile quando il numero di richieste supera la media. In tal caso Queue può gestire le richieste e può inviare messaggi periodicamente in base alla velocità effettiva del sistema senza interromperla.
Asincrono : la comunicazione del server client non è bloccante. Una volta che il client ha inviato la richiesta al server, può eseguire altre operazioni senza attendere la risposta. Quando la risposta ricevuta, il cliente può gestirla in qualsiasi momento.
Da Wikipedia
Apache ActiveMQ è un broker di messaggi open source scritto in Java insieme a un client JMS (Java Message Service) completo. Fornisce "Funzionalità Enterprise" che in questo caso significa favorire la comunicazione da più di un client o server
Per quanto riguarda le tue domande:
Perché non dovresti usare un database?
È necessario utilizzare il database per i dati persistenti e non per i dati temporanei. Supponi di dover inviare un messaggio dal mittente al destinatario. Alla ricezione del messaggio, il destinatario esegue un'operazione (ricevere, elaborare e dimenticare). Dopo aver elaborato quel messaggio, non hai più bisogno di quel messaggio. In questo caso, memorizzare il messaggio in un database persistente non è una soluzione corretta.
Sono pienamente d'accordo con la risposta di @Hiram Chirino per quanto riguarda l'inserimento e l'eliminazione di messaggi nel database se si utilizza il database anziché il sistema di messaggistica.
Vantaggi di questo articolo e di questo articolo
Ci deve essere una caratteristica che ActiveMQ ha che i database no?
Ci sono molti. Dai un'occhiata alla pagina della documentazione per maggiori dettagli. Dai un'occhiata anche ai casi d'uso .
Dai un'occhiata a questa presentazione per comprendere i meccanismi interni di ActiveMQ.
Supponiamo di avere un'applicazione che viene utilizzata in più posizioni contemporaneamente. Supponiamo inoltre che la tua applicazione debba gestire migliaia di richieste al minuto o qualcosa del genere, quindi le normali operazioni di database non possono gestire tali operazioni, Activemq funge da elaborazione del messaggio e porta tutti i messaggi in coda, quindi anche se una delle tue applicazioni si blocca in una posizione l'altra posizione non sarà interessata.