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

Den här artikeln analyserar skillnader och likheter mellan de två typer av köer som erbjuds av Microsoft Azure: Storage köer 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: Storage köer och Service Bus köer.

Storage köer ingår i den 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 eftersläpning för arbete som ska bearbetas asynkront. Mer information finns i Vad är Azure Storage köer.

Service Bus är en del av en bredare Azure-meddelandeinfrastruktur som stöder köer, publicera/prenumerera och mer avancerade integreringsmö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 hur Service Bus/ämnen/prenumerationer finns i Service Bus, ämnen och prenumerationer.

Överväganden för val av teknik

Storage kö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 avgör 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 Storage köer

Som lösningsarkitekt/utvecklare bör du överväga att använda Storage kö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 arbetsrollen som bearbetar ett meddelande kraschar. En annan arbetsroll kan sedan använda informationen för att fortsätta där den tidigare arbetsrollen 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 polla 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 TCP-baserade protokoll som Service Bus stöder.
• Din lösning kräver att kön tillhandahåller en garanterad först-in-först-ut-leverans (FIFO).
• 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 dataström med hjälp av sessions-ID-egenskapen för meddelandet). I den här modellen konkurrerar varje nod i det konsumerande 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 programmets strömtillstånd med hjälp av transaktioner.
• Din lösning kräver transaktionellt beteende och atomicitet när du skickar eller tar emot flera meddelanden från en kö.
• Programmet hanterar meddelanden som kan överskrida 64 kB men som sannolikt inte närmar sig gränsen på 256 KB.
• 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
• Din köstorlek blir inte större än 80 GB.
• Du vill använda standardbaserat meddelandeprotokoll för AMQP 1.0. Mer information om AMQP finns i Service Bus AMQP Overview ( Översikt över AMQP).
• Du kan föreställa dig en eventuell migrering från köbaserad punkt-till-punkt-kommunikation till ett meddelandemönster som publicera/prenumererar. 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 leveransgarantin "Högst 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öra Storage kö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 funktionerna som är tillgängliga i både Azure Storage 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 Storage köer och Service Bus köer.

Ytterligare information

• Meddelanden i Storage köer är vanligtvis först in först ut, men ibland kan de vara i fel ordning. Till exempel när varaktigheten för synlighets-timeout för ett meddelande upphör att gälla eftersom ett klientprogram kraschade under bearbetningen av ett meddelande. När tidsgränsen för synlighet upphör att gälla visas meddelandet igen i kön så att en annan arbetsroll tar 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 användning av meddelandesessioner. Om programmet kraschar när det bearbetar ett meddelande som tas emot i läget Granska &-lås, startar en kömottagare en meddelandesession nästa gång den tar emot en meddelandesession med det misslyckade meddelandet när meddelandets TTL-period (Time to Live) går ut.
• Storage köer är utformade för att stödja vanliga köscenarier, till exempel följande:
  • Frikoppla programkomponenter för att öka skalbarheten och toleransen för fel
  • Belastningsutjämning
  • Skapa processarbetsflöden.
• Inkonsekvenser gällande 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 för att ange mottagna meddelanden och uppdatera sessionstillståndet. Den här typen av konsekvensfunktion märks ibland exakt en gång i bearbetning i andra leverantörers produkter. Eventuella transaktionsfel leder naturligtvis till att meddelanden skickas igen och det är därför termen inte är exakt tillräcklig.
• Storage köer ger en enhetlig och konsekvent programmeringsmodell för köer, tabeller ochBLOB– både för utvecklare och för driftteam.
• Service Bus köer ger stöd för lokala transaktioner i kontexten för en enda kö.
• I läget Ta emot och ta bort som stöds av Service Bus kan du minska antalet meddelandeoperationer (och tillhörande kostnader) i utbyte mot lägre leveranssäkerhet.
• Storage köer ger lån med möjlighet att utöka lån för meddelanden. Med den här funktionen kan arbetsprocesser upprätthålla korta lån på meddelanden. Så om en arbetsroll kraschar kan meddelandet snabbt bearbetas igen av en annan arbetsroll. Dessutom kan en arbetsroll utöka lånet för ett meddelande om det behöver bearbetas längre än den aktuella lånetiden.
• Storage köer ger en tidsgräns för synlighet som du kan ange när ett meddelande tas i kö eller tas bort från kön. Du kan också uppdatera ett meddelande med olika lånevärden vid körning och uppdatera olika värden mellan meddelanden i samma kö. Service Bus tidsgränser för lås definieras i kömetadata. Du kan dock förnya meddelandelåset för den fördefinierade låstiden 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 tidsgränser har dock ett maxvärde på 55 sekunder.
• Batchbearbetning på klientsidan som tillhandahålls Service Bus en köklient kan batcha 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 för Storage köer (mer när du virtualiserar konton) och obegränsade köer gör det till en utmärkt plattform för SaaS-leverantörer.
• Storage köer ger en flexibel och performant delegerad åtkomstkontrollmekanism.

