Redis Cluster by S. Sanfilippo
-
Upload
corley-srl -
Category
Internet
-
view
706 -
download
0
description
Transcript of Redis Cluster by S. Sanfilippo
Redis ClusterCome funziona, come fallisce.
Cos’e’ la performance?
• Bassa latenza.
• IOPS.
• Qualita’ delle operazioni.
Go Cluster
• Redis Cluster doveva somigliare a Redis.
• Anche se bisogna scendere a compromessi.
• CAP? Fare il merge dei valori? Mirare alla strong consistency? Come replicare i dati?
I sistemi CP
Client S1
S2
S3
S4
CAP: paghi la consistenza con le performance.
I sistemi CP
Client S1
S2
S3
S4
Risposta dopo ACK della maggioranza.
Non e’ cosi’ semplice.S1 S2 S3
Disk Disk Disk
Il disco di ogni nodo fa parte del nostro sistema distribuito in ogni Modello di Sistema sano.
I sistemi AP
Client
S1
S2
Consistenza eventuale = Merging.
Client
A = {1,2,3,8,12,13,14}
A = {2,3,8,11,12,1}
Altre consistenze…
• La “C” di CAP e’ una consistenza “stretta”.
• Ma non e’ l’unica possibile.
• La consistenza e’ in realta’ il contratto tra il database e il client…
Redis Cluster
Client
A,B,C
A,B,C
Partizionamento e Replicazione (asincrona).
A,B,C
D,E,F
D,E,F
D,E,F
Replicazione asincrona
Client A,B,C
A,B,C
A,B,C
A,B,C
A,B,C
A,B,C
ACK asincrono
Full Mesh
A,B,C A,B,C
D,E,F D,E,F
• Heartbeats.
• Gossip.
• Consenso per failover.
• Propagazione configurazione.
Proxyless + Redirezioni
A,B,C D,E,F G,H,I L,M,N O,P,Q R,S,T
Client Client
A? D?
Failure detection
• Utilizza il gossip per arrivare ad un consenso “informale”.
• Trigger per il failover (che invece usa un consenso forte).
• Stati fondamentali: PFAIL -> FAIL
Gestire i metadata
• Dopo il fallimento, segue il failover.
• Il cluster necessita di una visione coerente.
• Chi serve questo slot ora?
• Cosa accade durante le partizioni?
Raft e il failover• Questi problemi sono risolti usando un “pezzo” di
Raft.
• Raft e’ un algoritmo distribuito del consenso, come Paxos, ma fatto di parti separate e chiare.
• Il paper originale di Raft e’ gia’ una pietra miliare.
• Ma tutto Raft e’ troppo per Redis Cluster…
Failover: slave vincente
FailedSlave
Slave
Slave
Master
Master
Master
Epoch = Epoch+1!(tempo logico)
Vota per me!
Troppo facile?• Perche’ non abbiamo bisogno di usare Raft
completo?
• L’essenza e’, possiamo rimpiazzare tutto lo “stato” per uno slot con un solo messaggio, e il nuovo stato non dipende da quello vecchio.
• Lo stesso algoritmo e’ stato applicato a Sentinel v2 con buoni risultati.
Propagazione
• Dopo il failover la configurazione viene spedita a tutti i nodi.
• Se ci sono partizioni non importa perche’ viene rispedita per sempre a tutti i nodi non aggiornati.
• Quella con epoch maggiore vince sempre.
Failure mode… #1
Client A,B,C
A,B,C
A,B,C
Failed
A,B,C
A,B,C
Scrittura!persa…
Failure mode #2Client
A,B,C
A,B,C
D,E,F
G,H,I
Minoranza Maggioranza
Limitare divergenzeClient A,B,C
D,E,F
G,H,I
Minoranza MaggioranzaAfter node-tim
eot
Operazioni multi-chiave
!
• Hey hashtags!
• {user:1000}.following {user:1000}.followers.
• Availability compromessa, ma nessun scambio dati tra nodi.
Operazioni multi-chiave (availability)
!
• Operazioni a chiave singola: sempre disponibili.
• Operazioni multi-chiave, disponibili se:
• Il custer e’ stabile (nessun resharding manuale).
• Il nodo contiene tutte le chiavi della query.
• Altrimenti -TRYAGAIN
{User:1}.key_A {User:2}.Key_B
{User:1}.key_A {User:1}.Key_B
{User:1}.key_A {User:1}.Key_B
SUNION key_A key_B!-TRYAGAIN
SUNION key_A key_B!… output …
SUNION key_A key_B!… output …
Persistenza
• Il concetto di persistenza “Point in Time” non esiste nel cluster globalmente, ma solo per hash slot.
• Anche le transazioni e le operazioni multi-chiave sono per hash slot.
• Con il Redis Cluster e’ opportuno usare AOF e non RDB (ma i due stanno per convergere).
Librerie per i client
• Redis-rb-cluster e’ stato rilasciato come esempio di client minimo accettabile.
• Jedis, Predis, StackExchange Redis, hanno aggiunto supporto per Redis Cluster nelle settimane scorse.
Amministrazione
• HA come conseguenza di usare Redis Cluster.
• redis-trib: create, fix, reshard, …!
• Nuovi strumenti di visualizzazione necessari.
Rilascio
• Siamo alla beta-2
• Ogni mese una nuova beta
• In un paio di mesi: Release Candidate
• RC usabile che diventa “stable” in base ad un processo empirico.
Migrazione• Da singolo master a Redis Cluster è immediato.
• Da sharding pre-esistente ci saranno due diversi modi.
• Non è necessario ad oggi fare lo sharding usando lo stesso algoritmo di Redis Cluster.
• Problema: op multi-chiave senza hash tag.
• Problema 2: op multi-chiave mission critical.