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

Den här artikeln analyserar skillnaderna och likheterna mellan de två typerna av köer som erbjuds av Microsoft Azure: Lagringsköer och Service Bus-köer. Genom att använda 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 är en del av 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, förtroendedomä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 vid val av teknik

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 bestämmer 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ö.
  • Ditt program 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 för mottagning med hjälp av de TCP-baserade protokoll som Service Bus stöder.
  • Din lösning kräver att kön tillhandahåller en garanterad FIFO-ordnad leverans (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 konsumerande programmet om strömmar, till skillnad från meddelanden. När en dataström ges till en förbrukande nod kan noden undersöka tillståndet för programströmmens tillstånd 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:
  • Köstorleken blir inte större än 80 GB.
  • Du vill använda det standardbaserade meddelandeprotokollet 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 publicera/prenumerera. Det här mönstret möjliggör integrering av ytterligare mottagare (prenumeranter). Varje mottagare får oberoende kopior av antingen vissa eller alla meddelanden som skickas till kön.
  • Meddelandelösningen måste ha stöd för leveransgarantierna "Högst en gång" och "Minst en gång" utan att du behöver skapa de ytterligare infrastrukturkomponenterna.
  • 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 gör att du snabbt kan 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.

Jämförelsevillkor Lagringsköer Service Bus-köer
Beställningsgaranti No

Mer information finns i den första anteckningen i avsnittet Ytterligare information .
Ja – Först in först ut (FIFO)

(med hjälp av meddelandesessioner)
Leveransgaranti Minst en gång Minst en gång (med PeekLock-mottagningsläge. Det är standardinställningen)

Högst en gång (med mottagningsläget ReceiveAndDelete)

Läs mer om olika mottagningslägen
Stöd för atomisk åtgärd Inga Ja

Ta emot beteende Icke-blockerande

(slutförs omedelbart om inget nytt meddelande hittas)
Blockera med eller utan tidsgräns

(erbjuder lång avsökning eller komettekniken)

Icke-blockerande

(endast med .NET-hanterat API)
API för push-format Inga Ja

Våra .NET-, Java-, JavaScript- och Go-SDK:er tillhandahåller API i push-format.
Mottagningsläge Granska & lån Granska & lås

Ta emot & borttagning
Exklusivt åtkomstläge Lånebaserad Låsbaserad
Låne-/låsvaraktighet 30 sekunder (standard)

7 dagar (max) (Du kan förnya eller släppa ett meddelandelån med hjälp av UpdateMessage-API :et.)
30 sekunder (standard)

Du kan förnya meddelandelåset under samma låstid varje gång manuellt eller använda funktionen för automatisk förnyelse av lås där klienten hanterar låsförnyelse åt dig.
Låne-/låsprecision Meddelandenivå

Varje meddelande kan ha olika timeout-värde, som du sedan kan uppdatera efter behov när du bearbetar meddelandet, med hjälp av UpdateMessage-API :et.
Könivå

(varje kö har en låsprecision som tillämpas på alla dess meddelanden, men låset kan förnyas enligt beskrivningen i föregående rad)
Batchbaserad mottagning Yes

(ange explicit antal meddelanden när meddelanden hämtas, upp till högst 32 meddelanden)
Yes

(implicit aktivera en förhämtningsegenskap eller explicit med hjälp av transaktioner)
Skicka i batch Inga Ja

(med hjälp av transaktioner eller batchbearbetning på klientsidan)

Ytterligare information

  • Meddelanden i Lagringsköer är vanligtvis först in först ut, men ibland kan de vara i fel ordning. Till exempel när varaktigheten för tidsgränsen för ett meddelande 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 arbetsroll kan ta bort det från kön. Då kan det nyligen synliga meddelandet placeras i kön för att tas bort från kön igen.
  • Det garanterade FIFO-mönstret i Service Bus-köer kräver att meddelandesessioner används. Om programmet kraschar när det bearbetar ett meddelande som tas emot i Peek & Lock-läget , nästa gång en kömottagare accepterar en meddelandesession, börjar det med det misslyckade meddelandet när meddelandets TTL-period (Time To Live) upphör att gälla.
  • Lagringsköer är utformade för att stödja vanliga kö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 kvitta mottagna meddelanden och uppdatera sessionstillståndet. Den här typen av konsekvensfunktion märks ibland exakt en gång i bearbetningen av andra leverantörers produkter. Eventuella transaktionsfel gör naturligtvis 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 för köer, tabeller och blobar – 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 enskild 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 upprätthå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 placeras i kö eller avskreparas. Du kan också uppdatera ett meddelande med olika lånevärden vid körning och uppdatera olika värden för 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 förnyelse av lås 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 maxvärde på 55 sekunder.
  • Batchbearbetning på klientsidan som tillhandahålls av Service Bus gör det möjligt för en köklient att skicka flera meddelanden till en enda sändningsåtgärd. Batchbearbetning är endast tillgängligt för asynkrona sändningsåtgärder.
  • Funktioner som taket på 200 TB i Lagringsköer (mer när du virtualiserar konton) och obegränsade köer gör det till en perfekt plattform för SaaS-leverantörer.
  • Lagringsköer ger en flexibel och högpresterande mekanism för delegerad åtkomstkontroll.

Avancerade funktioner

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

Jämförelsevillkor Lagringsköer Service Bus-köer
Schemalagd leverans Ja Ja
Automatisk obeställbara bokstäver Inga Ja
Öka värdet för time to live i kön Yes

(via på plats-uppdatering av synlighetstimeout)
Yes

(tillhandahålls via en dedikerad API-funktion)
Stöd för giftmeddelanden Ja Ja
Uppdatering på plats Ja Ja
Transaktionslogg på serversidan Ja Inga
Lagringsmått Yes

Minutmått tillhandahåller realtidsmått för tillgänglighet, TPS, antal API-anrop, antal fel med mera. De är alla i realtid, aggregerade per minut och rapporteras inom några minuter från det som just hände i produktionen. Mer information finns i Om mått för lagringsanalys.
Yes

Information om mått som stöds av Azure Service Bus finns i Meddelandemått.
Tillståndshantering No Ja (aktiv, inaktiverad, SendDisabled, ReceiveDisabled. Mer information om dessa tillstånd finns i Köstatus)
Automatisk avskogning av meddelanden Inga Ja
Rensa köfunktion Ja Inga
Meddelandegrupper Inga Ja

(med hjälp av meddelandesessioner)
Programtillstånd per meddelandegrupp Inga Ja
Dubblettidentifiering Inga Ja

(kan konfigureras på avsändarsidan)
Bläddra bland meddelandegrupper Inga Ja
Hämtar meddelandesessioner efter ID Inga Ja

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 spara tillståndsinformation och inkrementella förloppsuppdateringar i meddelandet så att den kan bearbetas från den senast kända kontrollpunkten i stället för 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 finns kvar i kön. Med Service Bus flyttas meddelandet till en särskild kö som heter $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 ett meddelande avmarkeras. 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 prestandajustering av 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 dubblettmeddelanden 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.

Jämförelsevillkor Lagringsköer Service Bus-köer
Maximal köstorlek 500 TB

(begränsat till en enda lagringskontokapacitet)
1 GB till 80 GB

(definieras när en kö skapas och partitionering aktiveras – se avsnittet "Ytterligare information")
Maximal meddelandestorlek 64 kB

(48 kB när du använder Base64-kodning)

Azure stöder stora meddelanden genom att kombinera köer och blobar – då kan du ställa in upp till 200 GB för ett enda objekt.
256 KB eller 100 MB

(inklusive både sidhuvud och brödtext, maximal rubrikstorlek: 64 kB).

Beror på tjänstnivån.
Högsta TTL-meddelande Infinite (api-version 2017-07-27 eller senare) TimeSpan.MaxValue
Maximalt antal köer Obegränsat 10 000

(per tjänstnamnområde)
Maximalt antal samtidiga klienter Obegränsat 5 000

Ytterligare information

  • Service Bus tillämpar köstorleksgränser. Den maximala köstorleken anges när du skapar en kö. Den 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.
  • Partitionering stöds inte på Premium-nivån. 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 partitioneringen är aktiverad skapar Service Bus 16 kopior (16 partitioner) av entiteten, var och en av samma storlek som angetts. Om du skapar en kö som har en storlek på 5 GB 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 över TCP-protokollet är det maximala antalet samtidiga anslutningar till en enda Service Bus-kö begränsat 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 tillämpas inte på 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 åtgärder

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

Jämförelsevillkor Lagringsköer Service Bus-köer
Hanteringsprotokoll REST över HTTP/HTTPS REST över HTTPS
Körningsprotokoll REST över HTTP/HTTPS REST över HTTPS

AMQP 1.0 Standard (TCP med TLS)
.NET-API Yes

(.NET Storage Client API)
Yes

(.NET Service Bus API)
Ursprunglig C++ Ja Ja
Java-API Ja Ja
PHP API Ja Ja
Node.js-API Ja Ja
Stöd för godtyckliga metadata Ja Inga
Namngivningsregler för köer Upp till 63 tecken långt

(Bokstäver i ett könamn måste vara gemener.)
Upp till 260 tecken långt

(Kösökvägar och namn är skiftlägesokänsliga.)
Hämta kölängdsfunktion Yes

(Ungefärligt värde om meddelanden upphör att gälla utöver TTL-värdet utan att tas bort.)
Yes

(Exakt, punkt-i-tid-värde.)
Funktionen Peek Ja Ja

Ytterligare information

  • Lagringsköer har 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 dig 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.
  • Asynkrona meddelande-API:er för Service Bus .NET använder TCP-anslutningar med full duplex för bättre prestanda jämfört med REST över HTTP, och de stöder standardprotokollet AMQP 1.0.
  • Namnen på Lagringsköer kan vara mellan 3 och 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 funktioner för autentisering och auktorisering som stöds av Lagringsköer och Service Bus-köer.

Jämförelsevillkor Lagringsköer Service Bus-köer
Autentisering Symmetrisk nyckel och rollbaserad åtkomstkontroll (RBAC) Symmetrisk nyckel och rollbaserad åtkomstkontroll (RBAC)
Identitetsproviderfederation Ja Ja

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 Azure Active Directory (Azure AD). Auktorisering av användare eller program med OAuth 2.0-token som returneras av Azure AD ger överlägsen säkerhet och användarvänlighet över signaturer för delad åtkomst (SAS). Med Azure AD behöver du inte lagra token i din kod och riskera potentiella säkerhetsproblem. Mer information finns i Azure Storage – Azure AD-autentisering och Azure Service Bus – Azure AD-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 kan vara mycket beroende av de enskilda behoven i ditt program och dess arkitektur.

Du kanske föredrar att välja Lagringsköer av följande skäl:

  • 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 val om du skapar ett hybridprogram eller om ditt program annars kräver dessa funktioner.

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.