Dela via

Service Bus-köer, ämnen och prenumerationer

  • Artikel

Azure Service Bus har stöd för tillförlitliga meddelandeköer och hållbara publicerings-/prenumerationsmeddelanden. De meddelandeentiteter som utgör kärnan i meddelandefunktionerna i Service Bus är köer, ämnen och prenumerationer.

Viktigt!

Om du är nybörjare på Azure Service Bus läser du igenom Vad är Azure Service Bus? innan du går igenom den här artikeln.

Köer

Köer erbjuder FIFO (First in, first out)-leverans av meddelanden till en eller flera konkurrerande konsumenter. Mottagarna tar alltså vanligtvis emot och bearbetar meddelanden i den ordning de lades till i kön. Och bara en meddelandekonsument tar emot och bearbetar varje meddelande.

Bild som visar hur tjänstköer fungerar.

En viktig fördel med att använda köer är att uppnå tidsmässig frikoppling av programkomponenter. Med andra ord behöver producenter (avsändare) och konsumenter (mottagare) inte skicka och ta emot meddelanden samtidigt, eftersom meddelanden lagras korrekt i kön. Dessutom behöver producenten inte vänta på att ett svar från konsumenten ska fortsätta bearbetas och skickas.

En relaterad fördel är belastningsutjämning, som gör det möjligt för producenter och konsumenter att skicka och ta emot meddelanden i olika takt. I många program varierar systembelastningen över tid. Bearbetningstiden som krävs för varje arbetsenhet är dock vanligtvis konstant. Att förmedla meddelandeproducenter och konsumenter med en kö innebär att det förbrukande programmet bara behöver kunna hantera genomsnittlig belastning i stället för hög belastning. Köns djup växer och dras samman allt eftersom den inkommande belastningen varierar. Den här funktionen sparar pengar direkt när det gäller den infrastruktur som krävs för att hantera programbelastningen. När belastningen ökar kan fler arbetsprocesser läggas till för att läsa från kön. Varje meddelande bearbetas bara av en av arbetsprocesserna. Dessutom möjliggör den här pull-baserade belastningsutjämningen bästa möjliga användning av arbetsdatorerna även om arbetsdatorerna med bearbetning av power pull-meddelanden med sin egen maximala hastighet. Det här mönstret kallas ofta för ett konkurrerande konsument-mönster.

Att använda köer till mellanliggande mellan meddelandeproducenter och konsumenter ger en inbyggd lös koppling mellan komponenterna. Eftersom producenter och konsumenter inte känner till varandra kan en konsument uppgraderas utan att det påverkar producenten.

Skapa köer

Du kan skapa köer med något av följande alternativ:

Skicka och ta sedan emot meddelanden med klienter skrivna på programmeringsspråk, inklusive följande:

Ta emot lägen

Du kan ange två olika lägen där konsumenter kan ta emot meddelanden från Service Bus.

  • Ta emot och ta bort. När Service Bus i det här läget tar emot begäran från konsumenten markerar det meddelandet som förbrukat och returnerar det till konsumentprogrammet. Det här läget är den enklaste modellen. Det fungerar bäst för scenarier där programmet kan tolerera att ett meddelande inte bearbetas om ett fel inträffar. För att förstå det här scenariot bör du överväga ett scenario där konsumenten utfärdar mottagningsbegäran och sedan kraschar innan den bearbetas. När Service Bus markerar meddelandet som förbrukat börjar programmet använda meddelanden vid omstart. Det kommer att missa meddelandet som det förbrukade före kraschen. Den här processen kallas ofta för bearbetning högst en gång .
  • Granska lås. I det här läget har mottagningsåtgärden två faser. Tack vare det är det möjligt att stöda program som inte tolererar att ett meddelande saknas.

    1. Hittar nästa meddelande som ska användas, låser det för att förhindra att andra konsumenter tar emot det och returnerar sedan meddelandet till programmet.

    2. När programmet har bearbetat meddelandet begär det att Service Bus-tjänsten slutför den andra fasen av mottagningsprocessen. Sedan markerar tjänsten meddelandet som förbrukat.

      Om programmet av någon anledning inte kan bearbeta meddelandet kan det begära att Service Bus-tjänsten avger meddelandet. Service Bus låser upp meddelandet och gör det tillgängligt att tas emot igen, antingen av samma konsument eller av en annan konkurrerande konsument. För det andra finns det en tidsgräns som är associerad med låset. Om programmet misslyckas med att bearbeta meddelandet innan tidsgränsen för låsning går ut, kommer Service Bus att låsa upp meddelandet och göra det tillgängligt så att det kan tas emot igen.

      Om programmet kraschar efter att det har bearbetat meddelandet, men innan det begär att Service Bus-tjänsten ska slutföra meddelandet, levererar Service Bus meddelandet på nytt till programmet när det startas om. Den här processen kallas ofta för bearbetning minst en gång . Varje meddelande bearbetas alltså minst en gång. I vissa situationer kan dock samma meddelande levereras igen. Om ditt scenario inte kan tolerera duplicerad bearbetning lägger du till extra logik i programmet för att identifiera dubbletter. Mer information finns i Dubblettidentifiering, som kallas exakt en gång bearbetning .

      Kommentar

      Mer information om dessa två lägen finns i Lösa mottagningsåtgärder.

Ämnen och prenumerationer

