Pubblica e sottoscrivi (trasferimento dati) con nodi permanenti offline. Le code dei messaggi si adattano bene?

Question

Pubblica e sottoscrivi (trasferimento dati) con nodi permanenti offline. Le code dei messaggi si adattano bene?

#1 da (1 voti)

1

La domanda generale è che tipo di meccanismo posso utilizzare per trasferire dati da e verso editori e abbonati in cui gli editori o gli abbonati possono essere permanentemente offline? Le code dei messaggi possono essere usate per questo?

Possibile approccio

Sto pensando a un approccio in stile coda di messaggi in cui il servizio online (publisher) pubblica i messaggi su una coda online, copia la coda offline e dispone del servizio offline (sottoscrittore), quindi elabora tutti i messaggi in arrivo. Devo progettare una soluzione in cui lo stesso vale per i ruoli invertiti, in cui il servizio offline è l'editore e il servizio online è l'abbonato

I dati vengono fisicamente trasportati tra le reti tramite supporto di memorizzazione. Una volta che il supporto di memorizzazione è collegato a una rete, un servizio di trasferimento dati legge il supporto di memorizzazione e sposta tutti i dati dal supporto di memorizzazione alle code.

Approccio attuale

Il modo in cui attualmente lo faccio è una semplice copia della tabella dove

Il database ha trigger che ascoltano inserimenti, aggiornamenti o eliminazioni, prende nota dell'evento in una tabella degli eventi del database (db_publish_events)
Successivamente un servizio di trasferimento dati legge tutti gli eventi pubblicati da db_publish_events e quindi copia l'intera riga in un file JSON con un tag INSERT, UPDATE o DELETE
Quindi il file JSON viene trasportato manualmente nel sistema di sottoscrizione e quindi elaborato da un servizio di trasferimento dati. Ogni record trasferito in viene contrassegnato in una tabella di ricezione eventi del database (db_received_events).
Un file JSON viene scaricato dal sottoscrittore delle ricevute di riconoscimento di tutti gli eventi ricevuti dal sottoscrittore.
Il file JSON con le ricevute viene rinviato al database di pubblicazione originale e cambia lo stato di db_publish_event per contrassegnarlo come ricevuto in modo che il publisher interrompa l'invio.

Pro

Copia della tabella semplice su una rete

Contro

Nessuna integrità dei dati su tabelle o limiti di eventi aziendali poiché un record viene trasferito alla volta.

Soluzione

Penso a una soluzione in cui l'intero evento viene trasferito come un unico messaggio, quindi prima che l'elaborazione complessa delle regole aziendali divida un evento in più tabelle.

Esiste un modo per software di messaggistica commerciale o open source (RabbitMQ) per eseguire una semplice copia USB dei messaggi per la pubblicazione in una coda offline?

architecture offline pubsub message-passing

posta Kent Johnson 28.09.2017 - 22:56

fonte

1 risposta

Leggi altre domande sui tag architecture offline pubsub message-passing

Come si aggiorna uno stato client con uno stato del server in Vue o in altri framework reattivi Progettazione endpoint del servizio C # .NET per il download di file di grandi dimensioni

score 1 · Accepted Answer

The general question is what kind of mechanism can I use to transfer data to and from publishers and subscribers where publishers or subscribers can be permanently offline? Can message queues be used for this?

Esiste un concetto di code durevoli in alcuni sistemi di messaggistica, ad esempio in RabbitMQ. Ma se il tuo abbonato è offline per un periodo piuttosto lungo, queste code possono ovviamente sovraccaricarsi. E se la tua applicazione è ad alta intensità di dati, potrebbe accadere molto presto. Oltre a ciò, le code sono più lente quando sono sopraffatte (penso che sia un tratto comune di molti sistemi di messaggistica, non solo RabbitMQ).

Ma l'opzione migliore per te è Kafka . Kafka ha il concetto di argomento, che mappa approssimativamente il concetto di coda in RabbitMQ. Ed è perfettamente adatto per memorizzare i dati lì. Qui è una buona introduzione in Kafka. Citato da lì:

What makes Kafka unique is that Kafka treats each topic partition as a log (an ordered set of messages). Each message in a partition is assigned a unique offset. Kafka does not attempt to track which messages were read by each consumer and only retain unread messages; rather, Kafka retains all messages for a set amount of time, and consumers are responsible to track their location in each log. Consequently, Kafka can support a large number of consumers and retain large amounts of data with very little overhead.

Non sono a conoscenza delle dimensioni e del carico del sistema, ma probabilmente l'opzione più semplice potrebbe essere semplice callback http. Quindi se l'abbonato è inattivo - è ok, l'editore riceve il codice http 500 e va avanti in un paio di minuti.