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