Redis Sentinel vs Cluster

Redis può essere identificato come un server di dizionario remoto progettato principalmente per la velocità. Inoltre, è ampiamente utilizzato come cache in memoria e database NoSQL. Come database o cache, è fondamentale fornire un alto tasso di accesso ai dati, alta disponibilità, frammenti di dati e funzionalità di scalabilità. Redis ha introdotto soluzioni Sentinel e cluster per affrontare gli aspetti menzionati.

Cluster Redis

La tecnologia del cluster Redis che è stata introdotta dalla versione 3.0 Abilita il ridimensionamento orizzontale per una determinata distribuzione Redis. Con i cluster Redis, i dati sono divisi su più nodi del cluster che forniscono un livello di servizio dati coerente e affidabile per le applicazioni.

È un must per avere almeno tre nodi principali per un cluster per funzionare correttamente. Inoltre, ogni nodo principale dovrebbe avere almeno un singolo nodo slave. Inoltre, i cluster Redis consentono un'elevata disponibilità fino a una certa misura promuovendo un nodo slave associato a un'istanza principale fallita in un hardware/software o un errore di rete.

Ogni nodo cluster comunica con altri nodi utilizzando un canale di comunicazione nodo-nodo basato sul protocollo binario. Inoltre, ogni nodo è aperto alle connessioni client utilizzando la porta TCP standard.

Di seguito è riportato uno schizzo di alto livello di una configurazione del cluster Redis di base:

Professionisti:

• Frammento di dati
  • I dati sono condivisi tra più nodi e possono essere regolati dinamicamente.
  • Poiché non esiste un centro di controllo centrale, i dati sono divisi automaticamente tra i nodi.
• Scalabilità
  • Un cluster può ridimensionare fino a 1000 nodi. I nodi possono essere rimossi o aggiunti dinamicamente.

• Failover automatico

• • Redis Cluster supporta l'architettura Master-Slave e consente la tecnica di failover master integrata.

Contro:

• Non completamente disponibile
  • In caso di un grave fallimento, la maggior parte dei nodi principali potrebbe scendere, il che fa sì che l'intero cluster scenda.
• L'alto numero di nodi per singolo cluster
  • È un must per avere almeno tre istanze principali e un singolo nodo slave per master che finisce con sei nodi per impostare un cluster Redis correttamente funzionante.
• Nessuna garanzia di coerenza dei dati
  • La replicazione principale del cluster Redis viene elaborata in modo asincrono e potrebbe influire sulla coerenza.
• Mancanza del supporto della libreria client per il cluster Redis
  • Esistono un numero minimo di librerie client che supportano le implementazioni del cluster Redis.
• Replicazione a livello singolo
  • L'architettura di replica del cluster Redis Cluster consente un solo livello. Una determinata istanza di slave può replicare solo il nodo principale.
• Il cluster Redis potrebbe perdere le scritture riconosciute in alcuni scenari

• La gestione dei dati è più complicata

• • A causa del frammento di dati, gli amministratori del cluster dovrebbero gestire più file RDB e AOF. Inoltre, sono necessari sforzi extra per aggregare i file di persistenza da più nodi per fare un backup.

Redis Sentinel

Redis Sentinel è un approccio ad alta disponibilità per le distribuzioni Redis che funziona come programma separato in background. Porta molte funzionalità alle distribuzioni Redis controllando costantemente lo stato del nodo master e slave, avvisando le modifiche significative relative alle istanze monitorate tramite un'API, inizializzando il processo di failover automatico quando si verifica un fallimento principale e agendo come fonte di origine Autorità per i clienti per scoprire l'indirizzo IP del nodo Master Redis attualmente attivo.

Una configurazione di Redis Sentinel può essere implementata utilizzando almeno tre nodi Sentinel che possono evitare la maggior parte dei problemi in una determinata distribuzione di Redis. Inoltre, in una determinata configurazione sentinella, il valore del quorum definisce il numero minimo di nodi sentinella che dovrebbe confermare quando un master non riuscisce.

Generalmente, il Redis Sentinel viene utilizzato principalmente per supportare l'elevata disponibilità di un database Redis in cui funziona meglio che nell'approccio del clustering.

Quello che segue è un'illustrazione di alto livello di una configurazione minima di Redis Sentinel:

Professionisti:

• Numero minimo di nodi
  • È possibile formare una distribuzione di Redis Sentinel completamente funzionante con tre nodi.
• Altamente disponibile
  • La distribuzione di Redis Sentinel può sopravvivere ai fallimenti del nodo critico senza alcun intervento umano.
  • Può funzionare quando almeno una singola istanza principale è disponibile anche se ogni schiavo è inattivo.
• Replicazione principale migliorata
  • Nella distribuzione di Redis Sentinel, diversi schiavi possono replicare una determinata istanza principale.
• Semplicità e flessibilità

• Redis Sentinel è molto facile da mantenere e ha anche opzioni di configurazione flessibili.

Contro:

• Nessun frammento supportato
  • Non è possibile il frammento di dati. Pertanto, l'accessibilità dei set di dati su larga scala può causare il degrado delle prestazioni.
• Mancanza di scalabilità
• Letture obsolete
  • Di solito, i nodi schiavi servono le letture nella distribuzione di Redis Sentinel. A causa della replica asincrona, le letture potrebbero non essere aggiornate.
• Redis Sentinel dovrebbe essere supportato dalla libreria client
• Il nodo slave non funge da nodo di backup

Redis Sentinel vs Cluster

Redis Cluster e Sentinel sono due approcci in cui ciascuno affronta diversi aspetti relativi a una distribuzione Redis. Per evidenziare, l'approccio del cluster Redis è più adatto per implementazioni complicate che si occupano di set di dati enormi in cui fornisce frammenti automatici di dati per migliori prestazioni di interrogazione di lettura/scrittura, failover principale automatico e replica con alta disponibilità fino a una certa misura. Inoltre, i nodi del cluster Redis possono essere ridimensionati senza sforzo.

D'altra parte, Redis Sentinel è più focalizzato su implementazioni più piccole con alta disponibilità in mente.

Disponibilità

Il cluster Redis non supporta completamente l'alta disponibilità. Perché, se la maggior parte dei maestri non è disponibile, il cluster può scendere. Contrariamente all'approccio del cluster, Redis Sentinel offre un'alta disponibilità senza alcun intervento umano. Ancora più importante, il sentinella può sopravvivere anche con una singola istanza principale in esecuzione quando si verifica un fallimento critico.

Frammento di dati

Il cluster Redis offre funzionalità di frammenti in cui i dati sono distribuiti tra più nodi quando i clienti hanno l'accesso alla rete a tutti i nodi. Abilita una maggiore capacità di prestazione e archiviazione dei dati.

D'altra parte, Redis Sentinel non offre capacità di frammento. Perché lo sharding provoca l'utilizzo dello squilibrio del maestro e dello schiavo.

Replica

Entrambi gli approcci offrono la replica principale con alcune limitazioni. Redis Sentinel consente la replica per più livelli in cui diversi nodi slave possono replicare da una determinata istanza principale. Al contrario, l'approccio del cluster Redis non consente la replica per più livelli. È in grado di replicare l'istanza principale in un singolo nodo slave. Entrambi gli approcci compromettono la coerenza dovuta alla replicazione asincrimale.

Scalabilità

I cluster Redis sono altamente scalabili. Supporta fino a mille nodi in una determinata configurazione di cluster singolo. Inoltre, i cluster consentono l'aggiunta e la rimozione di nodi in modo dinamico e senza sforzo. Redis Sentinel non è scalabile e le scritture sono dirette all'istanza principale, quindi il sentinella non è in grado di affrontare i problemi di separazione delle letture-scrittura.

Architettura

È possibile costruire un Redis Sentinel completamente funzionale con solo tre nodi. Ma per impostare un cluster Redis, richiede almeno tre nodi principali e tre schiavi collegati a loro che è più costoso che nella distribuzione di Redis Sentinel.

Conclusione

Riassumendo, l'approccio del cluster Redis è più focalizzato su distribuzioni complesse quando sono importanti la scalabilità elevata, le prestazioni elevate e un'elevata memoria di dati e l'alta disponibilità non è significativa. D'altra parte, Redis Sentinel è principalmente costruito per applicazioni semplici che si concentrano principalmente sull'alta disponibilità. Rispetto, entrambe le soluzioni sono dotate di pro e contro, ma per supportare gli utenti finali con la distribuzione Redis più finemente sintonizzata.