Redis Cluster by S. Sanfilippo
•
0 likes•2,444 views
Slides of speech by Salvatore Sanfilippo at Cloud Conference 2014
Report
Share
Redis Cluster by S. Sanfilippo
- 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
- 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
- 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.