Dela via

Översikt över bearbetning av Service Bus-transaktioner

  • Artikel

I den här artikeln beskrivs transaktionsfunktionerna i Microsoft Azure Service Bus. Mycket av diskussionen illustreras av exemplet Transaktioner. Den här artikeln är begränsad till en översikt över transaktionsbearbetning och funktionen skicka via i Service Bus, medan exemplet atomictransaktioner är bredare och mer komplext i omfånget.

Kommentar

  • Den grundläggande nivån för Service Bus stöder inte transaktioner. Standard- och premiumnivåerna stöder transaktioner. Skillnader mellan dessa nivåer finns i Service Bus-priser.
  • Det går inte att blanda hanterings- och meddelandeåtgärder i en transaktion.
  • JavaScript SDK stöder inte transaktioner.

Transaktioner i Service Bus

En transaktion grupperar två eller flera åtgärder i ett körningsomfång. En sådan transaktion måste till sin natur se till att alla åtgärder som hör till en viss åtgärdsgrupp antingen lyckas eller misslyckas gemensamt. I detta avseende fungerar transaktioner som en enhet, som ofta kallas atomicitet.

Service Bus är en transaktionell meddelandekö och garanterar transaktionsintegritet för alla interna åtgärder mot dess meddelandelager. Alla överföringar av meddelanden i Service Bus, till exempel att flytta meddelanden till en kö med obeställbara meddelanden eller automatisk vidarebefordran av meddelanden mellan entiteter, är transaktionella. Om Service Bus accepterar ett meddelande har det därför redan lagrats och märkts med ett sekvensnummer. Från och med då är alla meddelandeöverföringar i Service Bus samordnade åtgärder mellan entiteter och leder varken till förlust (källan lyckas och målet misslyckas) eller till duplicering (källan misslyckas och målet lyckas) för meddelandet.

Service Bus stöder grupperingsåtgärder mot en enskild meddelandeenhet (kö, ämne, prenumeration) inom en transaktion. Du kan till exempel skicka flera meddelanden till en kö inifrån ett transaktionsomfång, och meddelandena kommer endast att checkas in i köns logg när transaktionen har slutförts.

Åtgärder inom ett transaktionsomfång

De åtgärder som kan utföras inom ett transaktionsomfång är följande:

  • Skicka
  • Klart
  • Lämna
  • Deadletter
  • Skjuta upp
  • Förnya lås

Mottagningsåtgärder ingår inte, eftersom det antas att programmet hämtar meddelanden med hjälp av peek-lock-läget, inuti någon mottagningsloop eller med ett återanrop, och först då öppnas ett transaktionsomfång för bearbetning av meddelandet.

Borttagningen av meddelandet (fullständig, övergiven, obeställd, uppskjuten) sker sedan inom omfånget för och beroende av transaktionens övergripande resultat.

Viktigt!

Azure Service Bus försöker inte utföra en åtgärd igen i händelse av ett undantag när åtgärden finns i ett transaktionsomfång.

Åtgärder som inte listas i transaktionsomfång

Tänk på att kod för meddelandebearbetning som anropar till databaser och andra tjänster som Cosmos DB inte automatiskt registrerar dessa underordnade resurser i samma transaktionsomfång. Mer information om hur du hanterar dessa scenarier finns i riktlinjerna för idempotent meddelandebearbetning.

Överföringar och "skicka via"

För att möjliggöra transaktionell överlämning av data från en kö eller ett ämne till en processor, och sedan till en annan kö eller ett annat ämne, stöder Service Bus överföringar. I en överföringsåtgärd skickar en avsändare först ett meddelande till en överföringskö eller ett ämne, och överföringskö eller ämne flyttar omedelbart meddelandet till den avsedda målkön eller ämnet med samma robusta överföringsimplementering som funktionen autoforward förlitar sig på. Meddelandet checkas aldrig in i överföringskö eller ämnesloggen så att det blir synligt för överföringskö eller ämnets konsumenter.

Kraften i den här transaktionsfunktionen blir uppenbar när själva överföringsköen eller själva ämnet är källan till avsändarens indatameddelanden. Med andra ord kan Service Bus överföra meddelandet till målkön eller ämnet "via" överföringskö eller ämne, medan du utför en fullständig (eller uppskjuten eller obeställd) åtgärd på indatameddelandet, allt i en atomisk åtgärd.

Om du behöver ta emot från en ämnesprenumeration och sedan skicka till en kö eller ett ämne i samma transaktion måste överföringsentiteten vara ett ämne. I det här scenariot startar du transaktionsomfånget för ämnet, tar emot från prenumerationen med i transaktionsomfånget och skickar via överföringsämnet till en kö eller ett ämnesmål.

Kommentar

  • Om ett meddelande skickas via en överföringskö i omfånget för en transaktion motsvarar TransactionPartitionKey PartitionKeydet funktionellt . Det säkerställer att meddelanden hålls samman och i ordning när de överförs.
  • Om målkön eller ämnet tas bort utlöses ett 404-undantag.

Se den i kod

Om du vill konfigurera sådana överföringar skapar du en meddelandesändare som riktar sig mot målkön via överföringskö. Du har också en mottagare som hämtar meddelanden från samma kö. Till exempel:

En enkel transaktion använder sedan dessa element, som i följande exempel. Om du vill se det fullständiga exemplet läser du källkoden på GitHub:

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();
}

Mer information om egenskapen finns i EnableCrossEntityTransactions följande referens för ServiceBusClientBuilder.enableCrossEntityTransactions-metoden.

Timeout

En transaktion överskrider tidsgränsen efter 2 minuter. Transaktionstimern startar när den första åtgärden i transaktionen startar.

Nästa steg

Mer information om Service Bus-köer finns i följande artiklar: