So verwenden Sie Redis-Listen (LPUSH, RPOP) als Nachrichtenwarteschlangen

Redis-Listen können eine nützliche kleine Nachrichtenwarteschlange sein, wenn Sie etwas Leichteres als RabbitMQ, Kafka oder ein vollständiges Hintergrundjob-Framework benötigen. Das übliche Muster ist einfach: Produzenten fügen Jobs mit LPUSH hinzu, und Worker entnehmen Jobs mit RPOP oder BRPOP.

Diese Einfachheit ist der Grund, warum Menschen darauf zurückgreifen. Eine Webanfrage kann einen E-Mail-Job in Redis ablegen und schnell zurückkehren. Ein Worker kann diesen Job einen Moment später aufnehmen. Sie benötigen keine Broker-Topologie, Exchanges, Topics oder einen neuen Betriebsstack. Sie müssen jedoch ehrlich über den Kompromiss sein: Ein einfaches RPOP entfernt die Nachricht, bevor der Worker die Arbeit abgeschlossen hat. Wenn der Worker zum falschen Zeitpunkt abstürzt, ist dieser Job verloren, es sei denn, Sie bauen ein Bestätigungsmuster darum herum.

Redis-Listen als Warteschlangen verstehen

Eine Redis-Liste ist eine geordnete Sammlung von Zeichenfolgen. Sie kann als eine Sequenz von Elementen betrachtet werden, und Redis bietet Befehle zum Hinzufügen oder Entfernen von Elementen entweder vom Kopf oder vom Ende der Liste. Diese doppelendige Natur macht Listen von Natur aus für Warteschlangenimplementierungen geeignet.

Einreihen (Nachrichten hinzufügen): Wir können der Warteschlange neue Nachrichten hinzufügen, indem wir sie an ein Ende der Liste pushen. Der Befehl LPUSH fügt Elemente am Kopf (linke Seite) einer Liste hinzu.
Entnehmen (Nachrichten verarbeiten): Wir können Nachrichten aus der Warteschlange abrufen und entfernen, indem wir sie vom anderen Ende der Liste poppen. Der Befehl RPOP entfernt Elemente vom Ende (rechte Seite) einer Liste.

Diese spezifische Kombination (LPUSH zum Einreihen und RPOP zum Entnehmen) erzeugt eine First-In-First-Out (FIFO)-Warteschlange, was das üblichste und erwartete Verhalten für eine Nachrichtenwarteschlange ist.

Kernbefehle: LPUSH und RPOP

Lassen Sie uns in die beiden primären Befehle eintauchen, die das Rückgrat unserer Redis-Nachrichtenwarteschlange bilden.

`LPUSH key value [value ...]`

Der Befehl LPUSH fügt einen oder mehrere Zeichenfolgenwerte am Kopf (linke Seite) der unter key gespeicherten Liste ein. Wenn der key nicht existiert, wird eine neue Liste erstellt und die Werte werden eingefügt.

Beispiel:

Stellen Sie sich vor, Sie haben eine Aufgabe, die verarbeitet werden muss, wie das Senden einer E-Mail. Sie können diese Aufgabe als Nachricht auf eine Redis-Liste namens email_tasks pushen.

# Eine einzelne E-Mail-Aufgabe pushen
LPUSH email_tasks "{'to': '[email protected]', 'subject': 'Welcome!', 'body': 'Thanks for signing up!'}"

# Eine weitere Aufgabe pushen, sie wird vor der vorherigen platziert
LPUSH email_tasks "{'to': '[email protected]', 'subject': 'New User Registration', 'body': 'A new user has registered.'}"

Nach diesen Befehlen sieht die Liste email_tasks wie folgt aus (von Kopf bis Ende):

1) "{'to': '[email protected]', 'subject': 'New User Registration', 'body': 'A new user has registered.'}"
2) "{'to': '[email protected]', 'subject': 'Welcome!', 'body': 'Thanks for signing up!'}"

`RPOP key`

Der Befehl RPOP entfernt und gibt das letzte Element (vom Ende, rechte Seite) der unter key gespeicherten Liste zurück. Wenn die Liste leer ist, wird nil zurückgegeben.

Beispiel:

Ein Worker-Prozess kann die Liste email_tasks regelmäßig mit RPOP auf neue Aufgaben überprüfen.

# Ein Worker versucht, eine Aufgabe abzurufen
RPOP email_tasks

Wenn die Liste nicht leer ist, gibt RPOP das letzte gepushte Element zurück (das erste Element vom Ende). In unserem obigen Beispiel würde der erste Aufruf von RPOP Folgendes zurückgeben:

"{'to': '[email protected]', 'subject': 'Welcome!', 'body': 'Thanks for signing up!'}"

Nachfolgende Aufrufe würden dann die nächste verfügbare Aufgabe vom Ende abrufen.

Aufbau eines einfachen Nachrichtenwarteschlangensystems

Lassen Sie uns den typischen Ablauf einer einfachen Nachrichtenwarteschlange mit LPUSH und RPOP skizzieren.

1. Produzent (Aufgaben einreihen)

Jeder Teil Ihrer Anwendung, der Arbeit auslagern muss, kann als Produzent fungieren. Er konstruiert eine Nachricht (oft eine JSON-Zeichenfolge, die die Aufgabendetails darstellt) und pusht sie mit LPUSH auf eine Redis-Liste.

Produzentenlogik (Konzeptionelles Python-Beispiel):

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 fügt am Kopf der Liste 'email_queue' hinzu
    r.lpush('email_queue', json.dumps(task_message))
    print(f"E-Mail-Aufgabe in Warteschlange gestellt: {to_email}")

# Beispielverwendung:
send_email_task('[email protected]', 'Hallo vom Produzenten', 'Dies ist eine Testnachricht.')
send_email_task('[email protected]', 'Wichtiges Update', 'Neue Funktionen verfügbar.')

2. Verbraucher (Aufgaben entnehmen und verarbeiten)

Worker-Prozesse, die unabhängig voneinander laufen, überwachen kontinuierlich die Redis-Liste auf neue Nachrichten. Sie verwenden RPOP, um eine Nachricht aus der Warteschlange zu holen und zu entfernen.

Verbraucherlogik (Konzeptionelles Python-Beispiel):

import redis
import json
import time

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

def process_tasks():
    while True:
        # RPOP versucht, eine Nachricht vom Ende der Liste 'email_queue' zu holen
        message_bytes = r.rpop('email_queue')
        if message_bytes:
            message_str = message_bytes.decode('utf-8')
            try:
                task = json.loads(message_str)
                print(f"Verarbeite Aufgabe: {task}")
                # Simuliere Aufgabenverarbeitung
                if task.get('type') == 'send_email':
                    print(f"  -> Sende E-Mail an {task['payload']['to']}...")
                    # Ersetzen durch tatsächliche E-Mail-Sendelogik
                    time.sleep(1) # Simuliere Arbeit
                    print(f"  -> E-Mail gesendet an {task['payload']['to']}.")
                else:
                    print(f"  -> Unbekannter Aufgabentyp: {task.get('type')}")
            except json.JSONDecodeError:
                print(f"Fehler beim Dekodieren von JSON: {message_str}")
            except Exception as e:
                print(f"Fehler bei der Verarbeitung der Aufgabe {message_str}: {e}")
        else:
            # Keine Nachricht, kurz warten, bevor erneut abgefragt wird
            # print("Keine Aufgaben verfügbar, warte...")
            time.sleep(0.5)

if __name__ == "__main__":
    print("Worker gestartet. Warte auf Aufgaben...")
    process_tasks()

Wenn Sie den Produzenten ausführen, pusht er Nachrichten. Wenn Sie den Verbraucher ausführen, beginnt er, diese aufzunehmen und zu verarbeiten. Die Reihenfolge der Verarbeitung entspricht der Reihenfolge, in der sie gepusht wurden (FIFO), da LPUSH am Kopf hinzufügt und RPOP vom Ende entfernt.

Zuverlässigkeitsüberlegungen

Während LPUSH und RPOP einen grundlegenden Warteschlangenmechanismus bieten, bedeutet der Aufbau einer Produktionswarteschlange, zu entscheiden, was passieren soll, wenn Worker abstürzen, Jobs fehlschlagen oder Produzenten fehlerhafte Nutzdaten senden.

1. Nachrichtenverlust während der Verarbeitung

Wenn ein Worker-Prozess nachdem RPOP die Nachricht entfernt hat, aber bevor er die Verarbeitung abgeschlossen hat, abstürzt, geht diese Nachricht verloren. Um dies zu verhindern:

Verwenden Sie BRPOP anstelle von engem Polling: BRPOP blockiert, bis eine Liste ein Element hat oder bis ein Timeout eintritt. Dies macht die Verarbeitung nicht von sich aus zuverlässig, verhindert aber, dass Worker alle paar Millisekunden aufwachen, nur um eine leere Warteschlange vorzufinden.
```
# Blockierendes Pop von rechts, mit einem Timeout von 0 (unbegrenzt blockieren)
BRPOP email_queue 0
```
Verwenden Sie eine Verarbeitungsliste zur Bestätigung: Ein gängiges Muster besteht darin, eine Nachricht atomar von email_queue nach email_processing zu verschieben, sie zu verarbeiten und sie erst dann aus email_processing zu entfernen, nachdem die Arbeit erfolgreich war. Wenn ein Worker stirbt, kann ein separater Aufräumprozess nach veralteten Elementen in der Verarbeitungsliste suchen und sie zurück in die Hauptwarteschlange verschieben. RPOPLPUSH ist der klassische Befehl für dieses Muster, und neuere Redis-Versionen bieten auch LMOVE/BLMOVE.

2. Umgang mit fehlgeschlagenen Aufgaben

Was passiert, wenn eine Aufgabe während der Verarbeitung fehlschlägt (z. B. aufgrund eines vorübergehenden Netzwerkproblems oder fehlerhafter Daten)?

Wiederholungsmechanismen: Implementieren Sie Wiederholungslogik innerhalb des Workers. Verschieben Sie die Aufgabe nach einigen Fehlversuchen zur manuellen Überprüfung in eine Liste 'failed_tasks'.
Dead Letter Queue (DLQ): Eine dedizierte Redis-Liste (oder ein anderer Speicher), an die Nachrichten gesendet werden, die wiederholt fehlschlagen. Dies ist entscheidend für Debugging und Wiederherstellung.

3. Mehrere Verbraucher

Wenn Sie mehrere Worker-Instanzen haben, die aus derselben Warteschlange konsumieren, stellt RPOP (und BRPOP) sicher, dass jede Nachricht nur von einem Worker verarbeitet wird. Dies liegt daran, dass RPOP das Element atomar entfernt.

4. Nachrichtenreihenfolge

Während LPUSH und RPOP eine FIFO-Warteschlange erstellen, ist diese Garantie nur so stark wie Ihre Verarbeitungslogik. Wenn Verbraucher fehlgeschlagene Nachrichten ohne ordnungsgemäße Handhabung erneut in die Warteschlange stellen oder wenn Sie andere Operationen einführen, könnte die strenge FIFO-Reihenfolge beeinträchtigt werden.

5. Nutzlastformat und Idempotenz

Behandeln Sie den Nachrichtentext als einen kleinen Vertrag. JSON ist üblich, weil es in redis-cli leicht zu überprüfen ist, aber verwenden Sie gültiges JSON anstelle von Python-artigen einfachen Anführungszeichen-Wörterbüchern:

{"type":"send_email","id":"email-1842","payload":{"to":"[email protected]","template":"welcome"}}

Das Feld id ist wichtig. Wenn ein Worker nach einem Timeout wiederholt oder wenn ein veralteter Job aus einer Verarbeitungsliste erneut in die Warteschlange gestellt wird, kann derselbe logische Job mehr als einmal ausgeführt werden. Entwerfen Sie den Handler so, dass ein Duplikat harmlos ist. Für einen E-Mail-Worker könnte dies bedeuten, email-1842 vor dem Senden in der Anwendungsdatenbank zu protokollieren und dann diesen Eintrag zu überprüfen, bevor ein erneuter Versuch eine weitere Nachricht sendet.

6. Warteschlangenlänge und Gegendruck

Beobachten Sie die Warteschlangenlänge mit LLEN email_queue. Eine wachsende Warteschlange ist nicht automatisch schlecht; sie kann einfach bedeuten, dass Worker nach einem Verkehrsanstieg aufholen. Eine Warteschlange, die stundenlang wächst, bedeutet normalerweise, dass Produzenten schneller sind als Verbraucher, Worker ausfallen oder eine langsame Abhängigkeit alles zurückhält.

In der Praxis mag ich es, sowohl über das Alter als auch über die Länge zu alarmieren. Redis-Listen speichern die Einreihungszeit nicht separat, also setzen Sie einen Zeitstempel in die Nutzlast, wenn das Jobalter wichtig ist:

{"type":"resize_image","id":"img-991","created_at":"2026-05-24T08:15:00Z","payload":{"image_id":991}}

Dann können Ihnen Ihre Worker-Protokolle sagen, ob Jobs Sekunden oder Stunden zu spät verarbeitet werden. Das ist viel nützlicher als die Länge allein, wenn Sie einen echten Vorfall debuggen.

Fortgeschrittene Techniken (kurz)

RPOPLPUSH: Entfernt atomar eine Nachricht aus einer Liste und fügt sie in eine andere ein (z. B. eine 'Verarbeitungs'-Liste). Dies ist ein Schlüsselbefehl zur Implementierung zuverlässiger Verarbeitung mit Bestätigungen.
BLPOP / BRPOP mit mehreren Schlüsseln: Blockieren und von der ersten Liste poppen, die nicht leer wird. Nützlich zum Konsumieren aus mehreren Warteschlangen.
Lua-Scripting: Für komplexe atomare Operationen, die RPOPLPUSH nicht abdeckt, können Lua-Skripte verwendet werden, um sicherzustellen, dass kritische Befehlssequenzen ohne Unterbrechung ausgeführt werden.

Eine zuverlässigere Worker-Form

Für alles, was wichtiger ist als eine Best-Effort-Benachrichtigung, vermeiden Sie den einfachen "Pop and Hope"-Worker. Eine sicherere Form sieht so aus:

RPOPLPUSH email_queue email_processing

Der Worker empfängt die Nachricht und Redis hat sie bereits nach email_processing verschoben. Nachdem die E-Mail gesendet wurde und die Anwendung den Erfolg protokolliert hat, entfernt der Worker diese genaue Nutzlast aus der Verarbeitungsliste:

LREM email_processing 1 '{"type":"send_email","id":"email-1842"}'

Das ist immer noch keine perfekte Enterprise-Warteschlange. LREM muss mit der Nutzlast übereinstimmen, große Verarbeitungslisten können umständlich werden, und Sie benötigen einen Aufräumprozess, der weiß, wann eine Nachricht alt genug für einen erneuten Versuch ist. Aber es ändert die Fehlerart auf nützliche Weise. Ein Worker-Absturz löscht nicht mehr die einzige Kopie des Jobs.

Wenn Sie diesen Ansatz verwenden, fügen Sie Wiederholungsmetadaten in die Nachricht ein oder speichern Sie sie neben der Nachrichten-ID in einem anderen Schlüssel. Ein Aufräumprozess kann beispielsweise eine veraltete Nachricht die ersten paar Male zurück in email_queue verschieben und sie dann nach Erreichen des Wiederholungslimits nach email_failed verschieben. Das gibt Ihnen einen Ort, um Giftnachrichten zu untersuchen, anstatt zuzusehen, wie dieselbe fehlerhafte Nutzlast für immer fehlschlägt.

Wann Redis-Listen die falsche Warteschlange sind

Redis-Listen sind leicht zu verstehen, aber sie sind nicht immer das richtige Werkzeug. Wenn Sie verzögerte Jobs, Job-Prioritäten, geplante Wiederholungen, Workflow-Transparenz oder eine langfristige Audit-Historie benötigen, kann eine Job-Bibliothek oder ein dedizierter Broker am Ende weniger Arbeit bedeuten. Redis Streams sind ebenfalls eine Überlegung wert, da sie Verbrauchergruppen und Bestätigungssemantik in den Datentyp integriert haben.

Ich mag Listen immer noch für kleine interne Warteschlangen: Thumbnail-Generierung, Cache-Warming, Webhook-Fan-Out, bei dem das Quellsystem wiederholen kann, oder einfache Hintergrundjobs, die von einer Anwendung verwaltet werden. Sobald mehrere Teams von der Warteschlangenvereinbarung abhängen, schreiben Sie die Liefererwartungen auf. "Mindestens einmal", "Höchstens einmal" und "Best Effort" sind während eines Vorfalls keine akademischen Begriffe. Sie entscheiden, ob Duplikate akzeptabel sind, ob verlorene Nachrichten tolerierbar sind und wie viel Wiederherstellungsmechanik Sie benötigen.

Redis-Listen sind eine gute Wahl, wenn Sie eine kleine, verständliche Warteschlange benötigen und bereits Redis betreiben. Beginnen Sie mit LPUSH und BRPOP für einfache Hintergrundarbeit. Fügen Sie eine Verarbeitungsliste, eine Wiederholungsanzahl und eine Dead-Letter-Liste hinzu, sobald der Verlust eines Jobs von Bedeutung wäre. Wenn Sie verzögerte Planung, Prioritäten, Fan-Out, lange Aufbewahrung oder starke Liefergarantien über viele Dienste hinweg benötigen, ist das normalerweise der Punkt, an dem eine zweckgebundene Warteschlange einfacher zu handhaben ist als ein wachsender Haufen von Redis-Konventionen.