Avancerade funktioner

Det här avsnittet jämför avancerade funktioner som tillhandahålls av Storage kö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.
• Autoforwarding av köer gör att tusentals köer automatiskt kan skicka 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.
• Storage köer ger 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 det kan bearbetas från den senaste 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 dead lettering. 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å sitt mål 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ö med namnet $DeadLetterQueue TTL-perioden upphör att gälla.
• För att hitta "skadligt" meddelanden Storage köer undersöker programmet meddelandets dequeueCount-egenskap när ett meddelande tas bort från kön. Om DequeueCount är större än ett visst tröskelvärde flyttar programmet meddelandet till en programdefinierad kö för "dead letter".
• Storage kö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 Storage köer. De är också användbara för prestandajustering av ditt program och för att minska kostnaderna för att använda köer.
• Meddelandesessioner som stöds Service Bus att meddelanden som tillhör en logisk grupp kan associeras med en mottagare. Den 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 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 Storage jämförs Service Bus köer ur kapacitets- och kvotperspektivet som kan gälla.

Ytterligare information

• Service Bus tillämpar storleksgränser för köer. Den maximala köstorleken anges när du skapar en kö. Det kan vara mellan 1 GB och 80 GB. Om kön 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å. På standardmeddelandenivån kan du skapa Service Bus köer och ämnen i 1 (standard), 2, 3, 4 eller 5 GB. När partitionering är aktiverat Service Bus 16 kopior (16 partitioner) av entiteten, var och en med samma angivna storlek. 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 för din partitionerade kö eller ditt ämne i Azure Portal.
• Med Storage köer måste innehållet i meddelandet vara Base64-kodat om innehållet i meddelandet inte är XML-säkert. Om du base64-kodar meddelandet kan användarens nyttolast vara upp till 48 KB, i stället för 64 KB.
• När Service Bus köer består varje meddelande som lagras i en kö av två delar: en rubrik och en brödtext. Den totala storleken på meddelandet får inte överskrida den maximala meddelandestorleken som stöds av tjänstnivån.
• När klienter kommunicerar Service Bus köer via TCP-protokollet är det maximala antalet samtidiga anslutningar till en enskild Service Bus-kö begränsat till 100. Det här numret delas mellan avsändare och mottagare. Om kvoten uppnås avvisas begäranden om ytterligare anslutningar och ett undantag tas emot av den anropande koden. Den här gränsen gäller inte 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 namnrymder med hjälp av Azure Portal.

Hantering och åtgärder

I det här avsnittet jämförs de hanteringsfunktioner som tillhandahålls Storage köer och Service Bus köer.

Ytterligare information

• Storage köer ger stöd för godtyckliga attribut som kan tillämpas på köbeskrivningen i form av namn-/värdepar.
• 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öutforskaren/webbläsarverktyg.
• De Service Bus .NET-API:erna för a brokered messaging använder full duplex TCP-anslutningar för bättre prestanda jämfört med REST över HTTP, och de stöder AMQP 1.0-standardprotokollet.
• Namnen på Storage kö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 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 Storage kö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 SASkan du hantera det här scenariot genom att publicera en skrivskyddad SAS, skrivskyddad SAS eller till och med en SAS med fullständig åtkomst.
• Autentiseringsschemat som tillhandahålls av Storage köer omfattar användning av en symmetrisk nyckel. Den här nyckeln är en hash-baserad Message Authentication Code (HMAC), som beräknas med SHA-256-algoritmen och kodas som en Base64-sträng. Mer information om respektive protokoll finns i Autentisering för Azure Storage Services. Service Bus har stöd för en liknande modell med symmetriska nycklar. Mer information finns i Autentisering med signatur för delad åtkomst med Service Bus.

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 du ska använda Storage köer eller Service Bus köer 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 Storage köer av skäl 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

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

• Sessioner
• Transaktioner
• Dubblettidentifiering
• Automatisk dead-lettering
• Varaktiga publicerings- och prenumerationsfunktioner

Nästa steg

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

• Komma igång med Service Bus-köer
• Så här använder du Queue Storage Service
• Metodtips för prestandaförbättringar med hjälp Service Bus a brokered messaging