Redis Sentinel vs Cluster

Redis peut être identifié comme un serveur de dictionnaire distant qui est principalement conçu pour la vitesse. En outre, il est largement utilisé comme une base de données en mémoire et en mémoire NOSQL. En tant que base de données ou cache, il est essentiel de fournir un taux élevé d'accès aux données, de haute disponibilité, de fragmentation des données et de fonctionnalités d'évolutivité. Redis a présenté des solutions Sentinel et Cluster pour aborder les aspects mentionnés.

Cluster redis

La technologie Redis Cluster qui a été introduite à partir de la version 3.0 Active la mise à l'échelle horizontale pour un déploiement redis donné. Avec les clusters redis, les données sont divisées sur plusieurs nœuds de cluster qui fournissent une couche de service de données cohérente et fiable pour les applications.

Il est indispensable d'avoir au moins trois nœuds maîtres pour qu'un cluster fonctionne correctement. De plus, chaque nœud maître doit avoir au moins un seul nœud esclave. En outre, les clusters Redis permettent jusqu'à une certaine mesure la haute disponibilité en favorisant un nœud esclave associé à une instance de maîtrise défaillante dans un matériel / logiciel ou une défaillance du réseau.

Chaque nœud de cluster communique avec d'autres nœuds à l'aide d'un canal de communication de nœud à nœud basé sur un protocole binaire. De plus, chaque nœud est ouvert aux connexions du client en utilisant le port TCP standard.

Ce qui suit est un croquis de haut niveau d'une configuration de cluster Redis de base:

Avantages:

• Fragment de données
  • Les données sont partagées entre plusieurs nœuds et peuvent être ajustés dynamiquement.
  • Puisqu'il n'y a pas de centre de contrôle central, les données sont divisées entre les nœuds.
• Évolutivité
  • Un cluster peut évoluer jusqu'à 1000 nœuds. Les nœuds peuvent être supprimés ou ajoutés dynamiquement.

• Basculement automatique

• • Le cluster Redis prend en charge l'architecture maître-esclave et permet la technique de basculement maître intégrée.

Les inconvénients:

• Pas complètement disponible
  • En cas de défaillance majeure, la plupart des nœuds maîtres peuvent baisser, ce qui fait baisser l'ensemble du cluster.
• Le nombre élevé de nœuds par cluster unique
  • Il est indispensable d'avoir au moins trois instances de maître et un seul nœud esclave par maître qui se retrouve avec six nœuds pour configurer un cluster Redis fonctionnel correctement fonctionnel.
• Aucune garantie de cohérence des données
  • Redis Cluster Master Replication est traité de manière asynchrone et cela pourrait affecter la cohérence.
• Manque de prise en charge de la bibliothèque client pour le cluster redis
  • Il existe un nombre minimal de bibliothèques clients qui prennent en charge les implémentations de cluster redis.
• Réplication de couche unique
  • L'architecture de réplication maître de Redis Cluster ne permet qu'une seule couche. Une instance d'esclave donnée ne peut reproduire que le nœud maître.
• Redis Cluster peut perdre des écritures reconnues dans certains scénarios

• La gestion des données est plus compliquée

• • En raison de la percaison des données, les administrateurs de cluster doivent gérer plusieurs fichiers RDB et AOF. De plus, un effort supplémentaire est nécessaire pour agréger les fichiers de persistance de plusieurs nœuds pour effectuer une sauvegarde.

Redis Sentinel

Redis Sentinel est une approche à haute disponibilité pour les déploiements redis qui s'exécute comme un programme distinct en arrière-plan. Il apporte de nombreuses fonctionnalités à vos déploiements Redis en vérifiant constamment l'état du maître et du nœud esclave, en notifiant les modifications significatives liées aux instances surveillées via une API, en initialisant le processus de basculement automatique lorsqu'un échec maître se produit et en agissant comme une source de source de Autorité pour les clients pour découvrir l'adresse IP actuellement active Redis Master Node.

Une configuration Redis Sentinel peut être mise en œuvre en utilisant au moins trois nœuds sentinelles qui peuvent éviter la plupart des problèmes dans un déploiement redis donné. De plus, dans une configuration sentinelle donnée, la valeur du quorum définit le nombre minimum de nœuds sentinelles qui devraient confirmer lorsqu'un maître est échoué.

Généralement, le Redis Sentinel est principalement utilisé pour soutenir la haute disponibilité d'une base de données Redis où elle fonctionne mieux que dans l'approche de clustering.

Ce qui suit est une illustration de haut niveau d'une configuration minimale de Redis Sentinel:

