Duplikaterkennung in Azure Service Bus

Wenn eine Anwendung aufgrund eines schwerwiegenden Fehlers unmittelbar nach dem Senden einer Nachricht fehlschlägt und die neu gestartete Anwendungsinstanz versehentlich der Ansicht ist, dass die vorherige Nachrichtenübermittlung nicht aufgetreten ist, führt eine nachfolgende Übermittlung dazu, dass dieselbe Nachricht zweimal im System angezeigt wird.

Es ist auch möglich, dass kurz zuvor ein Fehler auf Client- oder Netzwerkebene aufgetreten ist, sodass eine gesendete Nachricht in die Warteschlange eingereiht wird, ohne dass die Bestätigung erfolgreich an den Client zurückgesendet werden kann. In diesem Fall weiß der Client nicht sicher, welches Ergebnis der Sendevorgang hatte.

Die doppelte Erkennung nimmt den Zweifel an diesen Situationen aus, indem der Absender die gleiche Nachricht erneut senden kann, und die Warteschlange oder das Thema verwirft alle duplizierten Kopien.

Funktionsweise

Hinweis

Der Basic-Tarif von Service Bus unterstützt keine Duplikaterkennung. Die Standard- und Premium-Tarife unterstützen Duplikaterkennung. Informationen zu den Unterschieden zwischen diesen Tarifen finden Sie unter Service Bus-Preise.

Das Aktivieren der Erkennung von Duplikaten unterstützt das Nachverfolgen der anwendungsgesteuerten MessageId aller in einem angegebenen Zeitfenster an eine Warteschlange oder ein Thema gesendeten Nachrichten. Wenn eine neue Nachricht mit MessageId gesendet wird, die während des Zeitfensters protokolliert wurde, meldet Service Bus die Nachricht als akzeptiert (der Sendevorgang ist erfolgreich), die neu gesendete Nachricht wird jedoch sofort ignoriert und gelöscht. Es werden keine anderen Teile der Nachricht außer der MessageId ausgewertet.

Die Kontrolle des Bezeichners durch die Anwendung ist unerlässlich, da sie es der Anwendung ermöglicht, das MessageId mit einem Geschäftsprozesskontext zu verknüpfen, aus dem es im Fehlerfall zuverlässig rekonstruiert werden kann.

Für einen Geschäftsprozess, bei dem für die Behandlung von Anwendungskontext mehrere Nachrichten gesendet werden, kann sich die MessageId möglicherweise aus dem Kontextbezeichner auf Anwendungsebene (z. B. einer Bestellnummer) und dem Betreff der Nachricht (z. B. 12345.2017/Bezahlung) zusammensetzen.

Dies MessageId kann immer eine GUID sein, aber das Ankern des Bezeichners an den Geschäftsprozess führt zu vorhersehbarer Wiederholbarkeit, was für die effektive Verwendung der Duplikaterkennungsfunktion wichtig ist.

Wichtig

  • Wenn Partitionierungaktiviert ist, wird MessageId+PartitionKey verwendet, um die Eindeutigkeit zu bestimmen. Wenn Sitzungen aktiviert sind, müssen der Partitionsschlüssel und die Sitzungs-ID identisch sein.
  • Wenn Partitionierungdeaktiviert ist (Standardeinstellung), wird nur MessageId verwendet, um die Eindeutigkeit zu bestimmen.
  • Informationen zu SessionId, PartitionKey und MessageIdfinden Sie unter Partitionsschlüssel verwenden.
  • Stellen Sie bei der Verwendung von Partitionierung und beim Senden von Nachrichtenstapeln sicher, dass diese keine Eigenschaften zur Partitionsidentifizierung enthalten. Da die Deduplizierung auf explizite Einstellung von Nachrichten-IDs basiert, um die Eindeutigkeit zu bestimmen, wird nicht empfohlen, Deduplizierung und Batchverarbeitung zusammen mit Partitionierung zu verwenden.

Hinweis

Geplante Nachrichten werden bei der Erkennung von Duplikaten einbezogen. Wenn Sie also eine geplante Nachricht senden und dann ein nicht geplantes Nachrichtenduplikat senden, wird die nicht geplante Nachricht entfernt. Wenn Sie eine nicht geplante Nachricht senden und dann eine geplante Nachricht duplizieren, wird die geplante Nachricht verworfen.

Fenstergröße für Duplikaterkennung

Zusätzlich zur Aktivierung der Duplikaterkennung können Sie auch die Größe des Zeitfensters für den doppelten Erkennungsverlauf konfigurieren, in dem Nachrichten-IDs aufbewahrt werden. Dieser Wert ist standardmäßig auf 10 Minuten für Warteschlangen und Topics gesetzt, mit einem Mindestwert von 20 Sekunden und einem Höchstwert von 7 Tagen.

Das Aktivieren der Duplikaterkennung und die Größe des Zeitfensters haben direkte Auswirkungen auf den Durchsatz von Warteschlangen (und Themen), da alle aufgezeichneten Nachrichten-IDs mit den neu übermittelten Nachrichten-IDs verglichen werden müssen.

Ein kürzeres Zeitfenster bedeutet, dass weniger Nachrichten-IDs gehalten und verglichen werden müssen, sodass der Durchsatz weniger beeinträchtigt wird. Für Entitäten mit hohem Durchsatz, die eine doppelte Erkennung erfordern, behalten Sie das Fenster so klein wie möglich.

Nächste Schritte

Sie können die Erkennung doppelter Nachrichten mithilfe des Azure Portals, PowerShell, CLI, Resource Manager Vorlage, .NET, Java, Python und JavaScript aktivieren. Weitere Informationen finden Sie unter Aktivieren der Duplikaterkennung.

In Szenarien, in denen Clientcode eine Nachricht mit derselben MessageId nicht erneut übermitteln kann wie zuvor, entwerfen Sie Nachrichten, die sicher erneut verarbeitet werden können. In diesem Blogbeitrag zu Idempotenz werden verschiedene Verfahren für diese Vorgehensweise beschrieben.

Sehen Sie sich die Beispiele in der Sprache Ihrer Wahl an, um Azure Service Bus-Features zu untersuchen.

Hier finden Sie Beispiele für die älteren .NET- und Java-Clientbibliotheken:

Am 30. September 2026 werden die Azure Service Bus SDK-Bibliotheken „WindowsAzure.ServiceBus“, „Microsoft.Azure.ServiceBus“ und „com.microsoft.azure.servicebus“ eingestellt, da sie nicht den Azure SDK-Richtlinien entsprechen. Außerdem wird die Unterstützung des SBMP-Protokolls beendet, sodass Sie dieses Protokoll nach dem 30. September 2026 nicht mehr verwenden können. Migrieren Sie vor diesem Datum zu den neuesten Azure SDK-Bibliotheken, die wichtige Sicherheitsupdates und verbesserte Funktionen bieten.

Obwohl die älteren Bibliotheken noch über den 30. September 2026 hinaus verwendet werden können, erhalten sie keinen offiziellen Support und keine Updates mehr von Microsoft. Weitere Informationen finden Sie in der Ankündigung der Einstellung des Supports.

  • Last updated on