Présentation de RedisRaft, une nouvelle option de déploiement à forte cohérence

Présentation de RedisRaft, une nouvelle option de déploiement à forte cohérence

Redis Raft (en cours de développement) est un nouveau module pour Redis open source qui permet d’exploiter plusieurs serveurs Redis comme un seul cluster tolérant aux pannes et fortement cohérent. Comme son nom l’indique, il est basé sur la Algorithme de consensus de radeau Et un bibliothèque C open source qui l’implémente.

RedisRaft apporte une nouvelle cohérence forte avec sérialisation stricte option de déploiement vers Redis et l’écosystème Redis. Le nouveau module permet d’utiliser Redis avec les clients, les bibliothèques et les types de données existants de Redis dans des scénarios hors cache nécessitant un haut niveau de fiabilité et de cohérence.

Les débuts de RedisRaft

RedisRaft a commencé comme un “projet parallèle” expérimental peu de temps avant la sortie de Redis 5. L’API du module Redis a été introduite dans Redis 4, principalement conçue pour prendre en charge les modules qui implémentent de nouveaux types de données et de nouvelles commandes. Nous voulions explorer jusqu’où nous pouvions étendre l’API et utiliser des modules pour étendre Redis de manière encore plus radicale. Mais nous voulions également aboutir à quelque chose d’utile : une option de déploiement à forte cohérence pour Redis.

Un cluster RedisRaft offre le même niveau de cohérence et de fiabilité que celui attendu de magasins de données fiables et bien connus tels que ZooKeeper ou Etcd. En un mot, dans RedisRaft :

  • Les écritures reconnues sont garanties d’être validées et jamais perdues.
  • Les lectures renverront toujours l’écriture validée la plus récente.

Comme on peut s’y attendre de la part de magasins de données fiables offrant ce niveau de cohérence, de telles garanties impliquent des compromis en termes de performances et de disponibilité. Dans Redis Raft :

  • Les opérations client dépendent des nœuds de cluster échangeant des messages, elles sont donc liées à la latence du réseau.
  • Les écritures doivent être vidées sur le disque avant de se terminer, elles sont donc liées à la latence d’E/S du disque.
  • Le cluster n’est disponible que tant que la majorité des nœuds sont opérationnels, sains et capables de communiquer entre eux.

Comment fonctionne RedisRaft

Une fois qu’un module RedisRaft est chargé dans Redis, il prend en charge la communication entre les nœuds du cluster, la réplication du journal Raft ou des instantanés, la persistance, etc. Le noyau Redis n’en est toujours pas conscient et, en ce qui le concerne, il fonctionne comme un serveur autonome sans clustering, persistance ou réplication.

La configuration d’un cluster RedisRaft à trois nœuds est aussi simple que le démarrage de trois serveurs Redis, comme illustré ici :

redis-server --loadmodule /path/to/redisraft.so

Voici comment se connecter au premier serveur et créer le cluster Raft :

10.0.0.1:6379> RAFT.CLUSTER INIT
OK 989645460313dd2ddb051f033c791222

Ensuite, vous vous connectez aux deux autres serveurs et les joignez au cluster :

10.0.0.2:6379> RAFT.CLUSTER JOIN 10.0.0.1:6379
OK
10.0.0.3:6379> RAFT.CLUSTER JOIN 10.0.0.1:6379
OK

Accéder au cluster

Une fois RedisRaft configuré, nous pouvons écrire des données dans notre cluster :

10.0.0.1:6379> INCR counter:1
(integer) 1

La réception d’une réponse montre que notre écriture a été répliquée sur au moins une majorité des nœuds du cluster (2 nœuds dans notre cas), et engagés dans leur stockage persistant.

Raft est basé sur un concept de leader fort, ce qui signifie que toutes les opérations du client doivent aller au nœud leader et démarrer à partir de celui-ci. Dans ce cas, notre client était en effet connecté au leader, mais le leadership du cluster est dynamique et les clients ne savent pas nécessairement qui est le leader.

Essayer la même opération sur un nœud suiveur (non leader) crée cette réponse :

10.0.0.3:6379> INCR counter:1
(error) MOVED 10.0.0.1:6379

Ainsi, en tant que client, nous pouvons maintenant détecter cette erreur, rétablir une connexion avec le nœud leader comme spécifié et réessayer notre commande.

Mais que se passe-t-il si nous ne voulons pas modifier notre application existante ? Heureusement, RedisRaft peut également être configuré pour gérer automatiquement cela pour nous. En activant mode proxy suiveurnous pouvons faire en sorte que les nœuds du cluster transmettent automatiquement notre demande au leader et fournissent la réponse lorsqu’elle est disponible :

10.0.0.3:6379> RAFT.CONFIG SET follower-proxy yes
OK
10.0.0.3:6379> INCR counter:1
(integer) 2

C’est beaucoup plus simple, bien sûr, mais cela a un impact sur la latence et la charge du réseau, car toucher un nœud non leader crée un saut de réseau supplémentaire.

Changements de cluster

Lors de la configuration de notre cluster, nous avons en fait effectué trois opérations distinctes :

  1. Création du cluster sur un seul nœud.
  2. Ajout du deuxième nœud.
  3. Ajout du troisième nœud.

La configuration du cluster RedisRaft n’est pas statique et il est possible d’ajouter ou de supprimer des nœuds supplémentaires après la création du cluster et pendant qu’il est actif.

Par exemple, nous devrons peut-être remplacer notre troisième nœud. Tout d’abord, nous rejoignons un nouveau nœud qui va le remplacer. Notez que nous « ajoutons-puis-supprimons » plutôt que « supprimons-puis-ajoutons » pour éviter de laisser le cluster et nos précieuses données dans un état de redondance dégradé pendant la transition :

10.0.0.4:6379> RAFT.CLUSTER JOIN 10.0.0.1:6379
OK

Ensuite, nous recherchons l’ID qui a été attribué au hasard à notre troisième nœud :

redis-cli -h 10.0.0.1 --raw RAFT.INFO | grep 10.0.0.3
node2:id=1739451728,state=connected,voting=yes,addr=10.0.0.3,port=6379,
last_conn_secs=3537,conn_errors=0,conn_oks=1

Et puis on le supprime :

10.0.0.1:6379> RAFT.NODE REMOVE 1739451728
OK

État de la version de RedisRaft

Dans le cadre du travail de développement de RedisRaft, nous avons collaboré avec Kyle Kingsbury (alias Aphyr) pour analyser et tester RedisRaft en utilisant Jepsen, un cadre bien connu pour tester la sécurité et l’exactitude des systèmes distribués. Cette collaboration s’est traduite jusqu’à présent par cette analyse publiée.

Bien qu’encore en cours de développement, la plupart des fonctionnalités de base de RedisRaft sont en place. Nous travaillons actuellement sur une première version de prévisualisation, qui devrait être disponible dans quelques mois. Lorsqu’il sera généralement disponible, RedisRaft sera publié sous une double licence, soit GNU AGPLv3, soit Redis Source Available License (RSAL).

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *