Persistenza dei messaggi nelle code dei messaggi

1

Ho esaminato diverse code di messaggi come indicato in questo link . Molti dei più grandi e più popolari sono solo in memoria.

Posso capire la necessità di questo in alcune situazioni, tuttavia in una grande architettura questo ha poco senso per me. Ad esempio se ho una serie di lavori che devono essere eseguiti come calcoli utente, aggiornamenti oggetto, aggiornamento informazioni, e poi il MQ si blocca tutto il lavoro è perso. Se questo è un imperativo, il lavoro perso potrebbe essere caricato di nuovo, tuttavia, perché dovrei voler?

Immagino che ci siano informazioni vitali e quindi regolari, tuttavia se utilizzo un MQ di non persistenza, tutti i miei dati sarebbero regolari e ciò non sembra valido.

    
posta Telavian 14.06.2016 - 01:53
fonte

1 risposta

1

Considera un cliente che desidera inviare un messaggio a una coda. Il gestore code di solito inviava una conferma al client per indicare che il messaggio era stato consegnato correttamente alla coda. Un MQ persistente dovrebbe prima scrivere il messaggio nella memoria permanente, che per la maggior parte dei supporti di memorizzazione sarebbe un'operazione costosa di IO relativa alle operazioni di memoria.

Il costo della persistenza nelle code di messaggi è un fattore che può giocare in una decisione di andare per code di messaggi non persistenti.

Gli svantaggi delle code di messaggi non persistenti sono essenzialmente la necessità di contrastare la potenziale perdita di dati in caso di interruzione parziale o totale di una macchina, tuttavia questo non è sempre necessariamente vero se si opta per la distribuzione non persistente distribuita code di messaggi in un'infrastruttura basata su cloud su più data center. Ciò garantirebbe che anche un'interruzione completa del data center per un provider di hosting cloud non comporterebbe la perdita del messaggio, almeno un altro nodo è garantito per il messaggio.

Naturalmente, se il potenziale per la perdita dei messaggi non è un problema serio per la tua applicazione, non hai nemmeno bisogno di una soluzione così complessa. Diventa un confronto tra gli attributi di qualità, Performance vs. Affidabilità.

    
risposta data 14.06.2016 - 04:08
fonte

Leggi altre domande sui tag