Storage-köer och Service Bus-köer – jämförelser och skillnader

Den här artikeln analyserar skillnaderna och likheterna mellan de två typer av köer som erbjuds av Microsoft Azure: Lagringsköer och Service Bus-köer. Med hjälp av den här informationen kan du fatta ett mer välgrundat beslut om vilken lösning som bäst uppfyller dina behov.

Introduktion

Azure stöder två typer av kömekanismer: lagringsköer och Service Bus-köer.

Lagringsköer ingår i Azure Storage-infrastrukturen . De gör att du kan lagra ett stort antal meddelanden. Du kommer åt meddelanden var som helst i världen via autentiserade anrop med HTTP eller HTTPS. Ett kömeddelande kan vara upp till 64 KB stort. En kö kan innehålla miljontals meddelanden, upp till den totala kapacitetsgränsen för ett lagringskonto. Köer används ofta för att skapa en kvarvarande arbetslogg för att bearbeta asynkront. Mer information finns i Vad är Azure Storage-köer.

Service Bus-köer är en del av en bredare Azure-meddelandeinfrastruktur som stöder köer, publicera/prenumerera och mer avancerade integrationsmönster. De är utformade för att integrera program eller programkomponenter som kan omfatta flera kommunikationsprotokoll, datakontrakt, betrodda domäner eller nätverksmiljöer. Mer information om Service Bus-köer/ämnen/prenumerationer finns i Service Bus-köer, ämnen och prenumerationer.

Överväganden för teknikval

Lagringsköer och Service Bus-köer har en något annorlunda funktionsuppsättning. Du kan välja antingen en eller båda, beroende på behoven för din specifika lösning.

När du fastställer vilken köteknik som passar syftet med en viss lösning bör lösningsarkitekter och utvecklare överväga dessa rekommendationer.

Överväg att använda lagringsköer

Som lösningsarkitekt/-utvecklare bör du överväga att använda lagringsköer när:

• Programmet måste lagra över 80 gigabyte meddelanden i en kö.
• Programmet vill spåra förloppet för bearbetning av ett meddelande i kön. Det är användbart om arbetaren som bearbetar ett meddelande kraschar. En annan arbetare kan sedan använda den informationen för att fortsätta där den tidigare arbetaren slutade.
• Du behöver loggar på serversidan för alla transaktioner som körs mot dina köer.

Överväg att använda Service Bus-köer

Som lösningsarkitekt/-utvecklare bör du överväga att använda Service Bus-köer när:

• Din lösning måste ta emot meddelanden utan att behöva avsöka kön. Med Service Bus kan du uppnå det genom att använda en lång avsökningsåtgärd med hjälp av TCP-baserade protokoll som Service Bus stöder.
• Din lösning kräver att kön tillhandahåller en garanterad fifo-orderleverans (first-in-first-out).
• Din lösning måste ha stöd för automatisk dubblettidentifiering.
• Du vill att programmet ska bearbeta meddelanden som parallella långvariga strömmar (meddelanden är associerade med en ström med hjälp av sessions-ID-egenskapen i meddelandet). I den här modellen konkurrerar varje nod i det förbrukande programmet om strömmar, i stället för meddelanden. När en dataström ges till en förbrukande nod kan noden undersöka tillståndet för programströmstillståndet med hjälp av transaktioner.
• Din lösning kräver transaktionsbeteende och atomicitet när du skickar eller tar emot flera meddelanden från en kö.
• Ditt program hanterar meddelanden som kan överskrida 64 KB men som sannolikt inte närmar sig gränsen på 256 KB eller 1 MB, beroende på den valda tjänstnivån (även om Service Bus-köer kan hantera meddelanden upp till 100 MB).
• Du hanterar ett krav på att tillhandahålla en rollbaserad åtkomstmodell till köerna och olika rättigheter/behörigheter för avsändare och mottagare. Mer information finns i följande artiklar:
  • Autentisera med hanterade identiteter
  • Autentisera från ett program
• Köstorleken blir inte större än 80 GB.
• Du vill använda standardbaserat meddelandeprotokoll för AMQP 1.0. Mer information om AMQP finns i Översikt över Service Bus AMQP.
• Du föreställer dig en eventuell migrering från köbaserad punkt-till-punkt-kommunikation till ett meddelandemönster för publicering och prenumeration. Det här mönstret möjliggör integrering av ytterligare mottagare (prenumeranter). Varje mottagare tar emot oberoende kopior av antingen vissa eller alla meddelanden som skickas till kön.
• Din meddelandelösning måste ha stöd för leveransgarantierna "Högst en gång" och "Minst en gång" utan att du behöver skapa ytterligare infrastrukturkomponenter.
• Din lösning måste publicera och använda batchar med meddelanden.

