Approche basée sur les Listes

Cette méthode repose sur les structures de données de type List pour simuler une file d'attente simple.

• Le producteur utilise LPUSH pour insérer des messages en tête de liste.
• Le consommateur utilise BRPOP pour extraire les messages en queue de liste de manière bloquante.

# Producteur : Ajout d'une tâche dans la file 'task_queue'
redis> LPUSH task_queue "process_image_01"
(integer) 1

# Consommateur : Récupération bloquante avec un timeout de 10 secondes
redis> BRPOP task_queue 10
1) "task_queue"
2) "process_image_01"

Avantages et Limites

• Points forts : Facilité de mise en œuvre, persistance native des données et respect strict de l'ordre d'insertion (FIFO).
• Points faibles : Distribution limitée à un seul consommateur par message et risque de perte de données si le client plante après avoir récupéré le message mais avant de l'avoir traité.

Le modèle Pub/Sub (Publication et Abonnement)

Introduit avec Redis 2.0, ce modèle permet une diffusion de type "broadcast". Un message envoyé sur un canal est reçu par tous les abonnés actifs.

Commandes principales

Analyse du modèle

• Avantages : Supporte nativement le multi-producteur et le multi-consommateur (fan-out).
• Inconvénients : Absence de persistance. Si aucun consommateur n'est connecté au moment de l'envoi, le message est définitivement perdu. De plus, les consommateurs disposent d'un tampon limité ; si le traitement est trop lent, les messages excédentaires sont supprimés.

Redis Stream : La solution robuste

Apparu dans la version 5.0, le type Stream est une structure de données persistante conçue spécifiquement pour les files de messages complexes.

Émission de messages

On utilise la commande XADD pour alimenter le flux.

# Syntaxe : XADD clé [MAXLEN limite] ID champ valeur [champ valeur ...]
# Exemple : Enregistrement d'un événement utilisateur
redis> XADD web_events * user_id 101 action "login"
"1695432100000-0"

• * : Demande à Redis de générer automatiquement un identifiant unique (timestamp-séquence).
• MAXLEN : Permet de limiter la taille du flux pour éviter une consommation mémoire excessive.

Lecture des flux

La lecture peut être ponctuelle ou bloquante via XREAD.

# Lecture simple à partir du début (ID 0)
redis> XREAD COUNT 2 STREAMS web_events 0

# Lecture bloquante pour les nouveaux messages uniquement ($)
redis> XREAD BLOCK 5000 STREAMS web_events $

Groupes de consommateurs (Consumer Groups)

Les groupes de consommateurs permettent de répartir la charge de travail entre plusieurs instances tout en garantissant la fiabilité.

• Répartition : Chaque message n'est délivré qu'à un seul membre du groupe.
• Persistance de l'état : Le groupe mémorise le dernier ID lu, permettant de reprendre après une panne.
• Accusé de réception : Un mécanisme de confirmation (XACK) assure que le message a été traité.

Exemple de workflow avec Groupe

# 1. Création du groupe 'billing_workers' sur le flux 'orders'
# On commence à lire depuis le début (0)
redis> XGROUP CREATE orders billing_workers 0 MKSTREAM

# 2. Le consommateur 'worker_A' récupère un nouveau message (symbole >)
redis> XREADGROUP GROUP billing_workers worker_A COUNT 1 STREAMS orders >
1) 1) "orders"
   2) 1) 1) "1695432155000-0"
         2) 1) "order_id"
            2) "99"

# 3. Validation du traitement par le consommateur
redis> XACK orders billing_workers 1695432155000-0

# 4. Consultation des messages en attente de validation (Pending List)
redis> XPENDING orders billing_workers - + 10

Le système de Pending List permet de suivre les messages envoyés mais non encore acquittés. Si un consommateur échoue, les messages listés dans son historique XPENDING peuvent être réaffectés ou retraités.