Übersicht über die Service Bus-Transaktionsverarbeitung
Dieser Artikel beschreibt die Transaktionsfunktionen von Microsoft Azure Service Bus. Ein Großteil der Diskussion wird durch die Transaktionsbeispielveranschaulicht. Dieser Artikel bietet lediglich eine Übersicht über die Transaktionsverarbeitung in Service Bus und die Service Bus-Funktion send via (Senden über), während das Beispiel zu den atomaren Transaktionen umfangreicher und komplexer ist.
Hinweis
- Der Basic-Tarif von Service Bus unterstützt keine Transaktionen. Die Standard- und Premium-Tarife unterstützen Transaktionen. Informationen zu den Unterschieden zwischen diesen Tarifen finden Sie unter Service Bus-Preise.
- Das Mischen von Verwaltungs- und Messagingvorgängen in einer Transaktion wird nicht unterstützt.
- Das JavaScript-SDK unterstützt keine Transaktionen.
Transaktionen in Service Bus
Eine Transaktion gruppiert zwei oder mehr Vorgänge in einem Ausführungsbereich. Solch eine Transaktion muss von sich aus sicherstellen, dass alle Vorgänge, die zu einer bestimmten Gruppe von Vorgängen gehören, entweder gemeinsam gelingen oder gemeinsam fehlschlagen. In dieser Hinsicht agieren Transaktionen als eine Einheit. Dieses Verhalten wird häufig als Unteilbarkeit bezeichnet.
Service Bus ist ein Transaktionsnachrichtenbroker und gewährleistet die Transaktionsintegrität für alle internen Vorgänge in seinen Nachrichtenspeichern. Alle Übertragungen von Nachrichten im Service Bus, wie das Verschieben von Nachrichten in eine Warteschlange für unzustellbare Nachrichten oder die automatische Weiterleitung von Nachrichten zwischen Entitäten, sind transaktional. Wenn Service Bus also eine Meldung akzeptiert, wurde diese bereits gespeichert und mit einer Sequenznummer versehen. Alle darauf folgenden Nachrichtenübermittlungen innerhalb von Service Bus sind koordinierte Vorgänge zwischen Entitäten und führen weder zum Verlust (Quelle erfolgreich, Ziel schlägt fehl) noch zur Duplizierung (Quelle schlägt fehl, Ziel erfolgreich) der Nachricht.
Service Bus unterstützt Gruppierungsvorgänge für eine einzelne Nachrichtenentität (Warteschlange, Thema, Abonnement) innerhalb eines Transaktionsbereichs. Sie können beispielsweise mehrere Nachrichten aus einem Transaktionsbereich an eine Warteschlange senden. Die Nachrichten werden allerdings erst im Warteschlangenprotokoll committet, wenn die Transaktion erfolgreich abgeschlossen wurde.
Vorgänge innerhalb eines Transaktionsbereichs
Die innerhalb eines Transaktionsbereichs ausführbaren Vorgänge sind:
- Send
- Abgeschlossen
- Abandon
- Deadletter
- Verzögern
- Schloss erneuern
Empfangsoperationen sind nicht enthalten, da davon ausgegangen wird, dass die Anwendung Nachrichten im Peek-Lock-Modus, in einer Empfangsschleife oder mit einem Callback abruft und erst dann einen Transaktionsbereich für die Verarbeitung der Nachricht öffnet.
Die Disposition der Nachricht (vollständig, verworfen, unzustellbar, zurückgestellt) tritt innerhalb des Bereichs und abhängig von dem Gesamtergebnis der Transaktion auf.
Wichtig
Azure Service Bus versucht bei einer Ausnahme nicht, einen Vorgang zu wiederholen, wenn sich der Vorgang in einem Transaktionsbereich befindet.
Vorgänge, die nicht in Transaktionsbereichen eingetragen werden
Beachten Sie, dass Nachrichtenverarbeitungscode, der Datenbanken und andere Dienste wie Cosmos DB aufruft, diese nachgelagerten Ressourcen nicht automatisch in denselben Transaktionsbereich einträgt. Weitere Informationen zum Umgang mit diesen Szenarien finden Sie in den Richtlinien zur idempotenten Nachrichtenverarbeitung.
Übertragungen und „send via“
Service Bus unterstützt Übertragungen, um transaktionsbasierte Übergaben von Daten aus einer Warteschlange oder einem Thema an einen Prozessor und von dort an eine andere Warteschlange oder ein anderes Thema zu ermöglichen. Bei einem Übertragungsvorgang sendet ein Sender eine Nachricht zuerst an eine Übertragungswarteschlange oder ein Übertragungsthema. Die Übertragungswarteschlange bzw. das Übertragungsthema verschiebt die Nachricht sofort an die gewünschte Zielwarteschlange bzw. das gewünschte Zielthema und verwendet dazu dieselbe stabile Übertragungsimplementierung, auf der auch die automatische Weiterleitung basiert. Die Nachricht wird an das Protokoll der Übertragungswarteschlange oder des Themas niemals in einer Weise committet, dass sie für die Consumer der Übertragungswarteschlange bzw. des Themas sichtbar wird.
Wenn die Übertragungswarteschlange oder das Übertragungsthema selbst die Quelle der eingehenden Nachrichten des Absenders ist, offenbart sich die Leistungsfähigkeit dieser Transaktionsfunktion. Anders gesagt: Service Bus kann die Nachricht über die Übertragungswarteschlange bzw. das Übertragungsthema an die Zielwarteschlange bzw. das Zielthema übermitteln. Gleichzeitig führt Service Bus einen vollständigen (oder einen zurückgestellten oder unzustellbaren) Vorgang für die Eingabenachricht aus. All dies erfolgt in einem einzigen atomaren Vorgang.
Wenn Sie Nachrichten von einem Themenabonnement empfangen und an eine Warteschlange oder ein Thema in der gleichen Transaktion senden müssen, muss es sich bei der Übertragungsentität um ein Thema handeln. In diesem Szenario starten Sie den Transaktionsbereich für das Thema, empfangen Nachrichten vom Abonnement im Transaktionsbereich und senden sie über das Übertragungsthema an ein Warteschlangen- oder Themenziel.
Hinweis
- Wenn eine Nachricht über eine Übertragungswarteschlange im Bereich einer Transaktion gesendet wird, entspricht „
TransactionPartitionKey“ funktionell „PartitionKey“. Dadurch wird sichergestellt, dass Nachrichten zusammengehalten werden, und zwar in der Reihenfolge, in der sie übertragen werden. - Wenn die Zielwarteschlange oder das Zielthema gelöscht wird, wird eine 404-Ausnahme ausgelöst.
Codebeispiel
Erstellen Sie einen Nachrichtenabsender, der sich über die Übertragungswarteschlange an die Zielwarteschlange richtet, um solche Übertragungen einzurichten. Sie verfügen außerdem über einen Empfänger, der Nachrichten aus derselben Warteschlange abruft. Beispiel:
Eine einfache Transaktion verwendet diese Elemente anschließend wie im folgenden Beispiel. Um das vollständige Beispiel zu sehen, sehen Sie sich den Quellcode auf GitHub an:
var options = new ServiceBusClientOptions { EnableCrossEntityTransactions = true };
await using var client = new ServiceBusClient(connectionString, options);
ServiceBusReceiver receiverA = client.CreateReceiver("queueA");
ServiceBusSender senderB = client.CreateSender("queueB");
ServiceBusReceivedMessage receivedMessage = await receiverA.ReceiveMessageAsync();
using (var ts = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled))
{
await receiverA.CompleteMessageAsync(receivedMessage);
await senderB.SendMessageAsync(new ServiceBusMessage());
ts.Complete();
}
Weitere Informationen zur EnableCrossEntityTransactions-Eigenschaft finden Sie in der Referenz zur ServiceBusClientBuilder.enableCrossEntityTransactions-Methode.
Timeout
Eine Transaktion weist nach zwei Minuten einen Timeout auf. Der Transaktionszeitgeber startet, wenn der erste Vorgang in der Transaktion gestartet wird.
Nächste Schritte
Weitere Informationen zu Service Bus-Warteschlangen finden Sie in den folgenden Artikeln: