data / redis

Pourquoi Redis et installation

Leçon 11 exercice

Explication

Un peu d'histoire

Redis est créé en 2009 par Salvatore Sanfilippo, un développeur italien connu sous le pseudonyme "antirez", pour résoudre un problème très concret : améliorer les performances de son propre site web, un compteur de visites en temps réel (retwis, un clone de Twitter). Insatisfait des bases de données existantes pour ce cas d'usage, il écrit Redis (REmote DIctionary Server) en C, en gardant toutes les données en mémoire vive pour des temps de réponse de l'ordre de la microseconde. Le projet est rapidement adopté par VMware puis Pivotal, qui emploient Sanfilippo pour le développer à plein temps. Depuis 2020, le projet est piloté par Redis Ltd. (anciennement Redis Labs) ; un changement de licence en 2024 a mené une partie de la communauté à créer un fork ouvert, Valkey, sous l'égide de la Linux Foundation — mais Redis reste le nom et l'implémentation de référence pour la quasi-totalité des usages en production.

Pourquoi apprendre Redis aujourd'hui

Redis est aujourd'hui l'une des bases de données les plus déployées au monde, utilisée en production par Twitter, GitHub, Snapchat, Stack Overflow ou Uber, notamment pour le cache, les sessions utilisateur, les files d'attente de jobs et les compteurs en temps réel. Sur le marché de l'emploi, savoir concevoir un cache efficace, éviter un cache stampede, ou dimensionner une politique d'éviction mémoire, sont des compétences directement recherchées pour tout poste backend ou DevOps où la performance et la scalabilité comptent — ce qui concerne la quasi-totalité des applications à trafic significatif.

Ce que vous allez apprendre

Comprendre ce qui distingue fondamentalement Redis d'une base de données disque classique
Installer Redis localement (paquet système, Docker) et t'y connecter avec redis-cli
Identifier les grandes familles d'usages où Redis excelle (cache, sessions, files, compteurs)
Localiser et lire le fichier de configuration principal de Redis
Te repérer dans la suite du cours, qui construit progressivement vers le clustering et la performance experte

Dans quel contexte ?

Une application web affiche un compteur de vues en temps réel sur chaque article, mis à jour à chaque chargement de page par des milliers de visiteurs simultanés. Faire un UPDATE sur une base de données relationnelle classique à chaque vue créerait une contention énorme sur cette ligne précise de la table. Un simple INCR compteur:article:42 dans Redis résout ce problème en une opération atomique et quasi instantanée, sans jamais toucher la base de données principale pour cet usage précis.

D'abord, la différence la plus fondamentale : tout vit en mémoire

Contrairement à PostgreSQL ou MySQL, qui écrivent leurs données sur disque en continu, Redis garde l'intégralité de son jeu de données en RAM. Cette différence explique à elle seule l'écart de performance : une lecture RAM prend de l'ordre de la microseconde, quand une lecture disque classique (même sur SSD) reste plusieurs ordres de grandeur plus lente.

Une fois cette différence comprise, un compromis devient évident

Tout ce qui vit en RAM est limité par la RAM disponible sur la machine, et une base de données en mémoire n'a pas vocation à remplacer une base relationnelle pour stocker des téraoctets de données historiques. Redis est pensé pour des volumes de données qui tiennent raisonnablement en mémoire, ou pour des données dont la durée de vie est volontairement limitée (un cache, une session).

Cas d'usage typique	Pourquoi Redis convient
Cache applicatif	Lecture ultra-rapide, TTL natif pour l'expiration automatique
Sessions utilisateur	Accès fréquent, données de taille modeste, expiration naturelle
Files d'attente de jobs	Structures natives (listes, streams) adaptées au pattern producteur/consommateur
Compteurs et leaderboards	Opérations atomiques (`INCR`), sorted sets triés par score

Ensuite, une seconde différence structurelle mérite d'être soulignée

Redis n'est pas qu'un simple stockage clé-valeur de chaînes de caractères : il expose des structures de données riches et natives — listes, sets, hashes, sorted sets — chacune avec ses propres opérations optimisées. C'est ce qui distingue Redis d'un simple cache mémoire basique : chaque structure est un outil taillé pour une classe de problèmes précise, explorée leçon après leçon dans ce cours.

Prérequis

Aucune connaissance de Redis n'est nécessaire pour cette leçon, mais une aisance de base avec le terminal (ou Docker) facilitera grandement l'installation et les premiers essais de commandes.

Bonne pratique

Pour du développement local, préfère Docker (docker run -d -p 6379:6379 redis:7-alpine) à une installation système complète : c'est plus rapide à mettre en place, plus facile à réinitialiser complètement (docker rm), et garantit une version identique entre tous les membres d'une équipe.

Piège fréquent

Un débutant confond parfois "rapide" avec "durable par défaut" : sans configuration explicite de persistance (sujet d'une leçon dédiée plus loin), les données de Redis peuvent être perdues intégralement en cas de redémarrage ou de crash du serveur. Redis n'est un bon choix de stockage principal que si cette contrainte est comprise et gérée.

Maintenant que Redis tourne sur ta machine, la prochaine leçon aborde les toutes premières commandes : les strings, le type de données le plus simple, avec ses opérations atomiques comme INCR.

Commandes & code

Pourquoi Redis et installation

Redis (REmote DIctionary Server) est une base de données en mémoire, clé-valeur, ultra rapide.

# Installation Linux (Debian/Ubuntu)
sudo apt update
sudo apt install redis-server -y
redis-server --version                      # vérifie l'installation

# Installation via Docker (recommandé pour dev)
docker run -d --name redis-dev -p 6379:6379 redis:7-alpine
docker exec -it redis-dev redis-cli          # ouvre un client dans le conteneur

# macOS
brew install redis
brew services start redis

# Démarrer/arrêter le service (Linux systemd)
sudo systemctl start redis
sudo systemctl enable redis                 # démarrage automatique au boot
sudo systemctl status redis

# Se connecter avec le client officiel
redis-cli
redis-cli -h 127.0.0.1 -p 6379 -a monmotdepasse
redis-cli PING                               # doit répondre PONG

# Fichier de configuration principal
cat /etc/redis/redis.conf | grep -v "^#" | grep -v "^$"   # config active, sans commentaires/lignes vides

# Pourquoi Redis plutôt qu'une base disque classique ?
# - Toutes les données vivent en RAM  -> latence sub-milliseconde
# - Structures de données riches (pas juste string/JSON) : listes, sets, hashes, sorted sets...
# - Usages typiques : cache, sessions, files d'attente, compteurs, leaderboards, pub/sub

Résumé

Redis stocke les données en mémoire : accès très rapide, mais volume limité par la RAM disponible.
redis-server lance le serveur, redis-cli est le client en ligne de commande.
Docker est la façon la plus simple de démarrer un Redis de développement.

Exercices pratiques

1 disponible

Mission : relancer un Redis de développement après une perte de données suspecte

Objectif : Diagnostiquer une perte de données après un redémarrage Docker, remettre en service un Redis de développement, et savoir situer Redis face à une base disque classique.

Contexte

Un collègue a supprimé puis recréé le conteneur redis-dev de l'équipe pour "nettoyer l'environnement" avant une démo client. Toutes les données de test (paniers, compteurs de vues) ont disparu, et il pense avoir cassé quelque chose. Tu dois remettre en service un Redis de développement fonctionnel et lui expliquer ce qui s'est réellement passé, sans jamais avoir touché à la configuration de persistance.

Résoudre l’exercice →