data / redis
Premières commandes et types clé-valeur
Explication
Ce que vous allez apprendre
- Stocker et lire une valeur simple avec
SET/GET, le duo de commandes le plus basique - Utiliser les opérations atomiques sur les compteurs (
INCR,DECR,INCRBY) - Comprendre pourquoi
KEYSest interdit en production et ce qu'il faut utiliser à la place - Réduire les allers-retours réseau avec
MSET/MGETplutôt que des commandes répétées - Te repérer dans les bases logiques Redis et la commande
DBSIZE
Dans quel contexte ?
Une application affiche un compteur de likes sur chaque publication, mis à jour en temps réel par des milliers d'utilisateurs qui cliquent simultanément. Utiliser une transaction SQL classique pour chaque clic (lire la valeur, l'incrémenter, la réécrire) créerait des conflits de concurrence à gérer explicitement. INCR compteur:publication:42 fait tout ça en une seule opération atomique, sans qu'aucun clic ne puisse jamais en écraser un autre.
D'abord, le duo de commandes le plus simple qui existe
SET cle valeur stocke une valeur associée à une clé, GET cle la relit. C'est la brique de base de tout ce que Redis propose, et elle ressemble énormément à un simple dictionnaire Python ou un objet JavaScript — sauf que ce dictionnaire est partagé entre tous les processus qui s'y connectent, potentiellement sur des machines différentes.
Une fois cette base acquise, une famille de commandes se distingue par son atomicité
INCR, DECR, INCRBY modifient une valeur numérique de façon atomique : même si mille clients appellent INCR sur la même clé au même instant, Redis garantit que chaque appel s'exécute entièrement avant le suivant, sans jamais perdre un seul incrément. C'est une garantie beaucoup plus forte, et beaucoup plus simple à obtenir, qu'un read-modify-write manuel dans une base relationnelle sous forte concurrence.
Ensuite, un piège classique attend quiconque explore ses données pour la première fois
KEYS user:* semble être le moyen naturel de lister les clés qui correspondent à un motif. Le problème est qu'elle parcourt bloquant l'intégralité de l'espace de clés en une seule opération : sur une base de production avec des millions de clés, cette commande peut geler le serveur entier pendant plusieurs secondes, bloquant toutes les autres requêtes en attente.
| Commande | Comportement | Usage recommandé |
|---|---|---|
KEYS motif | Bloquante, parcourt tout d'un coup | Développement local uniquement, jamais en production |
SCAN curseur MATCH motif | Non bloquante, itère par petits morceaux | Toujours en production |
Il reste une optimisation réseau simple mais souvent négligée
Faire dix SET puis dix GET séparés implique vingt allers-retours réseau entre le client et le serveur Redis. MSET/MGET regroupent plusieurs opérations en une seule commande, réduisant la latence réseau cumulée — un gain particulièrement sensible dès que le client et le serveur ne sont pas sur la même machine.
Prérequis
Cette leçon suppose que Redis est installé et accessible (voir la leçon précédente) : toutes les commandes ici s'exécutent depuis redis-cli ou un client applicatif déjà connecté.
Piège fréquent
Exécuter SCAN 0 MATCH user:* COUNT 100 une seule fois et croire avoir parcouru toute la base est une erreur fréquente : SCAN retourne un curseur qu'il faut réutiliser en boucle jusqu'à ce qu'il revienne à 0, signe que l'itération complète est terminée. Une seule invocation ne garantit jamais d'avoir vu toutes les clés correspondantes.
Bonne pratique
Ne jamais exécuter FLUSHDB ou FLUSHALL sans triple vérification de l'environnement connecté : ces commandes vident intégralement une base (ou toutes les bases) sans confirmation, et une erreur de terminal connecté à la mauvaise instance peut effacer des données de production en une fraction de seconde.
Maintenant que tu maîtrises les strings et leurs compteurs, la prochaine leçon introduit les hashes, une structure bien plus adaptée pour représenter un objet structuré comme un utilisateur avec plusieurs champs.
Commandes & code
Premières commandes et types clé-valeur
# Chaînes de caractères (strings) : le type le plus simple
SET user:1:name "Alice"
GET user:1:name # -> "Alice"
SET compteur 10
INCR compteur # -> 11 (incrément atomique)
INCRBY compteur 5 # -> 16
DECR compteur # -> 15
APPEND user:1:name " Dupont" # concatène à la fin de la valeur
# Existence, suppression, type
EXISTS user:1:name # -> 1 (existe) ou 0
DEL user:1:name # supprime une ou plusieurs clés
TYPE compteur # -> "string"
# Explorer l'espace de clés (à éviter en production sur gros volumes)
KEYS user:* # bloque le serveur sur une grosse base : usage dev uniquement
SCAN 0 MATCH user:* COUNT 100 # itération non bloquante, curseur retourné
# Plusieurs clés en une commande (moins d'aller-retours réseau)
MSET a 1 b 2 c 3
MGET a b c # -> [1, 2, 3]
# Renommer, dupliquer
RENAME compteur total
COPY total total_backup
# Durée de vie de la base
DBSIZE # nombre de clés dans la base courante
FLUSHDB # vide la base courante (danger en prod !)
SELECT 1 # bascule sur la base logique n°1 (0 à 15 par défaut)Résumé
- Les strings supportent des opérations atomiques (
INCR,APPEND) très utiles pour compteurs et flags. KEYSest bloquant et interdit en production ; toujours préférerSCANpour parcourir les clés.MSET/MGETréduisent le nombre d'allers-retours réseau par rapport à desSET/GETrépétés.
Exercices pratiques
Mission : sécuriser un compteur de likes sous forte concurrence
Objectif : Utiliser les commandes atomiques et l'exploration sûre des clés pour fiabiliser un compteur de likes à fort trafic, sans jamais utiliser une commande interdite en production.
Contexte
Une publication devient virale et des milliers d'utilisateurs cliquent "like" en quelques secondes. Le développeur a d'abord codé le compteur en lisant puis réécrivant la valeur côté application, et le total affiché est visiblement inférieur au nombre réel de clics. Tu dois corriger ce bug de concurrence et nettoyer proprement des clés de test, sans jamais utiliser une commande dangereuse en production.