Service Bus-köer, -ämnen och -prenumerationer

Azure Service Bus stöder en uppsättning molnbaserade, meddelandeorienterade mellanprogramstekniker, inklusive tillförlitliga meddelandeköer och beständig meddelandehantering för publicering/prenumeration. Dessa a brokered messaging-funktioner kan ses som frikopplade meddelandefunktioner som stöder publicera-prenumerera, tidsbestämd frikoppling och belastningsutjämningsscenarier med hjälp av Service Bus-meddelandearbetsbelastningen. Frikopplad kommunikation har många fördelar. Klienter och servrar kan till exempel ansluta efter behov och göra sina åtgärder på ett asynkront sätt.

De meddelandeentiteter som utgör kärnan i meddelandefunktionerna i Service Bus köer, ämnen och prenumerationer samt regler/åtgärder.

Köer

Köer erbjuder FIFO-meddelandeleverans (First In, First Out) till en eller flera konkurrerande konsumenter. Det innebär att mottagarna vanligtvis tar emot och bearbetar meddelanden i den ordning som de lades till i kön. Och endast en meddelandekonsument tar emot och bearbetar varje meddelande. En viktig fördel med att använda köer är att uppnå temporal frikoppling av programkomponenter. Producenter (avsändare) och konsumenter (mottagare) behöver med andra ord inte skicka och ta emot meddelanden samtidigt. Det beror på att meddelanden lagras durably i kön. Dessutom behöver producenten inte vänta på att ett svar från konsumenten ska fortsätta att bearbeta och skicka meddelanden.

En relaterad fördel är belastningsutjämning, vilket 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 normalt konstant. Att mellanmediara meddelandeproducenter och konsumenter med en kö innebär att det konsumerande 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 direkt pengar vad gäller mängden infrastruktur som krävs för att sera 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 ger den här pull-baserade belastningsutjämning 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 meddelandeproducenter och konsumenter ger en inbyggd lös koppling mellan komponenterna. Eftersom producenter och konsumenter inte är medvetna om varandra kan en konsument uppgraderas utan att påverka producenten.

Skapa köer

Du kan skapa köer med hjälp Azure Portal, PowerShell, CLI eller Resource Manager mallar. Skicka och ta emot meddelanden med hjälp av klienter som skrivits i C#, Java, Pythonoch JavaScript.

Mottagningslägen

Du kan ange två olika lägen där Service Bus tar emot meddelanden.

  • Ta emot och ta bort. I det här läget Service Bus 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 inte bearbeta ett meddelande 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 förbrukades före kraschen.
  • Granska låset. I det här läget blir mottagningsåtgärden tvåstegs, vilket gör det möjligt att stödja program som inte tolererar att meddelanden saknas.
    1. Söker efter nästa meddelande som ska användas, låser det för att förhindra att andra användare tar emot det och returnerar sedan meddelandet till programmet.

    2. När programmet har slutfört bearbetningen av meddelandet begär det att Service Bus tjänsten slutför det andra steget i mottagningsprocessen. Tjänsten markerar sedan meddelandet som förbrukat.

      Om programmet av någon anledning inte kan bearbeta meddelandet kan det begära att Service Bus tjänsten lämnar 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 timeout kopplad till låset. Om programmet inte kan bearbeta meddelandet innan tidsgränsen för låsning upphör att gälla Service Bus upp meddelandet och gör det tillgängligt att tas emot igen.

      Om programmet kraschar efter att det har bearbetat meddelandet, men innan det begär att Service Bus-tjänsten slutför meddelandet, Service Bus meddelandet till programmet när det startas om. Den här processen kallas ofta för bearbetning minst en gång. Det innebär att varje meddelande bearbetas 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 ytterligare logik i programmet för att identifiera dubbletter. Mer information finns i Dubblettidentifiering. Den här funktionen kallas för bearbetning exakt en gång.

      Anteckning

      Mer information om dessa två lägen finns i Setling receive operations (Reglera mottagningsåtgärder).

Ämnen och prenumerationer

En kö tillåter bearbetning av ett meddelande av en enskild konsument. Till skillnad från köer tillhandahåller ä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 registrerats med ämnet. Publisher ett meddelande till ett ämne och en eller flera prenumeranter får en kopia av meddelandet, beroende på vilka filterregler som har angetts för dessa prenumerationer. Prenumerationerna kan använda ytterligare 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 konsumenter får inte meddelanden direkt från ämnet. I stället får konsumenter meddelanden från prenumerationer på ämnet. En ämnesprenumeration liknar en virtuell kö som tar emot kopior av meddelanden som skickas till ämnet. Konsumenter får meddelanden från en prenumeration identiskt med hur de tar emot meddelanden från en kö.

Funktionen för att skicka meddelanden i en kö mappar direkt till ett ämne och dess funktioner för meddelandeleverans 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, tidsbestämd 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 hjälp Azure Portal, PowerShell, CLI eller Resource Manager mallar. Skicka sedan meddelanden till ett ämne och ta emot meddelanden från prenumerationer med klienter som skrivits i C#, Java, Pythonoch JavaScript.

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 i dessa egenskaper. Även Service Bus prenumerationer ser alla meddelanden som skickas till ämnet kan du bara kopiera en delmängd av dessa meddelanden till den virtuella prenumerationskön. Den här filtreringen åstadkoms 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å egenskaperna för meddelandet. Egenskaperna kan vara både systemegenskaperna (till exempel Etikett) och anpassade programegenskaper (till exempel StoreName.) Det 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 exempel finns i TopicFilters-exemplet 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 API:et Java Message Service (JMS) 2.0.

  • Tillfälliga köer
  • Tillfälliga ämnen
  • Delade beständiga prenumerationer
  • Icke-delade beständiga prenumerationer
  • Delade icke-varaktiga prenumerationer
  • Icke-varaktiga prenumerationer som inte delats

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

Nästa steg

Prova exemplen på det språk du väljer för att utforska Azure Service Bus funktioner.

Hitta exempel för äldre .NET- och Java-klientbibliotek nedan: