Hub de Connaissances DevOps
Hub de Connaissances DevOps

Comment Utiliser les Listes Redis (LPUSH, RPOP) comme Queues de Messages

Apprenez à transformer les listes Redis en un puissant système de mise en file d'attente de messages. Ce tutoriel couvre les commandes essentielles LPUSH et RPOP, montrant comment mettre des tâches en file d'attente et permettre aux workers de les retirer de la file et de les traiter de manière fiable. Explorez des exemples pratiques en Python et découvrez les considérations clés pour construire des queues de messages robustes basées sur le principe FIFO (premier entré, premier sorti) avec Redis pour le traitement de tâches asynchrones.

50 vues

Comment Utiliser les Listes Redis (LPUSH, RPOP) comme Files de Messages

Redis, réputé pour sa vitesse et sa polyvalence en tant que magasin de structures de données en mémoire, excelle également en tant que broker de messages. Bien qu'il offre des mécanismes de publication/abonnement dédiés, sa structure de données fondamentale de Liste, combinée à des commandes spécifiques comme LPUSH et RPOP, fournit un moyen simple mais robuste d'implémenter des systèmes de mise en file d'attente de messages. Cette approche est particulièrement utile pour les scénarios nécessitant un mécanisme léger et fiable pour découpler les tâches entre différents composants ou services d'application.

Cet article vous guidera à travers le processus d'utilisation des listes Redis pour construire une file de messages simple. Nous explorerons les commandes principales impliquées, démontrerons leur utilisation avec des exemples pratiques et discuterons des considérations pour la construction d'un système de mise en file d'attente fiable. À la fin, vous comprendrez comment exploiter ces fonctionnalités fondamentales de Redis pour le traitement asynchrone des tâches et la communication inter-services.

Comprendre les Listes Redis comme Files d'Attente

Une liste Redis est une collection ordonnée de chaînes de caractères. Elle peut être considérée comme une séquence d'éléments, et Redis fournit des commandes pour ajouter ou supprimer des éléments soit à la tête, soit à la queue de la liste. Cette nature à double extrémité rend les listes intrinsèquement adaptées aux implémentations de files d'attente.

  • Mise en file (Ajout de Messages) : Nous pouvons ajouter de nouveaux messages à la file d'attente en les poussant sur une extrémité de la liste. La commande LPUSH pousse les éléments vers la tête (côté gauche) d'une liste.
  • Retrait de la file (Traitement des Messages) : Nous pouvons récupérer et supprimer des messages de la file d'attente en les retirant de l'autre extrémité de la liste. La commande RPOP retire les éléments de la queue (côté droit) d'une liste.

Cette combinaison spécifique (LPUSH pour la mise en file et RPOP pour le retrait) crée une file d'attente Premier Entré, Premier Sorti (FIFO), ce qui est le comportement le plus courant et attendu pour une file de messages.

Commandes Principales : LPUSH et RPOP

Plongeons dans les deux commandes principales qui forment l'épine dorsale de notre file de messages Redis.

LPUSH key value [value ...]

La commande LPUSH insère une ou plusieurs valeurs de chaîne au début (côté gauche) de la liste stockée sous key. Si la key n'existe pas, une nouvelle liste est créée et les valeurs y sont insérées.

Exemple :

Imaginez que vous ayez une tâche à traiter, comme l'envoi d'un e-mail. Vous pouvez pousser cette tâche sous forme de message dans une liste Redis nommée email_tasks.

# Pousse une seule tâche d'e-mail
LPUSH email_tasks "{'to': '[email protected]', 'subject': 'Bienvenue !', 'body': 'Merci de vous être inscrit !'}"

# Pousse une autre tâche, elle sera placée avant la précédente
LPUSH email_tasks "{'to': '[email protected]', 'subject': 'Nouvel Enregistrement Utilisateur', 'body': 'Un nouvel utilisateur s'est enregistré.'}"

Après ces commandes, la liste email_tasks ressemblera à ceci (de la tête à la queue) :

1) "{'to': '[email protected]', 'subject': 'Nouvel Enregistrement Utilisateur', 'body': 'Un nouvel utilisateur s'est enregistré.'}"
2) "{'to': '[email protected]', 'subject': 'Bienvenue !', 'body': 'Merci de vous être inscrit !'}"

RPOP key

La commande RPOP supprime et renvoie le dernier élément (de la queue, côté droit) de la liste stockée sous key. Si la liste est vide, elle renvoie nil.

Exemple :

Un processus de travail peut interroger périodiquement la liste email_tasks pour de nouveaux messages à l'aide de RPOP.

# Un worker tente de récupérer une tâche
RPOP email_tasks

Si la liste n'est pas vide, RPOP renverra le dernier élément poussé (qui est le premier élément de la queue). Dans notre exemple ci-dessus, le premier appel à RPOP renverrait :

"{'to': '[email protected]', 'subject': 'Bienvenue !', 'body': 'Merci de vous être inscrit !'}"

Les appels ultérieurs récupéreraient alors la tâche suivante disponible depuis la queue.

Construction d'un Système de File de Messages de Base

Décrivons le flux typique d'une file de messages simple utilisant LPUSH et RPOP.

1. Producteur (Mise en file des tâches)

N'importe quelle partie de votre application qui a besoin de décharger du travail peut agir en tant que producteur. Elle construit un message (souvent une chaîne JSON représentant les détails de la tâche) et le pousse dans une liste Redis à l'aide de LPUSH.

Logique du Producteur (Exemple Python Conceptuel) :

import redis
import json

r = redis.Redis(host='localhost', port=6379, db=0)

def send_email_task(to_email, subject, body):
    task_message = {
        'type': 'send_email',
        'payload': {
            'to': to_email,
            'subject': subject,
            'body': body
        }
    }
    # LPUSH ajoute à la tête de la liste 'email_queue'
    r.lpush('email_queue', json.dumps(task_message))
    print(f"Tâche d'e-mail ajoutée à la file : {to_email}")

# Exemple d'utilisation :
send_email_task('[email protected]', 'Bonjour du Producteur', 'Ceci est un message de test.')
send_email_task('[email protected]', 'Mise à Jour Importante', 'De nouvelles fonctionnalités sont disponibles.')

2. Consommateur (Retrait et Traitement des tâches)

Les processus de travail, exécutés indépendamment, surveilleront en continu la liste Redis pour les nouveaux messages. Ils utiliseront RPOP pour récupérer et supprimer un message de la file d'attente.

Logique du Consommateur (Exemple Python Conceptuel) :

import redis
import json
import time

r = redis.Redis(host='localhost', port=6379, db=0)

def process_tasks():
    while True:
        # RPOP tente d'obtenir un message de la queue de la liste 'email_queue'
        message_bytes = r.rpop('email_queue')
        if message_bytes:
            message_str = message_bytes.decode('utf-8')
            try:
                task = json.loads(message_str)
                print(f"Traitement de la tâche : {task}")
                # Simuler le traitement de la tâche
                if task.get('type') == 'send_email':
                    print(f"  -> Envoi d'e-mail à {task['payload']['to']}...")
                    # Remplacer par la logique d'envoi d'e-mail réelle
                    time.sleep(1) # Simuler le travail
                    print(f"  -> E-mail envoyé à {task['payload']['to']}.")
                else:
                    print(f"  -> Type de tâche inconnu : {task.get('type')}")
            except json.JSONDecodeError:
                print(f"Erreur de décodage JSON : {message_str}")
            except Exception as e:
                print(f"Erreur lors du traitement de la tâche {message_str}: {e}")
        else:
            # Aucun message, attendez un peu avant de sonder à nouveau
            # print("Aucune tâche disponible, attente...")
            time.sleep(0.5)

if __name__ == "__main__":
    print("Worker démarré. En attente de tâches...")
    process_tasks()

Lorsque vous exécutez le producteur, il ajoute des messages. Lorsque vous exécutez le consommateur, il commencera à les récupérer et à les traiter. L'ordre de traitement correspondra à l'ordre dans lequel ils ont été poussés (FIFO) car LPUSH ajoute à la tête et RPOP retire de la queue.

Considérations sur la Fiabilité

Bien que LPUSH et RPOP fournissent un mécanisme de mise en file d'attente de base, la construction d'une file de messages véritablement fiable implique de traiter les points de défaillance potentiels :

1. Perte de Messages pendant le Traitement

Si un processus de travail plante après que RPOP a retiré le message mais avant qu'il ait fini de le traiter, ce message est perdu. Pour éviter cela :

  • Utiliser BRPOP ou BLPOP : Ce sont des variantes bloquantes. BRPOP bloquera jusqu'à ce qu'une liste contienne un élément ou jusqu'à ce qu'un délai d'attente soit atteint. Il est généralement préféré car il permet aux workers de dormir lorsqu'aucun message n'est disponible, réduisant ainsi l'utilisation du CPU.
    bash # Pop bloquant depuis la droite, avec un délai de 0 (bloquer indéfiniment) BRPOP email_queue 0
  • Implémenter l'Accusé de Réception / la Re-mise en File : Un schéma courant consiste à déplacer le message vers une liste de 'traitement' ou à utiliser une file 'retardée'. Si un worker échoue, un processus de surveillance séparé peut identifier les messages 'bloqués' et les remettre en file d'attente. Un schéma plus avancé implique l'utilisation de transactions Redis ou de scripts Lua pour extraire et déplacer atomiquement.

2. Gestion des Tâches Échouées

Que se passe-t-il si une tâche échoue pendant le traitement (par exemple, en raison d'un problème réseau temporaire ou de données erronées) ?

  • Mécanismes de Réessai : Implémentez une logique de réessai dans le worker. Après quelques échecs, déplacez la tâche vers une liste de 'tâches échouées' pour une inspection manuelle.
  • File de Lettres Mortes (DLQ) : Une liste Redis dédiée (ou un autre stockage) vers laquelle sont envoyés les messages qui échouent de manière répétée au traitement. C'est crucial pour le débogage et la récupération.

3. Consommateurs Multiples

Si vous avez plusieurs instances de travail consommant de la même file d'attente, RPOP (et BRPOP) garantit que chaque message est traité par un seul worker. En effet, RPOP supprime l'élément de manière atomique.

4. Ordre des Messages

Bien que LPUSH et RPOP créent une file FIFO, cette garantie n'est aussi forte que votre logique de traitement. Si les consommateurs remettent en file des messages échoués sans gestion appropriée, ou si vous introduisez d'autres opérations, l'ordre FIFO strict pourrait être compromis.

Techniques Avancées (Brièvement)

  • RPOPLPUSH : Retire atomiquement un message d'une liste et le pousse sur une autre (par exemple, une liste de 'traitement'). C'est une commande clé pour implémenter un traitement fiable avec accusés de réception.
  • BLPOP / BRPOP avec des Clés Multiples : Bloque et retire de la première liste qui devient non vide. Utile pour consommer à partir de plusieurs files.
  • Scripting Lua : Pour des opérations atomiques complexes que RPOPLPUSH ne couvre pas, les scripts Lua peuvent être utilisés pour garantir que des séquences critiques de commandes s'exécutent sans interruption.

Conclusion

Les listes Redis, grâce à la combinaison simple de LPUSH pour la mise en file et RPOP (ou sa contrepartie bloquante BRPOP) pour le retrait de la file, offrent un moyen simple mais efficace de construire des systèmes de mise en file d'attente de messages. Ce schéma est idéal pour découpler les tâches, permettre le traitement asynchrone et améliorer la réactivité de vos applications. Bien que basique, la compréhension de ces commandes et des considérations de fiabilité vous permettra d'implémenter des flux de traitement de tâches en arrière-plan et de communication inter-services robustes en utilisant Redis.