Rimozione di voci redis da più istanze di redis

Question

Rimozione di voci redis da più istanze di redis

#1 da (1 voti)

0

Ho un problema interessante che mi piacerebbe risolvere. Supponiamo di avere 2 distribuzioni, il Data Center degli Stati Uniti e il Data Center in Europa, ciascuna contenente Web Server e un'istanza Redis (replicata, ma che potrebbe eventualmente crescere nel proprio cluster utilizzando TWEMPROXY).

Disponiamo di un servizio di bilanciamento del carico che identifica il Centro dati disponibile più vicino e ne indirizza le richieste. La nostra logica applicativa è in grado di identificare un titolare e instradare la richiesta al centro dati appropriato indipendentemente da dove viene chiamato.

Ad es. se accedo agli inquilini statunitensi dall'Europa, Load Balancer invierà le richieste al data center Europa, ma l'applicazione identificherà l'inquilino e accederà ai dati dal database del titolare (che in questo caso risiede negli Stati Uniti).

Durante la pubblicazione delle richieste, i dati vengono anche memorizzati nella cache in Redis Server accoppiato (che risiede in Europa). E questo è quando iniziano i problemi.

Quando i dati vengono invalidati da qualcuno negli Stati Uniti, i dati vengono cancellati dai server redis abbinati USA, ma non dall'Europa. Pertanto, se qualcuno accede ai dati degli Stati Uniti dai server europei, continuerà a ricevere dati obsoleti a meno che non venga cancellato.

C'è un modo per invalidare una voce nel Data Center degli Stati Uniti e quindi anche invalidarla dal Data Center Europa? Qualcuno ha implementato una strategia in base alla quale è possibile identificare facilmente i server Redis in cui risiedono i dati invalidati in modo da poterli eliminare selettivamente dai server in cui risiede? Mi chiedo se la mia unica opzione è quella di inviare un messaggio ad ogni Redis Server per cancellare la chiave, se esiste. Questo è altamente poco pratico e non si ridimensiona.

L'altra alternativa è quella di accedere e memorizzare sempre i dati dell'Europa dalle cache Redis europee indipendentemente da dove provenga la richiesta. Ciò potrebbe aumentare la latenza di Redis per qualcuno che proviene dagli Stati Uniti e sta accedendo agli Euro Data Center, ma le probabilità che ciò accada sono piuttosto basse.

Mi piacerebbe sentire cosa pensano gli altri di questo.

Anup

redis distributed-computing

posta Anup Marwadi 22.11.2017 - 18:49

fonte

1 risposta

Leggi altre domande sui tag redis distributed-computing

Lintero MySQL: Lettere un pacchetto python installato Integrazione con un modulo python scritto dall'utente Progettazione di app web con ruolo condiviso

score 1 · Accepted Answer

Due elementi in CS sono difficili: denominazione, cache invalidata e off-by-one.

Per le distribuzioni N = 2, il tuo approccio ingenuo sembra adatto:

send a message to every Redis Server to clear the key off if it exists. This is highly impractical and will not scale.

Non sono d'accordo sul fatto che sia così poco pratico. Utilizza identificatori di piccole dimensioni ( non GUID), raggruppali e ogni millisecondo di K invia il batch di ID non validi all'altro centro dati. I messaggi di invalidazione dell'inondazione diventano brutti quando N diventa più grande, ma 2 non è grande.

Ecco un approccio più sofisticato:

Invece di lasciare che i client eseguano le operazioni di lettura come fanno ora, falli eseguire un'operazione di leasing (superiore in alto) contro la tua origine dati. Il cliente invia una scadenza, alcuni secondi o ore nel futuro. Source aggiunge il nome del client e la scadenza ai metadati per il valore recuperato. Il cliente può godere liberamente delle hit della cache locale dei dati memorizzati nella cache fino alla scadenza, dopo di che subiranno perdite di cache. Source invierà alla cache messaggi non validi a tutti i titolari di contratti di locazione e cancellerà tale elenco, dopo aver ricevuto un aggiornamento.

Questo rende ogni accesso all'origine dati un po 'più costoso man mano che manteniamo i metadati, ma elimina la larghezza di banda sprecata della cache di flooding invalida i messaggi ai client che (A) stanno potenzialmente memorizzando nella cache un elemento ma (B) in realtà la probabilità è memorizzato nella cache è estremamente basso. Alcuni articoli saranno caldi, altri freddi. Per conservare un elemento hot a tempo indeterminato, un client può notare che un hit della cache si è verificato dopo la metà dell'intervallo di lease trascorso, soddisfare immediatamente l'hit e accodare un'altra query (un rinnovo del lease) all'origine dati originale, per estendere la data e ora della scadenza . Durante la manutenzione programmata del server o il riavvio, il server può rifiutare le richieste di lettura fino alla scadenza di tutti i client, o meglio può cancellare tutti i lease inviando cache invalidate a tutti i client che compaiono su tutti gli elenchi di metadati.