Avantages:

• Nombre minimal de nœuds
  • Un déploiement Redis Sentinel entièrement fonctionnel peut être formé avec trois nœuds.
• Très disponible
  • Le déploiement de Redis Sentinel peut survivre à des défaillances de nœuds critiques sans aucune intervention humaine.
  • Il peut fonctionner quand au moins une seule instance de maître est disponible même si chaque esclave est en panne.
• Replication maître améliorée
  • Dans le déploiement de Redis Sentinel, plusieurs esclaves peuvent reproduire une instance de maître donnée.
• Simplicité et flexibilité

• Redis Sentinel est très facile à entretenir et possède également des options de configuration flexibles.

Les inconvénients:

• Aucun fragment pris en charge
  • La pépins de données n'est pas possible. Par conséquent, les ensembles de données à grande échelle peuvent entraîner la dégradation des performances.
• Manque d'évolutivité
• Lectures obsolètes
  • Habituellement, les nœuds esclaves servent des lectures dans le déploiement de Redis Sentinel. En raison de la réplication asynchrone, les lectures peuvent ne pas être à jour.
• Redis Sentinel doit être pris en charge par la bibliothèque client
• Le nœud esclave n'agit pas comme un nœud de sauvegarde

Redis Sentinel vs Cluster

Le cluster redis et la sentinelle sont deux approches où chacun aborde différents aspects liés à un déploiement redis. Pour mettre en évidence, l'approche Redis Cluster est plus adaptée aux implémentations compliquées qui traitent des ensembles de données massifs où il fournit une épisode de données automatique pour une meilleure lecture / écriture de requête, un basculement maître automatique et une réplication avec une grande disponibilité jusqu'à une certaine mesure. De plus, les nœuds de cluster redis peuvent être mis à l'échelle sans effort.

D'un autre côté, le Redis Sentinel se concentre davantage sur des implémentations plus petites avec une haute disponibilité à l'esprit.

Disponibilité

Le cluster Redis ne prend pas en charge pleinement la haute disponibilité. Parce que, si la majorité des maîtres ne sont pas disponibles, le cluster peut baisser. Contrairement à l'approche du cluster, le Redis Sentinel offre une haute disponibilité sans aucune intervention humaine. Plus important encore, la sentinelle peut survivre même avec une seule instance de maîtrise en cours lorsqu'une échec critique se produit.

Fragment de données

Le cluster Redis offre des capacités de fragment où les données sont distribuées entre plusieurs nœuds lorsque les clients ont un accès réseau à tous les nœuds. Il permet une augmentation des performances et de la capacité de stockage des données.

D'un autre côté, Redis Sentinel n'offre pas de capacités de fragment. Parce que l'éclat provoque l'utilisation du déséquilibre du maître et de l'esclave.

Réplication

Les deux approches offrent une réplication maître avec certaines limites. Redis Sentinel permet la réplication de plusieurs couches où plusieurs nœuds esclaves peuvent se reproduire à partir d'une instance de maître donnée. En revanche, l'approche Redis Cluster ne permet pas la réplication de plusieurs couches. Il est seulement capable de reproduire l'instance maître dans un seul nœud esclave. Les deux approches compromettent la cohérence due à la réplication asynchrone.

Évolutivité

Les clusters Redis sont très évolutifs. Il prend en charge jusqu'à des mille nœuds dans une configuration de cluster unique donnée. De plus, les clusters permettent d'ajouter et de retirer les nœuds dynamiquement et sans effort. Redis Sentinel n'est pas évolutif et les écritures sont adressées à l'instance de maître, donc le Sentinel n'est pas en mesure de faire face aux problèmes de séparation en lecture-écriture.

Architecture

Un Redis Sentinel entièrement fonctionnel peut être construit avec seulement trois nœuds. Mais pour configurer un cluster Redis, il nécessite au moins trois nœuds maîtres et trois esclaves qui leur sont attachés, ce qui est plus coûteux que dans le déploiement de Redis Sentinel.

Conclusion

Pour résumer, l'approche Redis Cluster est plus axée sur les déploiements complexes lorsque une évolutivité élevée, des performances élevées et un stockage élevé de données sont importants et que la haute disponibilité n'est pas significative. D'un autre côté, Redis Sentinel est principalement conçu pour des applications simples qui sont principalement axées sur la haute disponibilité. Par rapport à, les deux solutions sont livrées avec leurs avantages et leurs inconvénients, mais pour soutenir les utilisateurs finaux avec un déploiement de Redis plus finement réglé.