Design pattern per grandi quantità di dati traboccanti?

4

Le nostre code correnti pubblicano messaggi che sono consumati da servizi di terze parti con limiti di frequenza. Attualmente i messaggi vengono riprovati con il back-off esponenziale. Tuttavia, potrebbero verificarsi casi in cui i dati arrivano in modo così rapido che i tentativi non verranno mai raggiunti.

La maggior parte dei servizi di terze parti offre importazioni di lotti alternative e la soluzione che ho trovato finora è quella di scrivere i dati in file da elaborare fuori banda.

Esistono schemi di progettazione per la memorizzazione di dati traboccanti?

    
posta kreek 22.10.2015 - 22:32
fonte

3 risposte

1

Il problema principale descritto è che i produttori sono più veloci dei consumatori. Questo mi ricorda un sacco di link . Stream reattivi sono un'iniziativa che ho notato di recente per fornire una soluzione a questo tipo di impostazione.

Puoi dare un'occhiata a tutti i prodotti software orientati alla coda come:

  • Akka (letitcrash.com è il loro blog con alcuni post generali interessanti) o
  • ZeroMQ (La loro guida offre alcune configurazioni applicabili a qualsiasi sistema di code)

per vedere come puoi gestire i produttori di successo.

Tuttavia, la domanda principale rimane il modo in cui vuoi affrontarlo dal punto di vista del tuo business? Dal momento che i tuoi consumatori (di terze parti) sono limitati nella quantità di messaggi che possono gestire, il tuo approccio all'importazione in batch dei messaggi memorizzati nel buffer sembra ragionevole. I messaggi aggregati o addirittura in caduta possono anche essere validi a seconda del tuo scenario.

Indipendentemente da come vuoi reagire all'overflow, la tua coda dovrebbe essere messa al corrente di questo fatto (cioè introducendo la contropressione) e quindi puoi applicare la tua strategia che dipenderà dalle tue esigenze.

Nel mio ultimo progetto ho finito per estrarre messaggi da un utente tramite il sistema di coda:

  • I produttori non stavano hogging risorse che potrebbero essere utilizzate per lavorare attraverso la pila di messaggi esistente.
  • I lavoratori che elaborano i messaggi possono recuperare nuovi messaggi quando sono pronti senza la necessità di inserire nuovi messaggi su di essi.
  • Ho avuto un tempo di fermo garantito a intervalli specifici dei produttori che mi hanno permesso di recuperare dal momento che non potevo lasciare alcun messaggio.

Spero che questo fornisca degli handle che ti consentano di trovare la tua soluzione.

    
risposta data 23.10.2015 - 14:01
fonte
1

La situazione ideale sarebbe quella di far archiviare i messaggi nella coda per un tempo indefinito, fornire la posizione del messaggio mentre recapita i messaggi e consentire di riprendere l'abbonamento da una determinata posizione (anziché solo da ora in avanti). In questo modo, il tuo abbonato può tenere traccia dell'ultimo messaggio che ha elaborato correttamente e iniziare da quella posizione in avanti al suo riavvio. EventStore fa questo. Si tratta di un database di sola aggiunta che si comporta anche come coda a cui è possibile iscriversi.

Supponendo che la tua coda corrente fornisca solo i messaggi degli iscritti da ora in poi, dovrai memorizzare i messaggi non appena entrano (file o database o qualsiasi altra cosa). Quando si inviano messaggi a terze parti, è necessario registrare l'ultimo riuscito (per terza parte) in modo da poter riprendere da lì se si trova troppo indietro o si blocca. Periodicamente, presumo che vorrai eliminare i vecchi messaggi che tutte le terze parti hanno elaborato.

Checkpoint

Puoi salvare il checkpoint (id dell'ultimo messaggio elaborato correttamente) prima o dopo aver consegnato il messaggio.

Il salvataggio del checkpoint prima della consegna viene chiamato Al massimo una volta la consegna, perché è possibile che il messaggio non venga mai consegnato. Ad esempio: Checkpoint viene salvato, ma prima della consegna il computer si blocca. Al riavvio, il checkpoint caricato indica che il messaggio è già stato elaborato e carica quello successivo.

Il salvataggio del checkpoint dopo la consegna viene chiamato Almeno una volta la consegna, perché è possibile recapitare il messaggio più volte. Ad esempio: il messaggio viene inviato, ma il computer si blocca prima che il checkpoint venga salvato. Al riavvio, il checkpoint punta allo stesso messaggio inviato, che verrà nuovamente inviato nuovamente.

Almeno una volta la consegna (salvare il punto di controllo dopo il completamento della consegna) è più sicuro fintanto che i messaggi non inducono effetti collaterali (cioè sono idempotenti). Ad esempio, se il messaggio è CountIncreasedBy: 5, ha un effetto collaterale perché il suo nuovo valore dipende dal vecchio valore e l'elaborazione di questo messaggio più di una volta modificherà il valore sul ricevitore. Tuttavia, se il messaggio dice NewCountSetTo: 37, puoi elaborarlo qualsiasi numero di volte di seguito e avrà sempre lo stesso effetto.

Tuttavia, con "almeno una volta" devi anche guardare i messaggi velenosi. Si tratta di messaggi che si bloccano sempre quando vengono tentati di essere consegnati, quindi non è possibile procedere oltre. Saranno riprovati all'infinito a meno che tu non metta qualcosa a posto per guardarlo.

Si noti inoltre che se non ci sono circostanze in cui le terze parti possono raggiungere (ovvero non è solo traffico burst, ma traffico medio che travolge la terza parte), allora si verificherà lo stesso problema di overflow disco rigido. A quel punto, dovrai utilizzare i metodi offline o semplicemente saltare i messaggi una volta che l'elaborazione è troppo indietro.

    
risposta data 23.10.2015 - 00:14
fonte
1

Come comprendo, ci sono componenti di tre tipi nel sistema in questione.

                                         |
         ,----> [Message Translator] ----|---> [3rd Party Endpoint]
        /                                |
  [Queue] ----> [Message Translator] ----|---> [3rd Party Endpoint]
        \                                |
         '----> [Message Translator] ----|---> [3rd Party Endpoint]
                                         |

    [type] - component of type
    -----> - data flow
         | - internal/external component boundary
.

La prima cosa che mi viene in mente è la sostituzione di traduttori di messaggi con aggregators , memorizza i messaggi e li invia in batch. I dati batch possono essere archiviati in un database veloce (nosql) o anche in un file flat se i requisiti lo consentono. Se gli endpoint di terze parti richiedono dati grezzi, non si può fare molto di più. In generale, controlla Modelli di integrazione aziendale .

Le tecniche Event Sourcing (e tutti i database basati su di esse) possono essere utili, specialmente se il problema può essere descritto in termini di Domain Objects ed Domain Events ( Domain Driven Design ).

    
risposta data 23.10.2015 - 01:28
fonte