Idempotent Consumer-Muster

Entwerfen Sie Nachrichtenkonsumenten so, dass die mehrfache Verarbeitung derselben Nachricht dieselben Effekte hat wie ihre einmalige Verarbeitung. Messagingsysteme, die mindestens einmal die Zustellung garantieren, können dieselbe Nachricht mehrmals übermitteln. Die Resilienz gegen Duplikate stellt sicher, dass durch die erneute Verarbeitung einer Nachricht keine doppelten Datensätze erstellt werden, ein Kunde doppelt belastet wird oder andere unerwünschte Auswirkungen haben.

Kontext und Problem

Verteilte Anwendungen übermitteln Arbeit häufig über einen Nachrichtenbroker, anstatt direkte synchrone Aufrufe zu verwenden. Die meisten Broker, einschließlich Azure Service Bus, Azure Event Hubs, Apache Kafka und RabbitMQ, bieten eine Mindestens-einmal-Zustellung. Mit dieser Garantie wird sichergestellt, dass eine Nachricht auch dann einen Verbraucher erreicht, wenn Fehler auftreten, sondern auch, dass der Broker dieselbe Nachricht mehrmals übermitteln kann.

Es ist praktisch nicht möglich, die exactly-once-Lieferung in einem verteilten System zu garantieren. Selbst Broker, die Exactly-once-Semantik verwenden, können nur Vorgänge garantieren, die sie direkt steuern, z. B. die Zustellung von Nachrichten an Konsumenten oder das Zurückschreiben von Daten in den Broker. Sie können die Nebenwirkungen, die Verbraucher in externen Systemen implementieren, nicht steuern. Die dauerhafte Lösung besteht nicht darin, doppelte Zustellung zu verhindern, sondern darin, dass der Consumer-Prozess sie korrekt verarbeitet. Wenn Sie die Lieferung mindestens einmal mit einem Verbraucher kombinieren, der Duplikate ignoriert, erzielen Sie eine effektive-Verarbeitung.

Duplikate können aus mehreren Quellen entstehen:

• Wiederholungsversuche des Producers. Ein Produzent sendet eine Nachricht, erhält aufgrund eines vorübergehenden Netzwerkfehlers oder eines Timeouts keine Bestätigung und sendet die Nachricht erneut. Der Broker enthält jetzt zwei Kopien, obwohl das Senden das erste Mal erfolgreich war.

• Erneute Zustellung nach fehlender Bestätigung. Ein Verbraucher empfängt und verarbeitet eine Nachricht, erkennt sie aber nicht an, weil der Verbraucher abstürzt, die Sperre abläuft oder die Bestätigung verloren geht. Der Broker geht davon aus, dass die Nachricht nicht verarbeitet und erneut übermittelt wurde.

• Verbraucherfehler während der Verarbeitung. Ein Consumer schließt einen Datenbankschreibvorgang ab, stürzt aber ab, bevor die Nachricht bestätigt wird. Eine andere Instanz nimmt die Nachricht auf und wiederholt den Schreibvorgang.

Lösung

Erstellen Sie einen idempotenten Konsumenten, indem der Konsument eine Aufzeichnung der Nachrichten führt, die er erfolgreich verarbeitet hat, und alle Nachrichten überspringt, die er bereits verarbeitet hat, anhand eines stabilen Bezeichners, der eine erneute Zustellung übersteht. Der Verbraucher überprüft den Speicher persistenter Bezeichner, um festzustellen, ob er diesen Bezeichner bereits verarbeitet hat, und verarbeitet dann entweder die Nachricht oder verwirft sie als Duplikat.

Der Kernfluss besteht aus den folgenden Schritten:

1. Lesen Sie die Nachricht, und extrahieren Sie den Deduplizierungsschlüssel.
2. Überprüfen Sie den Deduplizierungsspeicher für diesen Schlüssel.
3. Wenn der Schlüssel bereits im Speicher vorhanden ist, behandeln Sie die Nachricht als Duplikat. Bestätigen Sie die Nachricht, und beenden Sie die Verarbeitung, und geben Sie optional das zuvor aufgezeichnete Ergebnis zurück.
4. Wenn der Schlüssel noch nicht im Speicher vorhanden ist, verarbeiten Sie die Nachricht, und notieren Sie den Schlüssel in einem einzelnen atomischen Vorgang, und bestätigen Sie dann die Nachricht.

Die folgenden Abschnitte enthalten Hinweise dazu, wie Verbraucher idempotent gemacht werden können:

Auswählen eines stabilen Deduplizierungsschlüssels

Der Deduplizierungsschlüssel muss die logische Nachricht bei jeder erneuten Zustellung eindeutig und konsistent identifizieren. Verwenden Sie entweder einen vom Hersteller zugewiesenen Nachrichtenbezeichner oder einen idempotenten Schlüssel auf Unternehmensebene, der den spezifischen logischen Vorgang identifiziert, nicht einen freigegebenen Korrelationskontext, den mehrere Nachrichten übertragen können.

Legen Sie beispielsweise die eigenschaft Service Bus MessageId auf einen Wert fest, der die logische Nachricht eindeutig identifiziert. Verwenden CorrelationId Sie nicht als Schlüssel, da sie sich auf Gruppen verwandter Nachrichten bezieht, z. B. eine Anforderung und ihre Antworten. Bei Ereignissen, die der CloudEvents-Spezifikation folgen, identifiziert die source Kombination und id Attributkombination eindeutig ein Ereignis und bleibt bei erneuten Wiederholungen stabil.

Stützen Sie sich nicht auf Bezeichner auf Transportebene, die der Broker bei erneuter Zustellung neu generiert, und auch nicht auf Werte, die aus Zustellversuchen abgeleitet werden. Diese Werte ändern sich zwischen Bereitstellungen und verhindern die Duplikaterkennung. Vermeiden Sie außerdem, den Schlüssel aus volatilen Feldern wie z. B. Empfangszeitstempeln abzuleiten.

Wenn mehr als ein unabhängiger Verbraucher denselben Kanal verarbeitet, z. B. mehrere Abonnenten in einem Veröffentlichungsabonnent-Design, erhält jeder Verbraucher eine eigene Kopie einer Nachricht und muss den Abschluss der Verarbeitung unabhängig nachverfolgen. Wenn die Verbraucher einen Deduplizierungsspeicher gemeinsam nutzen, indizieren Sie die Datensätze anhand eines zusammengesetzten Schlüssels aus der Identität des Verbrauchers und der Identität der Nachricht. Ein Store, der allein anhand der Nachrichtenidentität indiziert ist, würde es dem ersten Consumer ermöglichen, die Verarbeitung für alle anderen zu unterdrücken.

Entscheiden, wo verarbeitete Schlüssel gespeichert werden sollen

Die folgenden Speicheroptionen gelten für verarbeitete Schlüssel:

• Eine dedizierte Deduplizierungstabelle. Der Konsument verwaltet eine separate Tabelle, die manchmal als Inbox bezeichnet wird und in der eine Zeile pro verarbeitetem Schlüssel enthalten ist. Dieser Ansatz hält Deduplizierungsbedenken getrennt von Geschäftsdaten und funktioniert gut, wenn viele Nachrichtentypen denselben Mechanismus aufweisen.

• Die Geschäftseinheit selbst. Der Verbraucher speichert den Schlüssel im Datensatz, den die Nachricht erstellt oder aktualisiert. Bei diesem Ansatz wird eine separate Tabelle vermieden, aber die Deduplizierung mit dem Geschäftsdatentyp wird gekoppelt.

Verarbeiteten Schlüssel und die Nebenwirkungen atomar festschreiben

Ein Ablauf, bei dem zuerst geprüft und dann verarbeitet wird, weist ein Fehlerfenster auf. Wenn ein Verbraucher eine Nachricht verarbeitet und den Schlüssel erst in einem separaten Schritt speichert, führt ein Absturz zwischen diesen beiden Vorgängen dazu, dass die Seiteneffekte bereits angewendet wurden, der Schlüssel jedoch nicht gespeichert ist, sodass der Verbraucher die Nachricht bei der nächsten erneuten Zustellung erneut verarbeitet.

Vermeiden Sie dieses Fehlerfenster, indem Sie die Deduplizierungsmarkierung und die geschäftsseitigen Effekte in derselben Transaktion schreiben. Wenn ein Verbraucher beide Vorgänge entweder gemeinsam oder gar nicht durchführt, findet er bei erneuter Zustellung entweder die Markierung und überspringt die Nachricht, oder er findet keine Markierung, weil die Transaktion nicht abgeschlossen wurde, und kann die Nachricht sicher erneut verarbeiten. Diese transaktionale Variante ist das Inbox-Muster und das verbraucherseitige Gegenstück zum producerseitigen Transactional Outbox pattern.

Schutz vor gleichzeitigen Duplikaten

Unter mindestens einmaler Zustellung mit gleichzeitig konkurrierenden Verbrauchern können zwei Instanzen kopien derselben Nachricht gleichzeitig empfangen. Beide Instanzen können die Existenzprüfung passieren, bevor eine von ihnen den Commit durchführt, sodass die Prüfung allein eine doppelte Verarbeitung nicht verhindert.

Erzwingen Sie die Korrektheit im Datenspeicher anstelle der Anwendungslogik, indem Sie die folgenden Schritte ausführen:

• Verwenden Sie eine Eindeutigkeitseinschränkung für den Deduplizierungsschlüssel, sodass zwei Transaktionen versuchen können, einen Schlüssel einzufügen, aber nur eine kann erfolgreich sein. Die andere Transaktion schlägt die Einschränkung fehl und behandelt die Nachricht als Duplikat. Dieser Ansatz macht die Datenbank zum einzigen Arbiter des Konflikts.

• Vermeiden Sie check-then-set-Rennen in Caches. Ein Muster, das einen Schlüssel überprüft und ihn dann in zwei separaten Vorgängen setzt, weist ein Zeitfenster auf, in dem gleichzeitige Wiederholungsversuche sich den Schlüssel sichern können. Verwenden Sie einen atomaren bedingten Schreibvorgang, z. B. einen Einfügevorgang, der bei einem Konflikt fehlschlägt, oder eine Set-if-absent-Operation, um den Schlüssel in einem einzigen atomaren Schritt zu beanspruchen.

Nebeneffekte behandeln, die nicht an der Transaktion teilnehmen können

Einige Prozesse können nicht an der Datenbanktransaktion des Verbrauchers teilnehmen, z. B. das Aufrufen einer Drittanbieter-API oder das Schreiben in einen externen Speicher. Verwenden Sie den folgenden zweistufigen Ansatz für diese Prozesse:

1. Erfassen Sie den Schlüssel mit dem Status „In Bearbeitung“ und führen Sie dann die externe Aktion aus.
2. Aktualisieren Sie den Datensatz so, dass er abgeschlossen ist , und speichern Sie das Ergebnis.

Bei erneuter Zustellung signalisiert ein als abgeschlossen markierter Datensatz dem Consumer, den Aufruf nicht zu wiederholen. Ein in Bearbeitung befindlicher Datensatz zeigt an, dass ein vorheriger Versuch möglicherweise teilweise abgeschlossen wurde oder von einem anderen Consumer verarbeitet wird. Der Consumer sollte veraltete Datensätze abgleichen oder ungelöste Fälle zur Intervention weiterleiten, bevor er die erneute Zustellung bestätigt.

Probleme und Überlegungen

Berücksichtigen Sie die folgenden Punkte, wenn Sie sich für die Implementierung dieses Musters entscheiden:

• Bevorzugen Sie natürlich idempotente Operationen. Einige Vorgänge sind inhärent idempotent und benötigen keine Deduplizierungsbuchführung. Ein Upsert mit einer Geschäftskennung als Schlüssel, ein Schreibvorgang, der einen absoluten Wert statt eines Inkrements festlegt, oder ein HTTP-PUT an einen Ressourcenbezeichner liefert dieselben Ergebnisse, unabhängig davon, ob er einmal oder mehrmals erfolgt.

  Sie können einen Vorgang manchmal natürlich idempotent machen, indem Sie ereignisgestützte Zustandsübertragung verwenden. Die Nachricht enthält den daraus resultierenden absoluten Zustand, z. B. den neuen Status einer Bestellung, sodass der Consumer diesen als Upsert statt als relative Änderung verarbeitet.

  Tip

  Streben Sie, wenn möglich, natürliche Idempotenz an, und verwenden Sie Deduplizierungsverfahren nur für Vorgänge, die sich nicht auf natürliche Weise idempotent gestalten lassen.

• Verwenden Sie ein Messaging-Framework, anstatt die Deduplizierung zu konfigurieren. Die ordnungsgemäße Implementierung von Deduplizierungsspeicher, Commit und Bereinigung ist fehleranfällig. Nachrichtenbasierte Frameworks stellen dieses Muster als integriertes Feature bereit.

  Beispielsweise dedupliziert NServiceBus eingehende Nachrichten anhand ihrer Nachrichtenbezeichner und stellt konfigurierbare Aufbewahrung und Bereinigung für Deduplizierungsdaten bereit. Die Consumer-Outbox von MassTransit verfolgt empfangene Nachrichten anhand ihrer Nachrichtenkennungen, um ein Exactly-once-Verhalten des Consumers zu gewährleisten.

