L'architettura cambia dall'uso del disco alla RAM per leggere e scrivere coppie di chiavi / valori provenienti da una rete

Naviga le tue risposte
3

Una WebApp scrive un flusso di dati proveniente da una rete su disco come coppia chiave / valore e quindi legge & inviarlo nuovamente sulla rete dopo pochi millisecondi nel 99% dei casi. Nell'1% dei casi la scrittura / lettura può essere di poche ore a giorni di distanza (davvero non lo so).

La latenza è rigorosa "no" nell'app e dobbiamo servire il 100% dei clienti, quindi sto pianificando di inserire i dati nella RAM e successivamente leggerli e inviarli via rete e scrivere solo su disco se i dati non vengono letti da RAM entro un certo intervallo prefissato.

Quale potrebbe essere la soluzione a questo problema?

P.S - Memcached sembra una buona soluzione per l'utilizzo della RAM anziché del disco, ma può memcached la lettura / scrittura del disco dopo time_to_live?

Anch'io sto guardando Couchbase ma non voglio scrivere su disco in tutti i casi in quanto il 99% di scrittura / lettura avviene in pochi millisecondi.

È possibile che dopo time_to_die Memcached possa scrivere la chiave / il valore su Couchbase invece di rimuoverlo dalla RAM e leggerlo su richiesta?

[Modifica 1]

Dopo aver trascorso gli ultimi tentativi di esplorare varie opzioni. Quanto segue sembra una possibile soluzione

  1. Scrivi il flusso di dati simultaneamente sulla RAM (usando Memcached) e usando il disco (GlusterFS).
  2. Nel caso in cui i dati siano richiesti dal livello applicazione, controllarli prima nella RAM (Memcached) se restituiscono i dati ok, se non controllano i dati sul disco GlusterFS.
  3. Rimuovi il flusso di dati dalla RAM se i dati sono richiesti dall'applicazione o quando time_to_live viene raggiunto a seconda di quale sia precedente.

Suggerimenti molto graditi.

    
posta Gaurav Agarwal 27.03.2013 - 10:40
fonte

4 risposte

2

Molto del modo in cui gestisci questo problema dipende dal requisito del 100% dei clienti serviti. Quando l'obiettivo non prevede assolutamente tempi di inattività, le prestazioni dovranno quasi sempre prendere una seconda posizione rispetto all'affidabilità.

Si dice che l'intervallo di tempo per una risposta tipica è una questione di millisecondi, ma come si desidera gestire la situazione in cui si verifica un errore in questo lasso di tempo? È facile immaginare una macchina che si resetta mentre è in attesa di un lungo processo (ad esempio nell'ordine delle ore) ma tale ripristino potrebbe anche avvenire direttamente nel mezzo di una transazione che normalmente si verifica in pochi millisecondi. Forse la macchina perde potenza in quel momento esatto o la RAM finisce danneggiata.

Se l'affidabilità è la chiave del tuo sistema, allora direi che la tua unica vera opzione è quella di scrivere i dati in una posizione di archiviazione sicura prima di elaborarli. Se i dati non sono memorizzati in modo sicuro, non vengono elaborati dal sistema.

La soluzione migliore sarebbe molto probabilmente di ridurre il tuo modulo di richiesta dal 100% al 99,9% o simile e quindi potresti ignorare situazioni come l'errore sopra menzionato in un processo generalmente veloce.

    
risposta data 27.03.2013 - 17:22
fonte
1

Ricordare che la RAM è volatile e se il server deve resettare, i dati andrebbero persi. Sembra che sarebbe una preoccupazione, come dici tu devi servire al 100% dei clienti.

Suggerirei di scrivere il proprio sistema di buffering che conserva i dati nella RAM ma li scrive sul disco dopo un breve ritardo. Se i dati vengono pubblicati entro questo tempo, non c'è motivo di scrivere sul disco e le risorse possono essere liberate.

Ricorda di ricaricare i dati non inviati all'avvio.

    
risposta data 27.03.2013 - 14:44
fonte
1

Memcached è solo una cache. La versione java pronta all'uso al link supporta la scrittura su disco all'uscita, ma per quello che ti serve, penso che avrai per aggiungere il tuo codice.

Una cosa da considerare è la quantità di dati, al picco di carico, pensi che avrai 3 anni da oggi? Se ciò non è eccessivo, puoi utilizzare la tua RAM con una cache di memoria come whirly e il tuo thread che sbircia nella cache ogni 5 minuti e salva su elementi del disco che non sono stati ancora raccolti. Nota: il tuo POJO dovrà avere il check-in, ma non ti dirà quando un oggetto è stato inserito nella sua cache.

    
risposta data 27.03.2013 - 19:33
fonte
1

Per semplificare le cose. Usa Redis e non parlerai mai più di memcache. Di seguito sono riportati alcuni punti positivi:

Prima di tutto in Redis hai la possibilità di mantenere i dati nel disco.

In secondo luogo, hai strutture dati come lista, set ecc. Supporta anche le operazioni atomiche.

    
risposta data 28.03.2013 - 10:02
fonte

Leggi altre domande sui tag

Devo imparare Python per capire la parte 2 del libro Test Driven development? Rilascio degli strumenti di gestione con DVCS (Mercurial)