Teilen über

Duplikaterkennung

  • Artikel

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 auch eine GUID sein, aber das Verankern des Bezeichners in den Geschäftsprozess sorgt für eine vorhersagbare Wiederholbarkeit, die für die effektive Verwendung der Erkennung von Duplikaten gewünscht wird.

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 eine Partitionierung verwenden und Batches von Nachrichten übermitteln, sollten Sie sicherstellen, dass sie keine Eigenschaften für die Angabe einer Partitionierung enthalten. Da zur Bestimmung der Eindeutigkeit bei der Deduplizierung die explizite Festlegung von Nachrichten-IDs erforderlich ist, wird davon abgeraten, Deduplizierung und Batchverarbeitung zusammen mit der 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 ein geplantes Nachrichtenduplikat senden, wird die geplante Nachricht entfernt.

Fenstergröße für Duplikaterkennung

Neben der Aktivierung der Duplikaterkennung können Sie auch die Größe des Zeitfensters für den Duplikaterkennungsverlauf konfigurieren, in dem Nachrichten-IDs beibehalten werden. Der Wert beträgt für Warteschlangen und Themen standardmäßig 10 Minuten. Der Mindestwert beträgt 20 Sekunden, der Höchstwert beträgt 7 Tage.

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 Supporteinstellung.