Freigeben über

Duplikaterkennung

Tritt bei einer Anwendung unmittelbar nach dem Senden einer Nachricht ein schwerwiegender Fehler auf und geht die neu gestartete Anwendungsinstanz fälschlicherweise davon aus, dass die vorherige Nachrichtenübermittlung nicht stattgefunden hat, ist die Nachricht nach einem weiteren Sendevorgang zweimal im System enthalten.

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.

Durch die Erkennung von Duplikaten werden diese Situationen aufgelöst, indem der Absender die gleiche Nachricht erneut senden kann, während die Warteschlange oder das Thema mögliche Duplikate verwirft.

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.

Funktionsweise

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 einer MessageId gesendet wird, die während des Zeitfensters erfasst wurde, wird die Nachricht als akzeptiert gemeldet (der Sendevorgang war erfolgreich). Die neu gesendete Nachricht wird jedoch sofort ignoriert und verworfen. Es werden keine anderen Teile der Nachricht außer der MessageId ausgewertet.

Die Anwendungssteuerung der ID ist wichtig, da nur diese es der Anwendung erlaubt, die MessageId einem Geschäftsprozesskontext zuzuordnen, aus dem sie bei einem Fehler vorhersagbar 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.

Die MessageId kann immer eine GUID sein, aber wenn der Bezeichner im Geschäftsprozess verankert ist, führt dies zu einer vorhersagbaren Wiederholbarkeit, die für die effektive Nutzung der Duplikaterkennung gewünscht 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.
  • Wenn Sie die Partitionierung und das Versenden von Batches von Nachrichten nutzen, sollten Sie sicherstellen, dass sie keine Eigenschaften zur Identifizierung von Partitionen 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

Abgesehen von der Aktivierung der Duplikaterkennung können Sie auch die Größe des Zeitfensters des doppelten Erkennungsverlaufs konfigurieren, in dem Nachrichten-IDs aufbewahrt werden. Dieser Wert ist standardmäßig 1 Minute für Warteschlangen und Themen 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 einem hohen Durchsatz, die eine Duplikaterkennung erfordern, sollten Sie das Zeitfenster so klein wie möglich halten.

Nächste Schritte

Sie können die Duplikaterkennung mit dem Azure-Portal, PowerShell, der CLI, einer Resource Manager-Vorlage, .NET, Java, Python und JavaScript aktivieren. Weitere Informationen finden Sie unter Aktivieren der Duplikaterkennung.

In Szenarien, in denen der Clientcode eine Nachricht mit der gleichen MessageId wie zuvor nicht erneut übermitteln kann, ist es wichtig, Nachrichten zu entwerfen, 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.