## Introduction

Ce guide couvre les commandes Redis que les opérateurs et les développeurs utilisent au quotidien : définition de clés avec expiration, compteurs atomiques, hachages pour les données d'objets, listes pour les files d'attente, ensembles pour l'appartenance, ensembles triés pour les classements, itération sécurisée avec SCAN, transactions optimistes, messagerie pub/sub et vérifications de santé essentielles. Chaque exemple utilise l'espace de noms app:test:* afin que vous puissiez les exécuter sur une vraie instance sans toucher aux données de production.

## Aperçu du flux de travail

Suivez cette séquence pour obtenir des résultats fiables et reproductibles :

- Connexion et vérification initiale — PING et INFO confirment l'accessibilité et les métriques de base.

- Chaînes et expirations — SET / GET avec EX / TTL pour les données de type cache.

- Compteurs — INCR / DECR avec TTL pour les limites de taux et les métriques.

- Collections — commandes HASH , LIST , SET , ZSET pour les données structurées.

- Itération sécurisée — SCAN au lieu de KEYS pour éviter les blocages.

- Transactions — WATCH , MULTI , EXEC pour les mises à jour compare-and-swap.

- Pub/Sub — diffusion rapide de messages pour des événements éphémères.

- Observabilité — INFO , MEMORY , SLOWLOG pour la santé et l'optimisation.

## Clés et chaînes

### Connexion et ping

redis-cli PING 
 Résultat attendu : PONG

### Définir avec expiration et récupérer

redis-cli SET app:test:greeting "hello" EX 60 NX
redis-cli GET app:test:greeting
redis-cli TTL app:test:greeting 
 Notes :

- EX définit la durée de vie en secondes. NX évite d'écraser une clé existante ; utilisez XX pour exiger l'existence.

- Les espaces de noms comme app:test:* isolent les exemples des données réelles.

### Mettre à jour la valeur et vérifier l'existence

redis-cli SET app:test:greeting "hello, world" XX
redis-cli EXISTS app:test:greeting 

### Récupérer et modifier le TTL en une seule étape

 redis-cli GETEX app:test:greeting EX 120
redis-cli TTL app:test:greeting 

### Supprimer l'expiration si nécessaire

 redis-cli PERSIST app:test:greeting 

### Supprimer avec précaution (cibler uniquement les espaces de noms de test)

 redis-cli DEL app:test:greeting 

### Opérations multi-clés

 redis-cli MSET app:test:a 1 app:test:b 2
redis-cli MGET app:test:a app:test:b 

## Compteurs et limites de taux

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

 redis-cli SET app:test:login:count 0 EX 3600 NX
redis-cli INCR app:test:login:count
redis-cli INCRBY app:test:login:count 5
redis-cli TTL app:test:login:count 
 Modèle : Assurez-vous que le TTL persiste pour les compteurs en le définissant lors de la première création de la clé ( SET ... NX EX ). Pour les fenêtres glissantes, utilisez INCR avec des clés horodatées séparées par compartiment de fenêtre (ex. : ratelimit:u123:2024011514 pour 14:00 UTC).

### Vérification simple de limite de taux (fenêtre fixe de 60 secondes)

redis-cli INCR app:test:ratelimit:u123
redis-cli TTL app:test:ratelimit:u123 
 Si TTL renvoie -2 (la clé n'a pas d'expiration), appliquez-la maintenant pour une fenêtre de 60 secondes :

redis-cli EXPIRE app:test:ratelimit:u123 60 
 Puis vérifiez le compte par rapport à votre limite (ex. : 10 requêtes/minute) :

redis-cli GET app:test:ratelimit:u123 

## Hachages

 Les hachages stockent efficacement des champs de type objet — idéaux pour les profils utilisateur, les données de session ou les fiches produits.

redis-cli HSET app:test:user:1001 name "Ada" plan "pro" visits 1
redis-cli HGET app:test:user:1001 name
redis-cli HMGET app:test:user:1001 name plan visits
redis-cli HINCRBY app:test:user:1001 visits 1 
 Attention : HGETALL peut être coûteux sur de très gros hachages (milliers de champs). Préférez HMGET pour des champs spécifiques lorsque c'est possible.

## Listes

Les listes conviennent bien aux files d'attente et aux journaux ordonnés. Utilisez de petites charges utiles (identifiants) et récupérez les données complètes depuis un hachage ou une base de données.

### File FIFO avec LPUSH + RPOP

redis-cli DEL app:test:queue:emails
redis-cli LPUSH app:test:queue:emails id-1 id-2 id-3
redis-cli RPOP app:test:queue:emails
redis-cli RPOP app:test:queue:emails 

### Dépilement bloquant (attend un élément, timeout de 5 secondes)

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

## Ensembles et ensembles triés

### Ensembles — éléments uniques, idéaux pour l'appartenance et la déduplication

redis-cli SADD app:test:room:active u1 u2 u2 u3
redis-cli SISMEMBER app:test:room:active u2
redis-cli SMEMBERS app:test:room:active
redis-cli SREM app:test:room:active u1 

### Ensembles triés — classer les éléments par score

 redis-cli ZADD app:test:scores 100 u1 250 u2 180 u3
redis-cli ZRANGE app:test:scores 0 -1 WITHSCORES
redis-cli ZREVRANGE app:test:scores 0 1 WITHSCORES
redis-cli ZINCRBY app:test:scores 25 u1 
 Cas d'usage : classements, files de priorité, ordonnancement de séries temporelles.

