Redis Cluster by S. Sanfilippo
Upcoming SlideShare
Loading in...5
×
 

Redis Cluster by S. Sanfilippo

on

  • 374 views

Slides of speech by Salvatore Sanfilippo at Cloud Conference 2014

Slides of speech by Salvatore Sanfilippo at Cloud Conference 2014

Statistics

Views

Total Views
374
Views on SlideShare
371
Embed Views
3

Actions

Likes
0
Downloads
5
Comments
0

2 Embeds 3

http://www.slideee.com 2
https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Redis Cluster by S. Sanfilippo Redis Cluster by S. Sanfilippo Presentation Transcript

    • Redis Cluster Come 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 Failed Slave 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 #2 Client A,B,C A,B,C D,E,F G,H,I Minoranza Maggioranza
    • Limitare divergenze Client A,B,C D,E,F G,H,I Minoranza Maggioranza After node-timeot
    • 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.