Commandes Redis de base avec exemples pratiques : guide dimplémentation

Introduction

Ce guide rassemble les Redis basic commands que les opérateurs et développeurs utilisent au quotidien, avec des Redis examples sûrs à copier-coller. Vous apprendrez à poser et faire expirer des clés, gérer des compteurs, manipuler des hashes, listes, sets et sorted sets, itérer en sécurité avec SCAN, exécuter de petites transactions, utiliser pub/sub et vérifier la santé dune instance. Tous les exemples emploient un espace de noms de test ab app: test:* bb pour ne pas polluer vos données réelles. Que vous lanciez redis-cli via Docker ou que vous codiez en Node.js, ces recettes restent valables.

Aperçu du flux de travail

Utilisez cette séquence pour des résultats fiables :

1. Connexion et sanity check : PING et INFO.
2. Chaeenes et expirations : SET/GET avec EX/TTL pour les données de type cache.
3. Compteurs : INCR/DECR avec TTL pour limites de débit et métriques.
4. Collections : commandes HASH, LIST, SET, ZSET pour les structures.
5. Itération sûre : SCAN au lieu de KEYS.
6. Transactions : WATCH, MULTI, EXEC pour des mises à jour compare-and-swap.
7. Pub/Sub : diffusion rapide de messages.
8. Observabilité : INFO, MEMORY, SLOWLOG pour la santé et loptimisation.

Clés et chaeenes (Strings)

Connexion et ping :

$ redis-cli PING
PONG

Définir avec expiration et lire :

$ redis-cli SET app: test: greeting "hello" EX 60 NX
OK
$ redis-cli GET app: test: greeting
"hello"
$ redis-cli TTL app: test: greeting
(integer) 57

Notes :

• EX définit le time-to-live en secondes. NX évite décraser une clé existante. Utilisez XX pour exiger lexistence.
• Isolez les exemples avec des espaces de noms du type app: test:*.

Mettre à jour la valeur et vérifier lexistence :

$ redis-cli SET app: test: greeting "hello, world" XX
OK
$ redis-cli EXISTS app: test: greeting
(integer) 1

Obtenir et changer le TTL en une seule opération :

$ redis-cli GETEX app: test: greeting EX 120
"hello, world"
$ redis-cli TTL app: test: greeting
(integer) 119

Supprimer lexpiration si besoin :

$ redis-cli PERSIST app: test: greeting
(integer) 1

Supprimer avec précaution (ciblez lespace de test) :

$ redis-cli DEL app: test: greeting
(integer) 1

Opérations multi-clés :

$ redis-cli MSET app: test: a 1 app: test: b 2
OK
$ redis-cli MGET app: test: a app: test: b
1) "1"
2) "2"

Compteurs et limites de débit

Initialiser avec TTL puis incrémenter de manière atomique :

$ redis-cli SET app: test: login: count 0 EX 3600 NX
OK
$ redis-cli INCR app: test: login: count
(integer) 1
$ redis-cli INCRBY app: test: login: count 5
(integer) 6
$ redis-cli TTL app: test: login: count
(integer) 3597

Patron : assurez-vous que le TTL persiste pour les compteurs en le posant à la création (SET ... NX EX). Pour des fenêtres glissantes, utilisez INCR avec des clés horodatées par bucket.

Exemple simple de rate limit :

1. Incrémentez et récupérez le TTL restant de la fenêtre.

$ redis-cli INCR app: test: ratelimit: u123
(integer) 1
$ redis-cli TTL app: test: ratelimit: u123
(integer) -2

1. Si TTL vaut -2 (pas de TTL), appliquez-le maintenant pour une fenêtre de 60 s.

$ redis-cli EXPIRE app: test: ratelimit: u123 60
(integer) 1

Hashes

Les hashes stockent efficacement des objets légers :

$ redis-cli HSET app: test: user:1001 name "Ada" plan "pro" visits 1
(integer) 3
$ redis-cli HGET app: test: user:1001 name
"Ada"
$ redis-cli HMGET app: test: user:1001 name plan visits
1) "Ada"
2) "pro"
3) "1"
$ redis-cli HINCRBY app: test: user:1001 visits 1
(integer) 2

Prudence : HGETALL peut être coûteux sur de très gros hashes. Préférez HMGET pour des champs ciblés.

Listes

Idéales pour des files et journaux ordonnés.

File FIFO avec LPUSH + RPOP :

$ redis-cli DEL app: test: queue: emails
(integer) 1
$ redis-cli LPUSH app: test: queue: emails id-1 id-2 id-3
(integer) 3
$ redis-cli RPOP app: test: queue: emails
"id-1"
$ redis-cli RPOP app: test: queue: emails
"id-2"

Pop bloquant (attend un élément, time-out 5 s) :

$ redis-cli BRPOP app: test: queue: emails 5
1) "app: test: queue: emails"
2) "id-3"

Astuce : stockez de petits payloads (IDs) et récupérez les données complètes depuis un hash ou une base.

Sets et sorted sets

Les sets stockent des éléments uniques, parfaits pour lappartenance et la déduplication :

$ redis-cli SADD app: test: room: active u1 u2 u2 u3
(integer) 3
$ redis-cli SISMEMBER app: test: room: active u2
(integer) 1
$ redis-cli SMEMBERS app: test: room: active
1) "u1"
2) "u2"
3) "u3"
$ redis-cli SREM app: test: room: active u1
(integer) 1

