Redis
| Fiche express | |
|---|---|
| Type | Base de données clé/valeur en mémoire (NoSQL) |
| Port par défaut | 6379/tcp |
| Persistance | RDB (snapshots) · AOF (journal d'écriture) |
| Licence | BSD 3-clauses (à vérifier selon la version — licence modifiée sur certaines éditions récentes) |
| Voir aussi | Memcached · MongoDB |
Redis (REmote DIctionary Server) est un système de gestion de données NoSQL de type clé/valeur, s'exécutant principalement en mémoire vive pour offrir des temps de réponse très bas (généralement sous la milliseconde). Contrairement à un cache pur, Redis propose des structures de données riches et des mécanismes de persistance sur disque, ce qui lui permet de servir aussi bien de cache éphémère que de base de données à part entière pour certains usages.
Structures de données
Redis ne se limite pas à des paires clé/valeur simples ; chaque clé peut pointer vers un type de structure différent, manipulable via des commandes dédiées :
- String — chaîne binaire (texte, entier, JSON sérialisé...), la structure la plus simple.
- Hash — table de champs/valeurs associée à une clé, pratique pour représenter un objet
(ex. un profil utilisateur) sans le sérialiser entièrement.
- List — liste chaînée ordonnée, utilisable comme file d'attente (
LPUSH/
RPOP) ou pile.
- Set — ensemble non ordonné de valeurs uniques, avec opérations d'union/intersection/
différence entre sets.
- Sorted set (ZSet) — ensemble où chaque membre porte un score numérique, permettant des
classements (leaderboards), des files à priorité ou des requêtes par plage de score.
D'autres structures existent (bitmaps, HyperLogLog pour le comptage approximatif de cardinalité, streams pour des flux d'événements type log) (à vérifier selon la version).
Persistance
Bien que les données vivent en mémoire, Redis propose deux mécanismes de persistance sur disque, combinables :
- RDB (Redis Database) — snapshot binaire complet du jeu de données à intervalles
configurables (ex. « toutes les 5 minutes si au moins 100 clés ont changé »). Reprise rapide au redémarrage, mais perte potentielle des écritures survenues depuis le dernier snapshot.
- AOF (Append Only File) — journal de toutes les commandes d'écriture, rejoué au démarrage
pour reconstruire l'état. Plus durable (perte de données minimale selon la politique de
fsync), mais fichier plus volumineux et reconstruction plus lente qu'un RDB.
Il est possible de désactiver toute persistance pour un usage purement cache, ou de combiner RDB et AOF pour un compromis robustesse/performance (à vérifier selon la version — le comportement par défaut a évolué au fil des versions de Redis).
Cas d'usage
Cache applicatif
Usage le plus répandu : mettre en mémoire le résultat de requêtes coûteuses ou de calculs
répétitifs pour soulager la base de données principale, avec expiration automatique des clés
(TTL) plutôt qu'une invalidation manuelle.
Gestion de sessions
Les structures Hash et l'expiration native en font un support courant pour stocker des sessions utilisateur dans une architecture web à plusieurs instances applicatives, où une session en mémoire locale à un seul serveur ne conviendrait pas.
Files de messages / Pub-Sub
Redis intègre un mécanisme de publication/abonnement (PUBLISH / SUBSCRIBE)
permettant une diffusion de messages en temps réel entre producteurs et consommateurs. Les
structures List (comme file FIFO simple) ou Stream (journal persistant et rejouable) permettent
également de bâtir des files de messages plus élaborées que le pub/sub basique, qui ne conserve
aucun historique pour les abonnés déconnectés.
Positionnement face aux alternatives
Face à Memcached
Memcached couvre un périmètre plus restreint : cache clé/valeur en mémoire pur, sans persistance ni structures de données avancées. Redis est généralement préféré dès que le besoin dépasse le simple cache éphémère (structures riches, pub/sub, persistance, réplication), tandis que Memcached reste apprécié pour sa simplicité et son modèle multi-thread natif sur des charges de cache pur à très haut débit.
Face à MongoDB
MongoDB est un SGBD orienté documents, pensé pour stocker et interroger un volume important de données structurées de façon persistante sur disque, avec un langage de requête riche. Redis reste centré sur des accès en mémoire par clé, avec des structures plus simples et une persistance pensée davantage comme un filet de sécurité que comme un mode de stockage primaire. Les deux sont parfois utilisés ensemble : MongoDB (ou un SGBD relationnel) comme source de vérité, Redis comme couche de cache ou de données transitoires devant elle.