[Redis](http://redis.io/) est une base de donnée de type clef-valeur. On la
range dans la grande famille plutôt hétérogène des bases **NoSQL**<!-- more -->qui, pour
rappel, signifie plutôt *Not Only SQL* que *No SQL*. Ceci dit, dans le cas de
Redis, on est vraiment dans le *No SQL at all*. La base permet de stocker par
clef des chaînes, des listes de chaînes, des *hashtable*. Elle permet de
stocker des valeurs avec une date d'expiration au delà de laquelle la donnée
disparaît. Idéal pour gérer des données cache et c'est d'ailleurs
l'utilisation principale de Redis. On peut aussi facilement implémenter
producteur / consommateur entre plusieurs clients d'une base Redis. L'ensemble
des commandes supportées par Redis est parfaitement documenté
[ici](http://redis.io/commands).
La base est orientée performance et évolutivité :
- écrite en C, facilement portable car le code n'a pas de dépendance particulière,
- stockage des données en mémoire avec différents mécanismes optionnels pour conserver une copie sur disque,
- réplication possible d'une base maître vers un grand nombre de bases esclaves. On peut écrire dans la base maître et seulement lire dans les bases esclaves.
Ce qui fait (aussi) le succès de Redis, c'est que le coeur est en C et qu'il
existe des [clients pour la plupart des langages](http://redis.io/clients).
Pour l'instant, j'ai utilisé Jedis pour JAVA et redis-py pour Python. Enfin,
un client en ligne de commande permet d'interagir avec la base sans écrire de
code.
La dernière version stable est Redis 2.8.8. Quant à la version 3.0 à venir,
encore en phase de bêta, elle embarque des fonctionnalités de répartition des
données dans des configuration de type cluster, ce qu'on appelle en langue de
Shakespeare le **sharding**. Dans le futur, elle embarquera aussi des
fonctionnalités de Haute Disponibilité pour basculer les données lorsqu'un
noeud du cluster s'écroule.
En attendant ce futur, la version actuelle apporte une solution de cluster
actif/passif basée sur la réplication maître / esclave surveillée par des
sentinelles chargées de promouvoir un Redis esclave en maître en cas de
défaillance.
Je me suis intéressé à monter une configuration avec seulement 2 machines sous
Debian qui peut fonctionner si l'une des machines tombe et automatiquement
réintégrer le cluster quand elle redevient opérationnelle, sans impact pour
les clients Redis. Ce n'est pas si trivial et je me suis heurté à quelques
difficultés avant d'arriver à une configuration opérationnelle.
Comme dans la plupart des architectures clusterisées, un quorum (nombre
minimal de votants) est nécessaire pour élire un nouveau maître. La valeur
minimum possible est 1, signifiant qu'une sentinelle a besoin qu'au moins 1
autre sentinelle soit d'accord avec elle pour déclarer qu'un Redis maître est
défaillant. Il faut au minimum 2 sentinelles opérationnelles quel que soit
l'état du cluster donc sur chaque machine on va installer un Redis et 2
sentinelles.
Au début de mes expérimentations, j'attribuais un port différent aux
sentinelles pour les exécuter sans conflit sur la même machine mais j'avais
des problème d'indécision des sentinelles pour élire un nouveau noeud. Je
crois que toutes les sentinelles ne communiquaient pas. La situation s'est
arrangée quand j'ai configuré toutes mes sentinelles pour écouter sur le port
standard 26379. Pour que ce soit possible, j'ai attaché mes sentinelles à des
adresses IP différentes en déclarant une sous-interface sur chaque machine.
Je suis le projet Redis depuis un bout de temps avec intérêt car il offre beaucoup d'applications possibles dans des architectures distribuées multi-langages.
