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.