Les sorted sets classent par score :

$ redis-cli ZADD app: test: scores 100 u1 250 u2 180 u3
(integer) 3
$ redis-cli ZRANGE app: test: scores 0 -1 WITHSCORES
1) "u1"
2) "100"
3) "u3"
4) "180"
5) "u2"
6) "250"
$ redis-cli ZREVRANGE app: test: scores 0 1 WITHSCORES
1) "u2"
2) "250"
3) "u3"
4) "180"
$ redis-cli ZINCRBY app: test: scores 25 u1
"125"

Parcours sûr des données

Évitez KEYS en production car la commande peut bloquer le serveur sur de grands jeux de données. Préférez SCAN, incrémental et non bloquant.

Patron SCAN de base :

$ redis-cli SCAN 0 MATCH app: test:* COUNT 100
1) "cursor"
2) 1) "app: test: a"
   2) "app: test: b"
   3) "app: test: user:1001"

Bouclez jusquà ce que le curseur renvoie 0.

Variantes spécifiques aux collections :

• HSCAN key cursor [MATCH pattern] [COUNT n]
• SSCAN key cursor [MATCH pattern] [COUNT n]
• ZSCAN key cursor [MATCH pattern] [COUNT n]

Transactions

Utilisez WATCH + MULTI + EXEC pour un verrouillage optimiste.

Exemple : débiter si le solde est suffisant.

1. Amorcer les données :

$ redis-cli SET app: test: balance: u1 100
OK

1. Démarrer une mise à jour contrôlée :

$ redis-cli WATCH app: test: balance: u1
OK
$ redis-cli GET app: test: balance: u1
"100"
# Supposons que vous débitiez 30 si balance >= 30
$ redis-cli MULTI
OK
$ redis-cli DECRBY app: test: balance: u1 30
QUEUED
$ redis-cli EXEC
1) (integer) 70

Si une autre session modifie la clé après WATCH, EXEC renvoie nil et vous devez relancer la séquence.

Bases du Pub/Sub

Le Publish/Subscribe sert à des messages éphémères (non persistés).

Terminal A (abonné) :

$ redis-cli SUBSCRIBE app: test: events
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "app: test: events"
3) (integer) 1

Terminal B (publisher) :

$ redis-cli PUBLISH app: test: events "hello subscribers"
(integer) 1

Sortie du terminal A :

1) "message"
2) "app: test: events"
3) "hello subscribers"

Note : les messages ne sont pas conservés ; les abonnés tardifs ne verront pas lhistorique.

Observabilité et santé

Contrôles rapides :

• PING pour confirmer laccessibilité.
• INFO pour le serveur, la mémoire, les clients et les stats de keyspace.

$ redis-cli INFO server | head -n 5
# Server
redis_version:7.0.x
os:...

Utilisation mémoire dune clé :

$ redis-cli MEMORY USAGE app: test: user:1001
(integer) 112

Trouver des commandes lentes :

$ redis-cli SLOWLOG GET 10
1) 1) (integer) 42
   2) (integer) 1710000000
   3) (integer) 15000
   4) 1) "ZRANGE"
      2) "big: zset"
      3) "0"
      4) "1000"

Débogage du trafic en direct :

• MONITOR streame chaque commande. Utilisez-le avec parcimonie.

$ redis-cli MONITOR
OK
# Press Ctrl-C to quit when finished.

Plan pilote local

Gardez le premier déploiement étroit, mesurable et facile à inspecter. Idéal pour une instance Redis lancée en local ou dans Docker.

Portée :

• Nommez toutes les clés de test sous app: test:*.
• Nb9exercez que ces commandes : SET/GET/EXPIRE/TTL, INCR, HSET/HGET, LPUSH/RPOP, SADD/SISMEMBER, ZADD/ZRANGE, SCAN, INFO.

Étapes :

1. Sanity check : PING et INFO memory ; relevez used_memory et les stats de keyspace.
2. Exécutez exactement les exemples de ce guide.
3. Vérifiez : MGET des valeurs, TTLs, comptage via SCAN et MEMORY USAGE sur quelques clés.
4. Nettoyez : DEL uniquement les clés sous app: test:*.
5. Comparez INFO keyspace et mémoire avant/après pour écarter toute clé orpheline.

Critères de réussite :

• Toutes les commandes renvoient les valeurs attendues.
• Aucune clé persistante après le nettoyage (SCAN app: test:* ne renvoie rien).
• Aucun événement notable dans SLOWLOG pendant le pilote.

Conclusion

Vous disposez dun ab Redis cheat sheet bb opérationnel pour vos Redis operations quotidiennes : création sûre de clés avec expiration, compteurs atomiques, hashes objet, files avec listes, ensembles uniques et triés, itération non bloquante avec SCAN, mini-transactions, pub/sub et vérifications de santé essentielles. Conservez un espace de noms de démo, préférez SCAN à KEYS, et surveillez INFO, MEMORY et SLOWLOG pendant vos essais. Démarrez par le pilote local, validez, puis élargissez aux besoins de votre application (Node.js, Docker, caching, monitoring ou performance tuning compris).