Mehrere TTL-Queues bilden feste Wartezeiten ab, erhöhen aber die Zahl der Bindings und Fehlerpfade. Quorum Queues zählen erneute Zustellungen. Eine Retry-Migration sollte deshalb beim beobachteten Consumer-Verhalten beginnen, weil ein Requeue, ein Dead-Letter-Vorgang und ein erneutes Publishing verschiedene Fehlerfenster besitzen. Der gewählte Mechanismus bestimmt anschließend die Topologie und den Testplan.
Kann RabbitMQ Redeliveries nativ verzögern?
Ein normales Requeue liefert eine Nachricht erneut aus, legt aber keine Wartezeit fest. Für eine Verzögerung brauchst du eine TTL-Retry-Queue mit Dead-Letter-Routing, das Delayed-Message-Exchange-Plugin oder einen externen Scheduler. Das Delivery Limit einer Quorum Queue begrenzt Zustellversuche, ersetzt jedoch keinen Backoff.
| Mechanismus | Verhalten | Retry-Zähler |
|---|---|---|
requeue=true | Der Broker stellt die Nachricht ohne festgelegte Pause erneut bereit | Eine Quorum Queue führt den Header x-delivery-count |
| TTL-Queue mit DLX | Eine separate Queue hält die Nachricht bis zum Ablauf der TTL zurück | Die Dead-Letter-Historie steht im Header x-death |
| Delayed-Message-Exchange-Plugin | Ein Publisher setzt die Verzögerung über den Header x-delay | Die Anwendung verwaltet die Zahl der Versuche |
| Externer Scheduler | Ein zusätzlicher Dienst speichert und veröffentlicht die Nachricht später | Der Scheduler oder die Anwendung verwaltet die Versuche |
Die Mechanismen sind nicht austauschbar: Sie unterscheiden sich beim Zählen der Versuche, beim Verhalten nach einem Prozessabbruch und bei der Verantwortung für das erneute Publishing. Diese Unterschiede geben vor, welche Daten in die Bestandsaufnahme gehören.
Bestehende Retry- und Dead-Letter-Pfade erfassen
Der vollständige Nachrichtenweg beginnt an der ursprünglichen Exchange und endet entweder beim erfolgreichen Acknowledgement oder in der finalen Dead-Letter-Queue. In Rollouts fällt regelmäßig auf, dass Teams den Header x-death aus TTL-Schleifen mit dem Header x-delivery-count einer Quorum Queue gleichsetzen. Beide beschreiben unterschiedliche Vorgänge.
- Das Betriebsteam notiert den Namen und Typ jeder Arbeits-, Retry- und Dead-Letter-Queue
- Das Entwicklungsteam dokumentiert für jeden Fehlerpfad die Werte von
requeue, TTL, Routing-Key und Dead-Letter-Exchange - Die Messung erfasst die Verzögerung, die Zahl der Redeliveries, den DLQ-Zugang und fachliche Duplikate
- Im Test wird zwischen einem Consumer-Abbruch, einer negativen Bestätigung und einem erneuten Publishing unterschieden
Eine fachliche Nachrichten-ID verbindet mehrere Broker-Zustellungen mit demselben Auftrag. Ohne diese ID bleiben Duplikate unsichtbar, wenn der Publisher eine Retry-Nachricht erzeugt und der ursprüngliche Consumer vor seinem Acknowledgement abbricht. Die so ermittelte Baseline liefert den Ausgangswert für das Delivery Limit.
Delivery Limit und finale Dead-Letter-Queue konfigurieren
basic.nack oder basic.reject mit requeue=true stellt die Nachricht erneut bereit. Auch ein Channel-Verlust gibt unbestätigte Nachrichten wieder frei. Bei einer Quorum Queue steigt in diesen Fällen der Wert von x-delivery-count.
Quorum Queues verwenden ab RabbitMQ 4.0 standardmäßig ein Delivery Limit von 20. Ein expliziter Policy-Wert verhindert, dass das Verhalten von einem Versionsstandard abhängt. Nach Überschreiten des Limits leitet RabbitMQ die Nachricht an die konfigurierte Dead-Letter-Exchange weiter; ohne DLX geht sie verloren.
rabbitmqctl set_policy --vhost / --priority 50 --apply-to quorum_queues orders-limit '^orders\.work$' '{"delivery-limit":8,"dead-letter-exchange":"orders.dlx","dead-letter-routing-key":"orders.failed"}'Das Beispiel begrenzt die wiederholten Zustellungen der Quorum Queue orders.work auf acht Versuche. Die Dead-Letter-Exchange orders.dlx und ihr Binding zur finalen Queue müssen bereits existieren. Übungen zu Quorum Queues, Publisher Confirms und DLX enthält das RabbitMQ 4 Training: Cluster Operations.
Das Delivery Limit stoppt eine schnelle Requeue-Schleife, erzeugt aber weiterhin keine Wartezeit. Nach dieser Begrenzung folgt deshalb die Entscheidung über den eigentlichen Verzögerungspfad.
TTL-Queues oder verzögertes Publishing verwenden
Eine Retry-Queue mit einer Queue-TTL bildet ein festes Intervall ab. Der Consumer weist eine fehlgeschlagene Nachricht zunächst einer Retry-Route zu. Nach Ablauf der TTL dead-lettert die Retry-Queue die Nachricht zurück zur Arbeits-Exchange.
Feste Intervalle mit TTL und DLX
Für Wartezeiten von 30 Sekunden und fünf Minuten benötigt dieses Muster zwei Retry-Queues mit jeweils eigener TTL. Der Header x-death zeigt, welche Queue eine Nachricht dead-letterte und wie oft dieser Vorgang auftrat. Der Consumer oder die Routing-Logik entscheidet anhand dieser Historie, wann die finale Dead-Letter-Queue folgt.
Variable Intervalle mit Plugin oder Scheduler
Das separat installierte Delayed-Message-Exchange-Plugin liest die Verzögerung aus dem Header x-delay. Vor einem Broker-Upgrade braucht das Plugin eine Version, die zur Zielversion passt. Ein externer Scheduler übernimmt dieselbe zeitliche Aufgabe außerhalb des Brokers, fügt jedoch einen weiteren Speicher- und Betriebsdienst hinzu.
Beim anwendungsseitigen Republishing bleibt ein Fehlerfenster: Bestätigt der Broker die neue Nachricht und der Consumer bricht vor dem Acknowledgement der ursprünglichen Zustellung ab, liegen zwei fachlich identische Nachrichten vor. Ein Acknowledgement vor dem erneuten Publishing erzeugt das umgekehrte Risiko und kann die Nachricht verlieren. Idempotente Verarbeitung oder ein transaktionales Outbox-Muster begrenzt diese Folgen.
Eine Migration kann TTL-Queues daher nur entfernen, wenn ein Plugin, ein Scheduler oder die Anwendung die Verzögerung übernimmt. Erst ein Fehlerkatalog zeigt, ob der neue Pfad unter Abbrüchen dasselbe fachliche Ergebnis liefert.
Fehlerfälle vor dem Rollout testen
Eine simulierte HTTP-429-Antwort deckt nur einen Teil des Retry-Verhaltens ab. Der Integrationstest verwendet denselben AMQP-Client, dieselben Acknowledgement-Einstellungen und dieselbe automatische Wiederherstellung wie die Produktionsanwendung.
- Der Testprozess beendet einen Consumer vor dem Acknowledgement und erfasst die folgende Redelivery
- Eine temporäre HTTP-429-Antwort zeigt, ob die vorgesehene Wartezeit die Aufrufrate begrenzt
- Eine Datenbanksperre bleibt länger bestehen als das erste Retry-Intervall und löst mehrere Versuche aus
- Eine dauerhaft fehlerhafte Nachricht überschreitet den Grenzwert und erreicht die finale Dead-Letter-Queue
- Die fachliche Nachrichten-ID deckt doppelte Veröffentlichungen und fehlende Idempotenz auf
Der Test erfasst Zeitstempel, x-delivery-count, x-death und die Reihenfolge späterer Nachrichten. Diese Messwerte werden anschließend zu Dashboard-Kennzahlen.
Retry-Verhalten mit Prometheus und Grafana beobachten
Der Befehl rabbitmq-plugins enable rabbitmq_prometheus aktiviert den Prometheus-Endpunkt. Ohne abweichende Portkonfiguration liegt er unter http://broker:15692/metrics.
Ein Dashboard verbindet die Zahl bereiter und unbestätigter Nachrichten mit den Delivery- und Redelivery-Raten. Eine eigene Metrik für den Zugang zur finalen Dead-Letter-Queue ergänzt die Broker-Werte, weil sie den fachlichen Abbruch eines Retry-Pfads sichtbar macht. Alarme reagieren auf dauerhaftes Queue-Wachstum, fehlende Consumer oder Abweichungen von der zuvor gemessenen Redelivery-Rate.
Die Konfiguration von Metriken, Dashboards und Alarmregeln behandelt das Training Monitoring mit Prometheus und Grafana. Zu jeder Alarmregel gehören eine Diagnoseabfrage, ein Eskalationsweg und ein messbares Rollback-Kriterium. Diese Kriterien werden im Rollout zu Freigabepunkten.
Mit Rückweg ausrollen
Die alte TTL-Topologie bleibt während der Validierung bestehen, erhält aber keinen parallelen Nachrichtenstrom. So lässt sich der frühere Pfad reaktivieren, ohne Nachrichten gleichzeitig durch zwei Retry-Systeme zu schicken.
- Das Team aktiviert den neuen Pfad zunächst für eine Queue mit begrenztem Nachrichtenvolumen
- Der Rollout vergleicht Retry-Latenz, Redeliveries, DLQ-Zugänge und Duplikate mit der Baseline
- Der Test spielt mindestens eine Nachricht aus der finalen Dead-Letter-Queue kontrolliert erneut ein
- Die alte Topologie wird erst nach Ablauf des vereinbarten Beobachtungszeitraums entfernt
Ein Rollback stellt die frühere Consumer-Version, die alten Bindings und den bisherigen Retry-Publisher wieder her. Ein Cluster-Downgrade gehört nicht zu diesem Rückweg. Nach erfolgreicher Validierung kann die alte Topologie entfallen.
Fazit: Retry-Mechanismus vor der Migration festlegen
Quorum Queues begrenzen wiederholte Zustellungen über x-delivery-count und das Delivery Limit. Die Verzögerung stammt dagegen aus einer TTL-Queue, einem Plugin, einem Scheduler oder dem erneuten Publishing der Anwendung. Beginne mit einer einzelnen Queue und spiele dort Consumer-Abbruch, temporären Fehler und Poison Message vollständig durch.