Jämför lagringsköer och Service Bus-köer

Tabellerna i följande avsnitt innehåller en logisk gruppering av köfunktioner. De låter dig snabbt jämföra de funktioner som är tillgängliga i både Azure Storage-köer och Service Bus-köer.

Grundläggande funktioner

I det här avsnittet jämförs några av de grundläggande köfunktionerna som tillhandahålls av lagringsköer och Service Bus-köer.

Ytterligare information

• Meddelanden i lagringsköer är vanligtvis först-i-först-ut, men ibland kan de vara ur ordning. Till exempel när tidsgränsen för ett meddelandes synlighet upphör att gälla eftersom ett klientprogram kraschade när ett meddelande bearbetades. När tidsgränsen för synlighet upphör att gälla blir meddelandet synligt igen i kön så att en annan arbetare kan ta bort det. Då kan det nyligen synliga meddelandet placeras i kön för att dequeueras igen.
• Det garanterade FIFO-mönstret i Service Bus-köer kräver användning av meddelandesessioner. Om programmet kraschar när det bearbetar ett meddelande som tagits emot i läget Peek &Lock börjar det med det misslyckade meddelandet när sessionens låstid upphör att gälla nästa gång en kömottagare accepterar en meddelandesession.
• Lagringsköer är utformade för att stödja standardköscenarier, till exempel följande:
  • Avkoppling av programkomponenter för att öka skalbarheten och toleransen för fel
  • Belastningsutjämning
  • Skapa processarbetsflöden.
• Inkonsekvenser när det gäller meddelandehantering i samband med Service Bus-sessioner kan undvikas genom att använda sessionstillstånd för att lagra programmets tillstånd i förhållande till förloppet för hanteringen av sessionens meddelandesekvens, och genom att använda transaktioner kring att lösa mottagna meddelanden och uppdatera sessionstillståndet. Den här typen av konsekvensfunktion är ibland märkt exakt en gång bearbetning i andra leverantörers produkter. Eventuella transaktionsfel kommer naturligtvis att leda till att meddelanden skickas på nytt och det är därför termen inte är exakt tillräcklig.
• Lagringsköer ger en enhetlig och konsekvent programmeringsmodell i köer, tabeller och BLOB-filer – både för utvecklare och för driftsteam.
• Service Bus-köer ger stöd för lokala transaktioner i kontexten för en enda kö.
• Läget Ta emot och ta bort som stöds av Service Bus ger möjlighet att minska antalet meddelandeåtgärder (och tillhörande kostnad) i utbyte mot sänkt leveranssäkerhet.
• Lagringsköer ger lån med möjlighet att utöka lånen för meddelanden. Med den här funktionen kan arbetsprocesserna underhålla korta lån på meddelanden. Så om en arbetare kraschar kan meddelandet snabbt bearbetas igen av en annan arbetare. En arbetare kan också utöka lånet för ett meddelande om det behöver bearbetas längre än den aktuella lånetiden.
• Lagringsköer ger en synlighetstimeout som du kan ställa in när ett meddelande ska lagras eller dequeuas. Du kan också uppdatera ett meddelande med olika lånevärden vid körning och uppdatera olika värden mellan meddelanden i samma kö. Tidsgränser för Service Bus-lås definieras i kömetadata. Du kan dock förnya meddelandelåset för den fördefinierade låsvaraktigheten manuellt eller använda funktionen för automatisk låsförnyelse där klienten hanterar låsförnyelse åt dig.
• Den maximala tidsgränsen för en blockerande mottagningsåtgärd i Service Bus-köer är 24 dagar. REST-baserade timeouter har dock ett maximalt värde på 55 sekunder.
• Batchbearbetning på klientsidan som tillhandahålls av Service Bus gör det möjligt för en köklient att batcha flera meddelanden i en enda sändningsåtgärd. Batchbearbetning är endast tillgängligt för asynkrona sändningsåtgärder.
• Funktioner som taket på 200 TB för lagringsköer (mer när du virtualiserar konton) och obegränsade köer gör det till en idealisk plattform för SaaS-leverantörer.
• Lagringsköer ger en flexibel och högpresterande delegerad åtkomstkontrollmekanism.

Avancerade funktioner

I det här avsnittet jämförs avancerade funktioner som tillhandahålls av lagringsköer och Service Bus-köer.

Ytterligare information

• Båda köteknikerna gör att ett meddelande kan schemaläggas för leverans vid ett senare tillfälle.
• Med autoforwarding av köer kan tusentals köer automatisktforwarda sina meddelanden till en enda kö, från vilken det mottagande programmet använder meddelandet. Du kan använda den här mekanismen för att uppnå säkerhet, kontrollflöde och isolera lagring mellan varje meddelandeutgivare.
• Lagringsköer har stöd för uppdatering av meddelandeinnehåll. Du kan använda den här funktionen för att bevara tillståndsinformation och stegvisa förloppsuppdateringar i meddelandet så att den kan bearbetas från den senast kända kontrollpunkten i stället för att börja från början. Med Service Bus-köer kan du aktivera samma scenario med hjälp av meddelandesessioner. Mer information finns i Meddelandesessionstillstånd.
• Service Bus-köer stöder obeställbara bokstäver. Det kan vara användbart för att isolera meddelanden som uppfyller följande kriterier:
  • Meddelanden kan inte bearbetas av det mottagande programmet
  • Meddelanden kan inte nå målet på grund av en TTL-egenskap (time to live). TTL-värdet anger hur länge ett meddelande ska vara kvar i kön. Med Service Bus flyttas meddelandet till en särskild kö med namnet $DeadLetterQueue när TTL-perioden upphör att gälla.
• Om du vill hitta "gift"-meddelanden i lagringsköer undersöker programmet dequeueCount-egenskapen för meddelandet när du tar bort ett meddelande. Om DequeueCount är större än ett visst tröskelvärde flyttar programmet meddelandet till en programdefinierad kö med "död bokstav".
• Med lagringsköer kan du hämta en detaljerad logg över alla transaktioner som körs mot kön och aggregerade mått. Båda dessa alternativ är användbara för att felsöka och förstå hur ditt program använder lagringsköer. De är också användbara för att prestandajustera ditt program och minska kostnaderna för att använda köer.
• Meddelandesessioner som stöds av Service Bus gör det möjligt att associera meddelanden som tillhör en logisk grupp med en mottagare. Det skapar en sessionsliknande tillhörighet mellan meddelanden och deras respektive mottagare. Du kan aktivera den här avancerade funktionen i Service Bus genom att ange sessions-ID-egenskapen för ett meddelande. Mottagarna kan sedan lyssna på ett specifikt sessions-ID och ta emot meddelanden som delar den angivna sessionsidentifieraren.
• Funktionen för dupliceringsidentifiering i Service Bus-köer tar automatiskt bort duplicerade meddelanden som skickas till en kö eller ett ämne, baserat på värdet för meddelande-ID-egenskapen.

Kapacitet och kvoter

I det här avsnittet jämförs lagringsköer och Service Bus-köer utifrån kapacitet och kvoter som kan gälla.

Ytterligare information

• Service Bus tillämpar köstorleksgränser. Den maximala köstorleken anges när du skapar en kö. Det kan vara mellan 1 GB och 80 GB. Om köns storlek når den här gränsen avvisas ytterligare inkommande meddelanden och anroparen får ett undantag. Mer information om kvoter i Service Bus finns i Service Bus-kvoter.
• På meddelandenivån Standard kan du skapa Service Bus-köer och -ämnen i 1 (standard), 2, 3, 4 eller 5 GB storlekar. När du aktiverar partitionering på standardnivån skapar Service Bus 16 kopior (16 partitioner) av entiteten, var och en av samma storlek som angetts. Om du skapar en kö som är 5 GB stor, med 16 partitioner blir den maximala köstorleken (5 * 16) = 80 GB. Du kan se den maximala storleken på den partitionerade kön eller ämnet i Azure-portalen.
• Om innehållet i meddelandet inte är XML-säkert med Lagringsköer måste det vara Base64-kodat . Om du Base64-kodar meddelandet kan användarnyttolasten vara upp till 48 KB i stället för 64 KB.
• Med Service Bus-köer består varje meddelande som lagras i en kö av två delar: en rubrik och en brödtext. Meddelandets totala storlek får inte överskrida den maximala meddelandestorlek som stöds av tjänstnivån.
• När klienter kommunicerar med Service Bus-köer via TCP-protokollet är det maximala antalet samtidiga anslutningar till en enda Service Bus-kö begränsad till 100. Det här numret delas mellan avsändare och mottagare. Om den här kvoten nås avvisas begäranden om ytterligare anslutningar och ett undantag tas emot av den anropande koden. Den här gränsen gäller inte för klienter som ansluter till köerna med hjälp av REST-baserat API.
• Om du behöver fler än 10 000 köer i ett enda Service Bus-namnområde kan du kontakta Azure-supportteamet och begära en ökning. Om du vill skala över 10 000 köer med Service Bus kan du också skapa ytterligare namnområden med hjälp av Azure-portalen.