## Recherche de données en toute sécurité

Évitez KEYS en production — il bloque le serveur sur de gros jeux de données. Préférez SCAN , qui est incrémental et non bloquant.

### Modèle SCAN de base

redis-cli SCAN 0 MATCH app:test:* COUNT 100 
 Résultat : curseur suivi des clés correspondantes. Bouclez jusqu'à ce que le curseur revienne à 0 pour terminer le balayage.

# Curseur 0 -> premier lot
redis-cli SCAN 0 MATCH app:test:* COUNT 100
# Renvoie : 1) "17" 2) 1) "app:test:a" 2) "app:test:b" ...

# Curseur 17 -> lot suivant
redis-cli SCAN 17 MATCH app:test:* COUNT 100
# Renvoie : 1) "0" 2) 1) "app:test:user:1001" ... 

### Variantes spécifiques aux collections

- HSCAN clé curseur [MATCH motif] [COUNT n]

- SSCAN clé curseur [MATCH motif] [COUNT n]

- ZSCAN clé curseur [MATCH motif] [COUNT n]

## Transactions

 Utilisez WATCH + MULTI + EXEC pour le verrouillage optimiste. Si un autre client modifie une clé surveillée, EXEC renvoie nil — recommencez tout le flux.

### Exemple : transférer des crédits si le solde est suffisant

# Données de démonstration
redis-cli SET app:test:balance:u1 100
redis-cli SET app:test:balance:u2 50

# Démarrer une mise à jour gardée : débiter 30 de u1, créditer 30 à u2
redis-cli WATCH app:test:balance:u1
redis-cli GET app:test:balance:u1
# Renvoie "100" — poursuivre
redis-cli MULTI
redis-cli DECRBY app:test:balance:u1 30
redis-cli INCRBY app:test:balance:u2 30
redis-cli EXEC 
 Si EXEC renvoie (nil) , un autre client a modifié balance:u1 — relisez et réessayez.

## Bases du Pub/Sub

Le publish/subscribe sert aux messages éphémères (non stockés). Les abonnés tardifs manquent les messages passés.

### Terminal A (abonné)

redis-cli SUBSCRIBE app:test:events 
 Sortie :

1) "subscribe"
2) "app:test:events"
3) (integer) 1 

### Terminal B (éditeur)

 redis-cli PUBLISH app:test:events "hello subscribers" 
 Renvoie (integer) 1 — nombre de clients ayant reçu le message.

### Terminal A reçoit

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

## Observabilité et santé

### Vérifications rapides

- PING — confirme l'accessibilité.

- INFO — statistiques serveur, mémoire, clients, espace de clés.

 redis-cli INFO memory | head -n 10 

### Utilisation mémoire d'une clé spécifique

 redis-cli MEMORY USAGE app:test:user:1001 
 Renvoie les octets (ex. : 112 ). Utilisez MEMORY USAGE clé SAMPLES 5 pour les grosses collections.

### Trouver les commandes lentes

redis-cli SLOWLOG GET 10 
 Champs de sortie : identifiant unique, horodatage Unix, durée en microsecondes, commande + arguments. Étudiez tout ce qui dépasse votre budget de latence (ex. : >10 ms).

### Débogage du trafic en direct

MONITOR diffuse chaque commande — utilisez avec précaution et brièvement.

redis-cli MONITOR 
 Appuyez sur Ctrl-C pour quitter. Avertissement : sur des instances chargées, le volume de sortie de MONITOR peut affecter les performances.

## Plan pilote local

Gardez le premier déploiement étroit, mesurable et facile à inspecter.

### Périmètre

- Placez toutes les clés de test sous l'espace de noms app:test:* .

- Exercez uniquement ces commandes : SET / GET / EXPIRE / TTL , INCR , HSET / HGET , LPUSH / RPOP , SADD / SISMEMBER , ZADD / ZRANGE , SCAN , INFO .

### Étapes

- Vérification initiale : PING et INFO memory ; notez la mémoire utilisée de base et les stats de l'espace de clés.

- Exécutez les exemples de ce guide exactement comme écrits.

- Vérifiez les résultats : valeurs MGET , TTL , compteurs SCAN , et MEMORY USAGE sur quelques clés.

- Nettoyez : DEL uniquement les clés sous app:test:* .

- Comparez avant/après INFO keyspace et memory pour garantir l'absence de résidus.

### Critères de succès

- Toutes les commandes renvoient les valeurs attendues.

- Aucune clé persistante après nettoyage ( SCAN app:test:* ne renvoie rien).

- Aucune entrée slowlog introduite par le pilote.

## Conclusion

Vous disposez maintenant d'une boîte à outils pratique pour les opérations Redis quotidiennes : création sécurisée de clés avec expirations, compteurs atomiques, hachages de type objet, files d'attente avec listes, collections uniques et classées avec ensembles et ensembles triés, itération non bloquante via SCAN , transactions optimistes simples, pub/sub pour événements éphémères, et vérifications de santé essentielles via INFO , MEMORY et SLOWLOG . Gardez les exemples dans des espaces de noms, privilégiez SCAN à KEYS , et surveillez INFO , MEMORY et SLOWLOG pendant vos expériences. Commencez par le pilote local, confirmez les résultats, puis étendez à vos clés et motifs spécifiques à l'application.