Nachrichten löschen und Warteschlangeninhalte mit RabbitMQ-Befehlen verwalten

Das Löschen einer RabbitMQ-Warteschlange ist ein grobes Werkzeug. Es ist nützlich, wenn eine Warteschlange Testnachrichten, fehlerhafte Arbeitselemente oder einen Rückstand enthält, den Sie bewusst verwerfen möchten. Es ist gefährlich, wenn Sie nur raten. Eine Bereinigung sagt Ihnen nicht, warum der Rückstand entstanden ist, und sie behebt weder einen langsamen Verbraucher, eine fehlerhafte Wiederholungsschleife noch eine Dead-Letter-Richtlinie, die Nachrichten an die falsche Stelle sendet.

Verwenden Sie die Befehle in dieser Anleitung als operative Checkliste: Überprüfen Sie die Warteschlange, bestätigen Sie den Vhost, entscheiden Sie, was mit den Verbrauchern passiert, löschen Sie nur die Nachrichten, die Sie löschen möchten, und überprüfen Sie das Ergebnis.

Verstehen von Warteschlangeninhalten mit `rabbitmqctl`

Vor dem Löschen ist es oft notwendig, den aktuellen Zustand Ihrer Warteschlangen zu verstehen. Das Tool rabbitmqctl bietet mehrere Befehle zur Überprüfung von Warteschlangenstatistiken. Der relevanteste Befehl zum Verständnis von Nachrichtenanzahlen ist list_queues.

Auflisten von Warteschlangen und Nachrichtenanzahlen

Der Befehl rabbitmqctl list_queues zeigt Warteschlangenmetriken an. Für Löschungsentscheidungen ist die wichtigste Unterscheidung zwischen bereiten und nicht bestätigten Nachrichten.

Syntax:

rabbitmqctl list_queues [options]

Beispiel: Anzeigen von Warteschlangennamen und Nachrichtenanzahlen

Um alle Warteschlangen zusammen mit ihren Nachrichtenanzahlen anzuzeigen, können Sie den folgenden Befehl verwenden:

rabbitmqctl list_queues name messages_ready messages_unacknowledged

Dieser Befehl gibt eine Ausgabe ähnlich dieser aus:

name            messages_ready    messages_unacknowledged    consumers
my_queue        0                 0                          2
another_queue   150               25                         4

In dieser Ausgabe:

name: der Warteschlangenname innerhalb des ausgewählten Vhosts.
messages_ready: Nachrichten, die auf die Zustellung warten.
messages_unacknowledged: Nachrichten, die bereits an Verbraucher zugestellt, aber noch nicht bestätigt wurden.
consumers: die Anzahl der angeschlossenen Verbraucher.

Wenn messages_ready steigt, überholen Produzenten die Verbraucher oder Verbraucher fehlen. Wenn messages_unacknowledged steigt, haben Verbraucher Arbeit angenommen, beenden sie aber nicht. Das Löschen entfernt nur bereite Nachrichten; es ist kein sauberer Weg, um Arbeit zu entfernen, die sich bereits in den Händen der Verbraucher befindet.

Überprüfen spezifischer Warteschlangendetails

Für Skripting verwenden Sie die JSON-Ausgabe und filtern Sie sie mit einem JSON-fähigen Tool:

rabbitmqctl list_queues -p /prod name messages_ready messages_unacknowledged consumers --formatter json

Für eine manuelle Incident-Überprüfung ist die Tabellenausgabe oft schneller:

rabbitmqctl list_queues -p /prod name messages_ready messages_unacknowledged consumers state

Löschen von Nachrichten aus einer Warteschlange

Wenn eine Warteschlange Nachrichten angesammelt hat, die nicht mehr benötigt werden, oder um Testdaten zu löschen, ist der Befehl purge_queue Ihr primäres Werkzeug. Dieser Befehl entfernt alle Nachrichten aus einer bestimmten Warteschlange. Es ist eine leistungsstarke Operation, die mit Vorsicht verwendet werden sollte, da gelöschte Nachrichten nicht wiederhergestellt werden können.

Der Befehl `purge_queue`

Der Befehl rabbitmqctl purge_queue nimmt den Warteschlangennamen als Argument. Verwenden Sie -p für den virtuellen Host.

Syntax:

rabbitmqctl purge_queue [-p <vhost_name>] <queue_name>

Beispiel: Löschen einer Warteschlange im Standard-Virtual-Host

Angenommen, Sie haben eine Warteschlange namens processing_errors im Standard-Virtual-Host und möchten alle Nachrichten daraus löschen:

rabbitmqctl purge_queue processing_errors

Bei erfolgreicher Ausführung meldet rabbitmqctl die Anzahl der gelöschten Nachrichten:

Purged 150 messages from queue 'processing_errors' in vhost '/'

Beispiel: Löschen einer Warteschlange in einem bestimmten Virtual-Host

Wenn sich Ihre Warteschlange dead_letter_queue im Virtual-Host namens my_vhost befindet, würden Sie verwenden:

rabbitmqctl purge_queue -p my_vhost dead_letter_queue

Dieser Befehl gibt eine ähnliche Bestätigungsmeldung zurück, die die Anzahl der aus der angegebenen Warteschlange und dem Vhost gelöschten Nachrichten angibt.

Wichtige Überlegungen zu `purge_queue`

