Slides of speech by Salvatore Sanfilippo at Cloud Conference 2014

1. Redis Cluster
Come funziona, come fallisce.

2. Cos’e’ la performance?
• Bassa latenza.
• IOPS.
• Qualita’ delle operazioni.

3. 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?

4. I sistemi CP
Client S1
S2
S3
S4
CAP: paghi la consistenza con le performance.

5. I sistemi CP
Client S1
S2
S3
S4
Risposta dopo ACK della maggioranza.

6. 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.

7. 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}

8. 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…

9. 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

10. Replicazione asincrona
Client A,B,C
A,B,C
A,B,C
A,B,C
A,B,C
A,B,C
ACK asincrono

11. Full Mesh
A,B,C A,B,C
D,E,F D,E,F
• Heartbeats.
• Gossip.
• Consenso per
failover.
• Propagazione
configurazione.

12. Proxyless + Redirezioni
A,B,C D,E,F G,H,I L,M,N O,P,Q R,S,T
Client Client
A? D?

13. 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

14. 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?

15. 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…

16. Failover: slave vincente
Failed
Slave
Slave
Slave
Master
Master
Master
Epoch = Epoch+1!
(tempo logico)
Vota per me!

17. 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.

18. 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.

19. Failure mode… #1
Client A,B,C
A,B,C
A,B,C
Failed
A,B,C
A,B,C
Scrittura!
persa…

20. Failure mode #2
Client
A,B,C
A,B,C
D,E,F
G,H,I
Minoranza Maggioranza

21. Limitare divergenze
Client
A,B,C
D,E,F
G,H,I
Minoranza Maggioranza
After node-timeot

22. Operazioni multi-chiave
!
• Hey hashtags!
• {user:1000}.following {user:1000}.followers.
• Availability compromessa, ma nessun scambio dati
tra nodi.

23. 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

24. {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 …

25. 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).

26. 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.

27. Amministrazione
• HA come conseguenza di usare Redis Cluster.
• redis-trib: create, fix, reshard, …!
• Nuovi strumenti di visualizzazione necessari.

28. 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.

29. 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.