Nachrichtenbestätigung
Eine Nachrichtenbestätigung meldet dem Broker, dass eine Zustellung nach der vereinbarten Regel angenommen oder verarbeitet wurde.
Eine Nachrichtenbestätigung meldet einem Message Broker, wann er eine Zustellung als erledigt behandeln darf. Entscheidend sind die Richtung der Bestätigung und der Zeitpunkt, den die Anwendung dafür wählt.
Bei RabbitMQ bestätigt ein Consumer mit einer manuellen positiven Bestätigung wie basic.ack seine Verarbeitung gegenüber dem Broker. Ein Publisher Confirm bestätigt dagegen die Annahme auf der Brokerseite gegenüber dem Sender. Daraus folgt noch nicht, dass die empfangende Anwendung ihre Aufgabe abgeschlossen hat.
Zwischen Speichern und Bestätigen
In einem fiktiven Ablauf verarbeitet ein Dienst die Nachricht E-42, speichert die erforderliche Datenbankänderung dauerhaft und bestätigt erst danach. Bestätigt er vorher und stürzt vor dem Speichern ab, kann der Broker die Zustellung bereits als erledigt betrachten, obwohl die Änderung fehlt.
Auch die umgekehrte Lücke ist wichtig: Ist die Änderung gespeichert, aber die Bestätigung geht verloren, kann eine erneute Zustellung folgen. RabbitMQ stellt bei manueller Bestätigung unbestätigte Nachrichten nach einem Verbindungs- oder Kanalabbruch wieder in die Queue. Der Dienst muss eine Wiederholung deshalb ohne doppeltes Geschäftsergebnis behandeln können.
Automatische Bestätigung wartet bei RabbitMQ nicht auf den Abschluss der Anwendungsarbeit. Der gewählte Modus muss zum gewünschten Schutz vor Arbeitsverlust passen. Eine Consumer-Bestätigung ist außerdem kein Beleg dafür, dass alle nachgelagerten Dienste oder eine externe Benachrichtigung erfolgreich waren.
Quellen
Verwandte Begriffe
- Message QueueEine Message Queue puffert Nachrichten, bis ein Verbraucher sie zur Verarbeitung übernimmt.
- Transactional InboxEine Transactional Inbox nutzt dauerhafte Nachrichteneinträge, um die lokale Verarbeitung gegen doppelte Zustellungen abzusichern.
- Retry-JitterRetry-Jitter verteilt Wiederholungsversuche durch zufällig variierte Wartezeiten, damit viele Clients nicht gleichzeitig erneut anfragen.
- TestmandantEin logisch abgegrenzter Kundenbereich einer mandantenfähigen Anwendung, der für Prüfungen eingerichtet ist.
- Webhook-ReplayWebhook-Replay bezeichnet die erneute Übermittlung einer Webhook-Meldung. Gezieltes Nachholen und Angriffe durch Wiederholung brauchen unterschiedliche Prüfungen.
- IdempotenzschlüsselEin Idempotenzschlüssel kennzeichnet Wiederholungen derselben beabsichtigten Anfrage. Geltungsbereich, Speicherdauer und API-Regeln bestimmen seine Wirkung.
Beiträge zum Thema








Schnittstellen & Integration mit ASES
ERP, CRM und Shop sauber verbunden