Med en kö kan ett meddelande av en enskild konsument bearbetas. Till skillnad från köer ger ämnen och prenumerationer en en-till-många-form av kommunikation i ett publicerings- och prenumerationsmönster . Det är användbart för skalning till ett stort antal mottagare. Varje publicerat meddelande görs tillgängligt för varje prenumeration som har registrerats med ämnet. Publisher skickar ett meddelande till ett ämne och en eller flera prenumeranter får en kopia av meddelandet.

Bild som visar ett Service Bus-ämne med tre prenumerationer.

Prenumerationerna kan använda fler filter för att begränsa de meddelanden som de vill ta emot. Utgivare skickar meddelanden till ett ämne på samma sätt som de skickar meddelanden till en kö. Men konsumenterna får inte meddelanden direkt från ämnet. I stället får konsumenter meddelanden från prenumerationer i ämnet. En ämnesprenumeration liknar en virtuell kö som tar emot kopior av de meddelanden som skickas till ämnet. Konsumenter får meddelanden från en prenumeration på samma sätt som de tar emot meddelanden från en kö.

Funktionen för meddelandesändning i en kö mappar direkt till ett ämne och dess funktioner för meddelandemottagande mappar till en prenumeration. Den här funktionen innebär bland annat att prenumerationer stöder samma mönster som beskrevs tidigare i det här avsnittet om köer: konkurrerande konsument, tidsmässig frikoppling, belastningsutjämning och belastningsutjämning.

Skapa ämnen och prenumerationer

Att skapa ett ämne liknar att skapa en kö enligt beskrivningen i föregående avsnitt. Du kan skapa ämnen och prenumerationer med något av följande alternativ:

Skicka sedan meddelanden till ett ämne och ta emot meddelanden från prenumerationer med klienter skrivna på programmeringsspråk, inklusive följande:

Regler och åtgärder

I många scenarier måste meddelanden som har specifika egenskaper bearbetas på olika sätt. Om du vill aktivera den här bearbetningen kan du konfigurera prenumerationer för att hitta meddelanden som har önskade egenskaper och sedan utföra vissa ändringar av dessa egenskaper. Service Bus-prenumerationer ser alla meddelanden som skickas till ämnet, men det går bara att kopiera en delmängd av dessa meddelanden till den virtuella prenumerationskön. Den här filtreringen utförs med hjälp av prenumerationsfilter. Sådana ändringar kallas filteråtgärder. När en prenumeration skapas kan du ange ett filteruttryck som fungerar på meddelandets egenskaper. Egenskaperna kan vara både systemegenskaperna (till exempel Etikett) och anpassade programegenskaper (till exempel StoreName.) SQL-filteruttrycket är valfritt i det här fallet. Utan ett SQL-filteruttryck utförs alla filteråtgärder som definierats för en prenumeration på alla meddelanden för den prenumerationen.

Ett fullständigt fungerande exempel finns i Exemplet TopicFilters på GitHub. Mer information om filter finns i Ämnesfilter och åtgärder.

Java Message Service (JMS) 2.0-entiteter

Följande entiteter är tillgängliga via Java Message Service (JMS) 2.0 API.

  • Tillfälliga köer
  • Tillfälliga ämnen
  • Delade varaktiga prenumerationer
  • Ej delade varaktiga prenumerationer
  • Delade icke-varaktiga prenumerationer
  • Ej delade icke-varaktiga prenumerationer

Läs mer om JMS 2.0-entiteter och hur du använder dem.

Expressentiteter

Expressentiteter skapades för scenarier med högt dataflöde och kortare svarstider. Om ett meddelande skickas till en kö eller ett ämne med expressentiteter lagras det inte omedelbart i meddelandearkivet. I stället cachelagras meddelandet ursprungligen i minnet. Meddelanden som finns kvar i entiteten skrivs till meddelandearkivet efter en fördröjning, då dessa skyddas mot förlust på grund av ett avbrott.

I vanliga entiteter sparas alla körningsåtgärder (t.ex. Skicka, Slutför, Överge, Deadletter) till arkivet först och först efter att detta har bekräftats för klienten som lyckat. I expressentiteter bekräftas en körningsåtgärd för klienten som lyckad först och sparas först senare i butiken. Om en dator startas om eller ett maskinvaruproblem inträffar kanske vissa bekräftade körningsåtgärder inte sparas alls. Det innebär att klienten får lägre svarstid och högre dataflöde med expressentiteter, på bekostnad av potentiell dataförlust och/eller omleverans av meddelanden.

Dessutom har många optimeringar gjorts inom Service Bus med tiden, vilket innebär att fördelarna med dataflöde och svarstid för expressentiteter för närvarande är minimala. Dessutom har Premium-nivån för Service Bus inte stöd för Express-entiteter. Därför rekommenderas det för närvarande inte att använda den här funktionen.

Nästa steg

Prova exemplen på det språk du väljer:

Använd följande länkar för exempel som använder äldre .NET- och Java-klientbibliotek:

Den 30 september 2026 drar vi tillbaka Azure Service Bus SDK-biblioteken WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus och com.microsoft.azure.servicebus, som inte följer Riktlinjerna för Azure SDK. Vi kommer också att avsluta stödet för SBMP-protokollet, så du kommer inte längre att kunna använda det här protokollet efter den 30 september 2026. Migrera till de senaste Azure SDK-biblioteken, som erbjuder kritiska säkerhetsuppdateringar och förbättrade funktioner, före det datumet.

Även om de äldre biblioteken fortfarande kan användas efter den 30 september 2026 får de inte längre officiell support och uppdateringar från Microsoft. Mer information finns i meddelandet om supportavgång.