Débuter avec Redis

Qu’est-ce que Redis ?

Redis est un stockage en mémoire de structures de données simple (chaîne de caractère, hash, liste, ensemble, bitmap…).
Il a la particularité de travailler seulement en mémoire ce qui lui confère de très bonnes performances.
Il peut toutefois persister ses données sur disque.
Il supporte aussi des fonctionnalités avancées comme :

• Transactions,
• Mécanismes de publication et d’inscription,
• Le scripting Lua,
• Gestion automatique du TTL sur les clefs,
• Haute disponibilité,
• Clustering.

Modes de fonctionnement

Fonctionnement en mémoire uniquement

Dans ce mode, Redis utilise seulement la mémoire. Si le serveur est arrêté, les données disparaissent.

Fonctionnement en mémoire avec persistance régulière sur le disque

Dans ce cas, Redis qui fonctionne avec toutes ses données en mémoire, va les enregistrer régulièrement (suivant la configuration) sur le disque.
Si le serveur est arrêté, les données ajoutées ou modifiées depuis la dernière persistance sur disque seront perdues.
Lorsque Redis reçoit une nouvelle donnée à insérer, à modifier ou à supprimer, il incrémente un compteur.
Suivant le nombre d’opérations d’écriture et le temps, Redis va persister sa mémoire sur disque (dans un fichier RDB).
C’est le rôle de la configuration suivante :

save 900 1
save 300 10
save 60 10000

La première ligne indique de sauvegarder si au moins une clef a été modifiée dans les dernières 15 minutes.
La seconde, de sauvegarder si au moins dix clefs ont été mises à jour (ajoutées, supprimées, modifiées) dans les 5 minutes.
La dernière, de sauvegarder au bout d’une minute si 10000 clefs ont été mises à jour.

Fonctionnement en mémoire avec persistance régulière sur le disque et enregistrement des commandes

Afin de minimiser encore plus la perte de données, sans pour autant sacrifier les performances, Redis va enregistrer les commandes qu’il reçoit dans un fichier à part (AOF – Append Only File), en mode append.
Ainsi, si le serveur est arrêté, au redémarrage de Redis, ce dernier réexécutera les commandes afin de retrouver les données dans l’état au moment de l’arrêt.
Le fichier AOF sera régulièrement réinitialisé lorsque sa taille deviendra trop importante (plus de détail dans l’article Redis persistence demystified).

Les différentes architectures

Architecture standalone

Il s’agit d’un seul Redis. Si le serveur est coupé, plus d’accès aux données.

Architecture master/replica

Dans ce mode, l’application lit et écrit sur le master.
Des sentinels (au moins 3), vérifient l’état du master. Si le master est défaillant, elles élisent un nouveau master.
Le master se réplique régulièrement sur les slaves. Cela signifie que si le master est défaillant avant qu’il ait répliqué ses données, celles reçues depuis la dernière réplication seront perdues.
Il est toutefois possible de forcer une réplication synchrone au risque de dégrader les performances.

L’architecture cluster

En mode cluster, Redis va répartir les données sur les différents noeuds master (sharding).
Cette répartition se fait via un hash CRC16 modulo 16384.
16384 est le nombre de slots disponibles sur le cluster (valeur fixe).
Pourquoi 16384 ? Salvatore Sanfilippo y répond dans le ticket GitHub 2576.
Si un noeud master devient défaillant, c’est un noeud slave qui lui est associé qui prend le relais (comme dans le cas du master/replica).
À la différence de l’architecture master/replica, ce sont les noeuds (absence de sentinel) entre eux qui élisent le nouveau master.
Ces noeuds communiquent entre eux par le port d’écoute de commande + 10000 (valeur fixe).

Passons à la pratique

Installation

Afin de faciliter l’exercice, nous allons utiliser l’image officielle Docker.

$ docker pull redis:5.0

Redis en standalone

Maintenant que nous avons l’image Docker, lancez le container :
$ docker container run –rm -it redis:5.0 /bin/bash
Pour l’exercice, nous allons lancer directement Redis avec les paramètres par défaut (sans fichier de configuration) :

root@c2b1c8a7a9df:/# cd /tmp/
root@c2b1c8a7a9df:/tmp# redis-server &
18:C 02 Jan 2019 13:27:09.215 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
18:C 02 Jan 2019 13:27:09.215 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=18, just started
…
18:M 02 Jan 2019 13:27:09.217 * DB loaded from disk: 0.000 seconds
18:M 02 Jan 2019 13:27:09.217 * Ready to accept connections

Le port par défaut est 6379.
Testons simplement la connexion et le bon fonctionnement de redis.
On lance redis-cli sans paramètres (il prend la configuration par défaut) :

root@c2b1c8a7a9df:/tmp# redis-cli
127.0.0.1:6379>

et on crée une clef :

127.0.0.1:6379> set toto « coucou ca va »
OK
127.0.0.1:6379> keys *
1) « toto »
127.0.0.1:6379> exit

ensuite on arrête Redis :

root@c2b1c8a7a9df:/tmp# kill 18
18:signal-handler (1546436001) Received SIGTERM scheduling shutdown…
root@c2b1c8a7a9df:/tmp# 18:M 02 Jan 2019 13:33:21.739 # User requested shutdown…
18:M 02 Jan 2019 13:33:21.739 * Saving the final RDB snapshot before exiting.
18:M 02 Jan 2019 13:33:21.749 * DB saved on disk
18:M 02 Jan 2019 13:33:21.749 # Redis is now ready to exit, bye bye…

maintenant, on liste les fichiers dans le répertoire/tmp :

root@c2b1c8a7a9df:/tmp# ls
dump.rdb

On constate que nos données ont bien été sauvegardées dans un fichier. Mais uniquement car nous l’avons arrêté gracieusement avec le signal SIGTERM.
Redémarrons Redis, listons les clefs avec keys * . Insérons une nouvelle clef :

127.0.0.1:6379> keys *
1) « toto »
127.0.0.1:6379> set titi « BASIC is never die! »
OK
127.0.0.1:6379> keys *
1) « titi »
2) « toto »
127.0.0.1:6379>

Si on refait l’exercice avec une kill -s kill <pid>.
On relance le serveur Redis :

$ redis-server &
[1] 30
root@c2b1c8a7a9df:/tmp# 30:C 02 Jan 2019 13:47:00.716 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
…
30:M 02 Jan 2019 13:47:00.717 * Ready to accept connections
$ redis-cli
127.0.0.1:6379> keys *
1) « toto »
127.0.0.1:6379>

On constate que la nouvelle donnée a disparu.
Rendez-vous sur le Github Zenika pour continuer les exercices.
Merci à Julien Landuré et Pierre-Yves Aillet pour leur relecture.