• Verwalten Sie den Lebenszyklus von Deduplizierungsdatensätzen. Deduplizierungsdatensätze sammeln sich an, wenn Sie kein Ablaufdatum für sie festlegen. Bewahren Sie jeden Datensatz mindestens so lange auf, bis der Broker die ursprüngliche Nachricht weiterhin erneut senden kann. Die Größe dieses Fensters hängt von den maximalen Übermittlungsversuchen des Brokers, dessen Sperr- oder Sichtbarkeitstimeout und dem Zeitlimit der Nachricht ab.

  Legen Sie für Deduplizierungsdatensätze eine Time-to-Live (TTL) fest, die dieses Fenster überschreitet, sodass eine verspätete erneute Zustellung den zugehörigen Marker noch findet. Das Löschen von Datensätzen zu früh öffnet das Fenster für Duplikate erneut. Berücksichtigen Sie Nachrichten, die Operatoren erneut aus Dead-Letter-Warteschlangen einreichen, da diese erneuten Einreichungen noch lange nach Ablauf des normalen Wiederzustellungsfensters erfolgen können.

• Verwenden Sie keine Broker-Deduplizierung anstelle einer idempotenten Consumer-Logik. Einige Plattformen filtern Duplikate auf der Transportebene. Beispielsweise verwirft die Service Bus-Duplikaterkennung Nachrichten, die innerhalb eines konfigurierten Zeitfensters dieselbe MessageId aufweisen, wodurch erneute Sendeversuche des Produzenten unterdrückt werden.

  Dieses Feature arbeitet auf der Sendeseite und innerhalb eines begrenzten Zeitfensters, verhindert jedoch nicht, dass ein Consumer dieselbe Nachricht nach einer erneuten Zustellung zweimal verarbeitet. Sie benötigen weiterhin idempotente Consumerlogik. Verwenden Sie Plattformfunktionen, um das Duplikataufkommen zu reduzieren, und nicht als Ersatz für das Idempotent-Consumer-Muster.

• Nachrichtenreihenfolge berücksichtigen. Die Deduplizierung entfernt Duplikate, garantiert jedoch keine Reihenfolge. Wenn der Verbraucher von der Verarbeitungsreihenfolge abhängt, kombinieren Sie dieses Muster mit einem Bestellmechanismus wie Service Bus Nachrichtensitzungen, oder fügen Sie Sequenz- oder Versionsdaten hinzu, damit der Verbraucher veraltete Nachrichten ablehnen kann.

• Instrumentieren für Beobachtbarkeit. Geben Sie den Deduplizierungsschlüssel und einen Korrelationsbezeichner in strukturierten Protokollen aus, und verfolgen Sie eine Metrik für erkannte Duplikate. Eine steigende Duplikatrate kann auf eine Fehlkonfiguration des Producers, ein zu kleines Bestätigungs- oder Sperrfenster oder fehlerhafte Consumer hinweisen. Verwenden Sie verteilte Ablaufverfolgung und Korrelation , um einer Nachricht über Dienste hinweg zu folgen.

• Idempotenz an nachgeschaltete Aufrufe weitergeben. Einen Message-Consumer idempotent zu machen, schützt die von ihm aufgerufenen Dienste nicht. Wenn ein Verbraucher nachgeschaltete Dienste als Teil der Verarbeitung aufruft, verteilen Sie den Idempotency-Schlüssel, damit jede Dienstebene ihre eigene Arbeit deduplizieren kann.

Wann dieses Muster verwenden

Verwenden Sie dieses Muster in folgenden Fällen:

• Sie nutzen Nachrichten von einem Broker, der mindestens einmal die Zustellung bereitstellt, was die Standardeinstellung für die meisten Broker ist.

• Durch die Erneute Verarbeitung einer Nachricht können falsche Ergebnisse entstehen, z. B. doppelte Finanztransaktionen, doppelte Ressourcenerstellung oder wiederholte Benachrichtigungen.

• Mehrere konkurrierende Verbraucher verarbeiten denselben Kanal, wodurch die gleichzeitige Doppelte Zustellung wahrscheinlicher wird.

Dieses Muster ist möglicherweise nicht geeignet, wenn:

• Die Vorgänge, die der Consumer ausführt, sind bereits von Natur aus idempotent, sodass eine erneute Verarbeitung unbedenklich ist und der Buchführungsaufwand für die Deduplizierung nur zusätzlichen Aufwand ohne Nutzen verursacht.

• Die Arbeitslast kann die Auswirkungen gelegentlicher doppelter Verarbeitung verkraften, und die Kosten eines Deduplizierungsspeichers übersteigen die Auswirkungen eines Duplikats.

Idempotente Verarbeitung über das Messaging hinaus

Dieses Muster wendet das Prinzip der Idempotenz auf Nachrichtenkonsumenten an, aber die idempotente Verarbeitung ist ein allgemeineres Zuverlässigkeitsprinzip, das für jeden Vorgang von Vorteil sein kann, der mehr als einmal für dieselbe Aufgabe ausgeführt wird. Dieses Prinzip umfasst ETL-Transformationen (Extrahieren, Transformieren, Laden), die erneut eingespielte Daten erneut verarbeiten, Datenstromverarbeitung, die ab einem Checkpoint fortgesetzt wird, geplante Aufträge, die sich überschneiden oder neu gestartet werden, sowie Webhook- oder HTTP-Endpunkte, die doppelte Zustellungen erhalten.

Die gleiche Kerntechnik gilt in jedem Fall.

1. Verwenden Sie einen stabilen Schlüssel, um die Arbeitseinheit zu identifizieren.
2. Notieren Sie sich, was Sie verarbeiten.
3. Überspringen oder Absorbieren doppelter Ausführungen, sodass sich das Ergebnis nicht ändert, wenn die Arbeit wiederholt wird.

Die Mechanismen in diesem Artikel, z. B. stabile Schlüssel, Atommarkierungen und Einschränkungen der Eindeutigkeit, werden an diese Kontexte übertragen, auch wenn kein Nachrichtenbroker beteiligt ist.

Arbeitslastgestaltung

Bewerten Sie, wie das Muster für idempotente Consumer im Entwurf einer Workload verwendet werden kann, um die Ziele und Prinzipien zu erreichen, die in den Säulen des Azure Well-Architected Framework behandelt werden. Die folgende Tabelle enthält Anleitungen dazu, wie dieses Muster die Ziele jeder Säule unterstützt.

Säule	So unterstützt dieses Muster die Säulenziele
Zuverlässigkeitsentwurfsentscheidungen helfen Ihrer Arbeitsauslastung, ausfallsicher zu werden und sicherzustellen, dass sie nach auftreten eines Fehlers wieder in einen voll funktionsfähigen Zustand versetzt wird.	Dieses Muster ermöglicht es einer Workload, At-least-once-Zustellung und sichere Wiederholungsversuche zu verwenden, ohne Daten zu beschädigen, wodurch doppelte Zustellung aus einem Risiko für die Korrektheit zu einem tolerierbaren Zustand wird. - RE:07 Selbsterhaltung - Vorübergehende Fehler

Wenn dieses Muster Kompromisse innerhalb einer Säule einführt, sollten Sie sie gegen die Ziele der anderen Säulen berücksichtigen.

Beispiel

Im folgenden Beispiel wird ein idempotenter Consumer beschrieben, der Bestellungen aus Service Bus verarbeitet und den Zustand in Azure Cosmos DB for NoSQL speichert.

1. Ein Producer legt den Service Bus-MessageId auf einen Auftragsbezeichner auf Geschäftsebene fest.
2. Der Consumer empfängt die Nachricht im PeekLock-Modus, wodurch die Nachricht für eine erneute Zustellung verfügbar wird, wenn der Consumer sie nicht abschließt, bevor die Sperre abläuft.
3. Der Consumer partitioniert den Azure Cosmos DB-Container anhand der /orderId Bestellkennung und setzt das Dokumentfeld id auf dieselbe Bestellkennung, sodass jede Kopie einer bestimmten Bestellung in derselben logischen Partition landet und die Bestellung id selbst als Deduplizierungsmarker dient.

Der Consumer führt die folgenden Schritte aus, um jede Nachricht zu verarbeiten:

1. Lesen Sie die Nachricht, und verwenden Sie sie MessageId als Deduplizierungsschlüssel.
2. Versuchen Sie, das Bestelldokument zu erstellen, wobei sowohl id als auch der Partitionsschlüssel auf den Bestellbezeichner festgelegt sind.
3. Wenn die Erstellung erfolgreich ist, schließen Sie die Nachricht ab, sodass Service Bus sie aus der Warteschlange entfernt.
4. Wenn die Erstellung mit dem Statuscode HTTP 409 (Conflict) fehlschlägt, weil bereits ein Dokument mit diesem id existiert, lesen Sie das vorhandene Dokument und vergleichen Sie es mit der aktuellen Nachricht.
5. Wenn der gespeicherte Anforderungshash oder unveränderliche Geschäftsfelder übereinstimmen, behandeln Sie die Nachricht als Duplikat, schließen Sie sie ab, und überspringen Sie die weitere Verarbeitung.
6. Wenn der Hash der gespeicherten Anfrage oder unveränderliche Geschäftsfelder nicht übereinstimmen, senden Sie die Nachricht an eine Dead-Letter-Queue, und lösen Sie einen Alarm aus, anstatt die Nachricht stillschweigend zu verwerfen. Möglicherweise hat der Produzent den Bezeichner für unterschiedliche Inhalte wiederverwendet, oder die Nachrichtendetails wurden seit der ersten Verarbeitung geändert.
7. Wenn die Verarbeitung aus einem vorübergehenden Grund fehlschlägt, geben Sie die Nachricht frei, sodass Service Bus sie erneut zustellt, oder lassen Sie die Sperre ablaufen, damit ein anderer Consumer sie empfangen kann.

Der Erstellungsvorgang ist atomisch, sodass er sowohl als Deduplizierungsprüfung als auch als Schreibvorgang dient. Zwei Verbraucher, die Kopien derselben Nachricht erhalten, können nicht beide die Bestellung erstellen. Ein Erstellungsversuch ist erfolgreich, und der andere Versuch gibt einen Konflikt zurück und verwirft sein Duplikat sicher.

Wenn bei der Verarbeitung mehr als ein Dokument geschrieben werden muss, verwenden Sie einen transaktionalen Batch, der sowohl den Deduplizierungsschlüssel als auch die Geschäftsdokumente innerhalb desselben Partitionsschlüssels enthält. Da ein Transaktionsbatch in einer einzigen logischen Partition ausgeführt wird, wählen Sie einen Partitionsschlüssel, den alle Dokumente einer Nachricht gemeinsam haben. Der Batch schreibt entweder alle Dokumente gemeinsam fest oder keines von ihnen, sodass ein Absturz zwischen Verarbeitung und Bestätigung nicht dazu führen kann, dass der Deduplizierungsmarker und die Geschäftsdaten inkonsistent werden. Ein Batch, der versucht, ein Dokument zu erstellen, das bereits existiert, liefert den Statuscode 409 (Conflict) zurück, woran das Duplikat erkannt wird.

Damit dieser idempotente Verbraucher auch gegen Doppelte Senden-Wiederholungen widerstandsfähig ist, aktivieren Sie die Duplikaterkennung in der Warteschlange. Bei einer Standard- oder Premium-Warteschlange unterdrückt die Duplikaterkennung wiederholte Sendevorgänge innerhalb ihres Historienfensters. Der idempotente Consumer verarbeitet weiterhin alle Duplikate, die außerhalb dieses Fensters liegen oder durch erneute Zustellung entstehen.

Nächster Schritt

• Das Entwerfen von Azure Functions für identische Eingaben bietet Anleitungen zum Erstellen von idempotenten Funktionen, die duplizierte Aufrufe tolerieren.

Verwandte Ressourcen

• Asynchrone Messagingoptionen in Azure beschreiben die Auswahlmöglichkeiten der Messaginginfrastruktur, die Ihre Übermittlungsgarantien und Anforderungen an die Duplikatbehandlung bestimmen.

• Das Transactional-Outbox-Muster, das Nachrichten zuverlässig veröffentlicht, indem es sie in derselben Transaktion wie die Geschäftsdaten festschreibt, ist die Publisher-Seite des Idempotent-Consumer-Musters.

• Mithilfe des Wiederholungsmusters können Anwendungen vorübergehende Fehler durch Wiederholungsvorgänge behandeln, was die idempotente Verarbeitung erforderlich macht, da Wiederholungen zu doppelten Zustellungen führen können.

• Entwurf für resiliente Azure Event Hubs und Azure Functions wendet dieses Muster auf Funktionen an, die von Event Hubs ausgelöst werden, einschließlich Techniken zur Deduplizierung von Ereignisdatenströmen.