Hantering och drift

I det här avsnittet jämförs hanteringsfunktionerna som tillhandahålls av lagringsköer och Service Bus-köer.

Ytterligare information

• Lagringsköer ger stöd för godtyckliga attribut som kan tillämpas på köbeskrivningen i form av namn/värde-par.
• Båda köteknikerna ger möjlighet att granska ett meddelande utan att behöva låsa det, vilket kan vara användbart när du implementerar ett köutforskare/webbläsarverktyg.
• Service Bus .NET-asynkrona meddelande-API:er använder TCP-anslutningar med full duplex för bättre prestanda jämfört med REST via HTTP, och de stöder standardprotokollet AMQP 1.0.
• Namn på lagringsköer kan vara 3–63 tecken långa, kan innehålla gemener, siffror och bindestreck. Mer information finns i Namngivning av köer och metadata.
• Service Bus-könamn kan vara upp till 260 tecken långa och ha mindre restriktiva namngivningsregler. Service Bus-könamn kan innehålla bokstäver, siffror, punkter, bindestreck och understreck.

Autentisering och auktorisering

I det här avsnittet beskrivs de autentiserings- och auktoriseringsfunktioner som stöds av lagringsköer och Service Bus-köer.

Ytterligare information

• Varje begäran till någon av köteknikerna måste autentiseras. Offentliga köer med anonym åtkomst stöds inte.
• Med hjälp av sas-autentisering (signatur för delad åtkomst) kan du skapa en auktoriseringsregel för delad åtkomst i en kö som kan ge användarna skrivskyddad, skrivskyddad eller fullständig åtkomst. Mer information finns i Azure Storage – SAS-autentisering och Azure Service Bus – SAS-autentisering.
• Båda köerna stöder auktorisering av åtkomst med hjälp av Microsoft Entra-ID. Att auktorisera användare eller program med OAuth 2.0-token som returneras av Microsoft Entra ID ger överlägsen säkerhet och användarvänlighet för signaturer för delad åtkomst (SAS). Med Microsoft Entra-ID behöver du inte lagra token i koden och riskera potentiella säkerhetsrisker. Mer information finns i Azure Storage – Microsoft Entra-autentisering och Azure Service Bus – Microsoft Entra-autentisering.

Slutsats

Genom att få en djupare förståelse för de två teknikerna kan du fatta ett mer välgrundat beslut om vilken köteknik som ska användas och när. Beslutet om när lagringsköer eller Service Bus-köer ska användas beror helt klart på många faktorer. Dessa faktorer beror i hög grad på programmets individuella behov och dess arkitektur.

Du kanske föredrar att välja Lagringsköer av orsaker som följande:

• Om ditt program redan använder kärnfunktionerna i Microsoft Azure
• Om du behöver grundläggande kommunikation och meddelanden mellan tjänster
• Behöver köer som kan vara större än 80 GB i storlek

Service Bus-köer innehåller många avancerade funktioner, till exempel följande. De kan därför vara ett föredraget alternativ om du skapar ett hybridprogram eller om ditt program annars kräver dessa funktioner.

• Sessioner
• Transaktioner
• Dubblettidentifiering
• Automatisk obeställbara bokstäver
• Funktioner för beständig publicering och prenumeration

Nästa steg

Följande artiklar innehåller mer vägledning och information om hur du använder lagringsköer eller Service Bus-köer.

• Komma igång med Service Bus-köer
• Så här använder du kölagringstjänsten
• Metodtips för prestandaförbättringar med hjälp av asynkrona Service Bus-meddelanden