Unumkehrbarkeit: gelöschte bereite Nachrichten sind verloren, es sei denn, Sie haben erfasste oder wiederholbare Quelldaten an anderer Stelle.
Nicht bestätigte Nachrichten: eine Bereinigung löscht nicht zuverlässig Nachrichten, die bereits an Verbraucher zugestellt wurden. Stoppen Sie zuerst die Verbraucher, wenn Sie einen sauberen Reset benötigen.
Berechtigungen: der Benutzer, der rabbitmqctl ausführt, benötigt entsprechenden Zugriff auf den Vhost und die Warteschlange.
Risiko des falschen Vhosts: geben Sie in gemeinsam genutzten Umgebungen immer -p an.

Hier ist eine sicherere Löschsequenz für eine produktionsähnliche Warteschlange:

# 1. Überprüfen Sie die Warteschlange im genauen Vhost
rabbitmqctl list_queues -p /prod name messages_ready messages_unacknowledged consumers

# 2. Stoppen oder skalieren Sie Verbraucher von Ihrem Bereitstellungssystem herunter
# Nur Beispiel; verwenden Sie die normale Steuerungsebene Ihrer Plattform.

# 3. Überprüfen Sie erneut, um laufende Nachrichten zu verstehen
rabbitmqctl list_queues -p /prod name messages_ready messages_unacknowledged consumers

# 4. Löschen Sie die Warteschlange
rabbitmqctl purge_queue -p /prod processing_errors

# 5. Überprüfen
rabbitmqctl list_queues -p /prod name messages_ready messages_unacknowledged consumers

Wenn die Warteschlange eine Dead-Letter-Warteschlange ist, ziehe ich es vor, vor dem Löschen einige Nachrichten über die Management-UI oder einen kontrollierten Verbraucher zu stichprobenartig zu überprüfen. Dead-Letter-Warteschlangen enthalten oft die einzigen einfachen Beweise für einen Serialisierungsfehler, einen falschen Routing-Key, eine abgelaufene Nachricht oder einen abgelehnten Job.

Best Practices für die Warteschlangenverwaltung

Effektive Warteschlangenverwaltung geht über das bloße Wissen, wie man löscht, hinaus. Hier sind einige Best Practices, die Sie beachten sollten:

Regelmäßige Überwachung

Überwachen Sie Ihre Warteschlangen kontinuierlich mit rabbitmqctl list_queues oder der RabbitMQ Management-UI. Achten Sie besonders auf die Zähler messages_ready und messages_unacknowledged. Unerwartet hohe Zahlen können auf Folgendes hinweisen:

Verbraucher sind ausgefallen oder haben die Verarbeitung eingestellt.
Verbraucher sind zu langsam, um mit der Produktionsrate Schritt zu halten.
Ein Fehler in der Nachrichtenverarbeitungslogik führt dazu, dass Bestätigungen fehlschlagen.

Alarmierung

Richten Sie Alarme basierend auf Warteschlangenmetriken ein. Lösen Sie beispielsweise einen Alarm aus, wenn messages_ready für einen längeren Zeitraum einen bestimmten Schwellenwert überschreitet. Dieser proaktive Ansatz ermöglicht es Ihnen, Probleme zu beheben, bevor sie die Leistung oder Datenintegrität Ihrer Anwendung beeinträchtigen.

Kontrolliertes Löschen

Geplante Wartung: Wenn eine temporäre Warteschlange absichtlich wegwerfbar ist, automatisieren Sie die Bereinigung während eines bekannten Zeitfensters.
Fehlerbehebung: Löschen Sie, nachdem Sie genügend Beweise gesammelt haben, um den Rückstand zu erklären.
Kapazitätsplanung: Wiederholte Löschungen sind ein Warnsignal. Sie bedeuten normalerweise, dass die Verbraucherkapazität, das Wiederholungsverhalten oder das Routing Aufmerksamkeit benötigt.

Dead-Lettering

Konfigurieren Sie für Nachrichten, die nicht erfolgreich verarbeitet werden können, Dead-Lettering. Dies leitet abgelehnte, abgelaufene oder über das Limit hinausgehende Nachrichten an eine andere Exchange/Warteschlange zur Überprüfung weiter. Löschen Sie die Dead-Letter-Warteschlange erst, nachdem Sie verstanden haben, ob diese Nachrichten wiederholt, archiviert oder verworfen werden sollen.

Idempotenz

Entwerfen Sie Ihre Verbraucher so, dass sie idempotent sind. Das bedeutet, dass die mehrmalige Verarbeitung derselben Nachricht den gleichen Effekt hat wie die einmalige Verarbeitung. Dies ist entscheidend, da es das Löschen und erneute Zustellen weniger riskant macht, da eine doppelte Verarbeitung nicht zu falschen Anwendungszuständen führt.

Wann nicht gelöscht werden sollte

Löschen Sie nicht nur, weil ein Graph hoch ist. Ein Rückstand kann ein nützlicher Druck sein: Er sagt Ihnen, dass Produzenten schneller sind als Verbraucher, Verbraucher ausfallen oder nachgelagerte Dienste langsam sind. Das Löschen verdeckt dieses Signal. Es ist der richtige Schritt, wenn das Geschäft entschieden hat, dass diese Nachrichten nicht verarbeitet werden sollen.

Ein guter Lösch-Ticket oder Incident-Notiz sollte vier Fragen beantworten:

Welcher Vhost und welche Warteschlange wurden gelöscht?
Wie viele bereite und nicht bestätigte Nachrichten existierten vor dem Löschen?
Wurden Verbraucher gestoppt oder liefen sie noch?
Warum war das Verwerfen der Nachrichten akzeptabel?

Diese Notiz mag im Moment langweilig erscheinen, spart aber später viel Diskussion, wenn jemand fragt, wo die Jobs geblieben sind.