Redis Cluster by S. Sanfilippo

1,583 views

Published on

Slides of speech by Salvatore Sanfilippo at Cloud Conference 2014

Published in: Internet
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,583
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Redis Cluster by S. Sanfilippo

  1. 1. Redis Cluster Come funziona, come fallisce.
  2. 2. Cos’e’ la performance? • Bassa latenza. • IOPS. • Qualita’ delle operazioni.
  3. 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. 4. I sistemi CP Client S1 S2 S3 S4 CAP: paghi la consistenza con le performance.
  5. 5. I sistemi CP Client S1 S2 S3 S4 Risposta dopo ACK della maggioranza.
  6. 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. 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. 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. 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. 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. 11. Full Mesh A,B,C A,B,C D,E,F D,E,F • Heartbeats. • Gossip. • Consenso per failover. • Propagazione configurazione.
  12. 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. 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. 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. 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. 16. Failover: slave vincente Failed Slave Slave Slave Master Master Master Epoch = Epoch+1! (tempo logico) Vota per me!
  17. 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. 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. 19. Failure mode… #1 Client A,B,C A,B,C A,B,C Failed A,B,C A,B,C Scrittura! persa…
  20. 20. Failure mode #2 Client A,B,C A,B,C D,E,F G,H,I Minoranza Maggioranza
  21. 21. Limitare divergenze Client A,B,C D,E,F G,H,I Minoranza Maggioranza After node-timeot
  22. 22. Operazioni multi-chiave ! • Hey hashtags! • {user:1000}.following {user:1000}.followers. • Availability compromessa, ma nessun scambio dati tra nodi.
  23. 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. 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. 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. 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. 27. Amministrazione • HA come conseguenza di usare Redis Cluster. • redis-trib: create, fix, reshard, …! • Nuovi strumenti di visualizzazione necessari.
  28. 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. 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.

×