Storage-köer och Service Bus-köer – jämförelser och skillnaderStorage queues and Service Bus queues - compared and contrasted

Den här artikeln analyserar både skillnader och likheter mellan de två typerna av köer som erbjuds av Microsoft Azure idag: Storage-köer och Service Bus-köer.This article analyzes the differences and similarities between the two types of queues offered by Microsoft Azure today: Storage queues and Service Bus queues. Med hjälp av informationen kan du jämföra de olika teknikerna och fatta klokare beslut när du ska avgöra vilken lösning som passar dig bäst.By using this information, you can compare and contrast the respective technologies and be able to make a more informed decision about which solution best meets your needs.

IntroduktionIntroduction

Azure stöder två typer av kön mekanismer: Lagringsköer och Service Bus-köer.Azure supports two types of queue mechanisms: Storage queues and Service Bus queues.

Lagringsköer, vilket är en del av den Azure storage infrastruktur, funktionen ett enkelt REST-baserad GET/PUT/PEEK-gränssnitt för att tillhandahålla pålitlig, beständig meddelandetrafik inom och mellan tjänster.Storage queues, which are part of the Azure storage infrastructure, feature a simple REST-based GET/PUT/PEEK interface, providing reliable, persistent messaging within and between services.

Service Bus-köer är en del av en bredare Azure messaging infrastruktur som stöder queuing samt publicera/prenumerera på och mer avancerade integration mönster.Service Bus queues are part of a broader Azure messaging infrastructure that supports queuing as well as publish/subscribe, and more advanced integration patterns. Läs mer om Service Bus-köer/ämnen/prenumerationer, den översikt över Service Bus.For more information about Service Bus queues/topics/subscriptions, see the overview of Service Bus.

Även om båda queuing teknikerna finns samtidigt, introducerades lagringsköer först som en dedikerad kö storage mekanism som bygger på Azure Storage-tjänster.While both queuing technologies exist concurrently, Storage queues were introduced first, as a dedicated queue storage mechanism built on top of Azure Storage services. Service Bus-köer är byggda på bredare meddelandeinfrastrukturen för att integrera program eller programkomponenter som kan omfatta flera kommunikationsprotokoll, datakontrakt, betrodda domäner och nätverksmiljöer.Service Bus queues are built on top of the broader messaging infrastructure designed to integrate applications or application components that may span multiple communication protocols, data contracts, trust domains, and/or network environments.

Överväganden för val av teknikTechnology selection considerations

Både Storage-köer och Service Bus-köer är implementeringar av Meddelandeköer tjänst som för närvarande erbjuds av Microsoft Azure.Both Storage queues and Service Bus queues are implementations of the message queuing service currently offered by Microsoft Azure. Var och en har ett något annorlunda funktionsuppsättning, vilket innebär att du kan välja en av eller använda båda beroende på behoven i din lösning eller business-tekniska problem som du vill lösa.Each has a slightly different feature set, which means you can choose one or the other, or use both, depending on the needs of your particular solution or business/technical problem you are solving.

När du fastställer vilken queuing teknik passar syftet för den aktuella lösningen, bör de här rekommendationerna i lösningsarkitekter och utvecklare.When determining which queuing technology fits the purpose for a given solution, solution architects and developers should consider these recommendations. Mer information finns i nästa avsnitt.For more details, see the next section.

Som utvecklare/solution architect, bör du använda lagringsköer när:As a solution architect/developer, you should consider using Storage queues when:

  • Programmet måste lagra över 80 GB av meddelanden i en kö.Your application must store over 80 GB of messages in a queue.
  • Programmet vill spåra förloppet för bearbetning av ett meddelande i kön.Your application wants to track progress for processing a message inside of the queue. Detta är användbart om den arbetsroll som bearbetar ett meddelande som kraschar.This is useful if the worker processing a message crashes. En efterföljande worker kan sedan använda informationen för att fortsätta från där den tidigare worker slutade.A subsequent worker can then use that information to continue from where the prior worker left off.
  • Du behöver sida i loggarna för alla transaktioner som körs mot din köer.You require server side logs of all of the transactions executed against your queues.

Som utvecklare/solution architect, bör du använda Service Bus-köer när:As a solution architect/developer, you should consider using Service Bus queues when:

  • Lösningen måste kunna ta emot meddelanden utan att behöva söka i kön.Your solution must be able to receive messages without having to poll the queue. Med Service Bus, detta kan uppnås genom att använda-longpolling får igen med de TCP-baserade protokoll som stöds av Service Bus.With Service Bus, this can be achieved through the use of the long-polling receive operation using the TCP-based protocols that Service Bus supports.
  • Din lösning kräver kön att tillhandahålla en garanterad först-in-först-ut (FIFO) sorterade leverans.Your solution requires the queue to provide a guaranteed first-in-first-out (FIFO) ordered delivery.
  • Lösningen måste kunna stödja automatisk identifiering av dubbletter.Your solution must be able to support automatic duplicate detection.
  • Du vill att programmet att bearbeta meddelanden som parallella tidskrävande dataströmmar (meddelanden som är kopplade till en dataström med hjälp av den SessionId egenskap).You want your application to process messages as parallel long-running streams (messages are associated with a stream using the SessionId property on the message). Varje nod i den konsumerande appen konkurrerar om strömmar, till skillnad från meddelanden i den här modellen.In this model, each node in the consuming application competes for streams, as opposed to messages. När en dataström har tilldelats en konsumerande nod, undersöka noden tillståndet för stream programtillståndet med transaktioner.When a stream is given to a consuming node, the node can examine the state of the application stream state using transactions.
  • Din lösning kräver transaktionella beteende och Atomicitet när du skickar eller tar emot flera meddelanden från en kö.Your solution requires transactional behavior and atomicity when sending or receiving multiple messages from a queue.
  • Ditt program hanterar meddelanden som kan överskrida 64 KB men begränsas inte troligt metoden 256 KB.Your application handles messages that can exceed 64 KB but will not likely approach the 256 KB limit.
  • Du hantera ett krav att tillhandahålla en modell för rollbaserad åtkomst till köer och olika rights/behörigheter för sändare och mottagare.You deal with a requirement to provide a role-based access model to the queues, and different rights/permissions for senders and receivers.
  • Storleken på din kö växer inte större än 80 GB.Your queue size will not grow larger than 80 GB.
  • Du vill använda AMQP 1.0 standardiserade meddelanden-protokollet.You want to use the AMQP 1.0 standards-based messaging protocol. Läs mer om AMQP översikt för Service Bus AMQP.For more information about AMQP, see Service Bus AMQP Overview.
  • Du kan tänka på en eventuell migrering från Köbaserad point-to-point kommunikation med ett meddelande exchange-mönster som möjliggör sömlös integration av ytterligare mottagare (prenumeranter), som tar emot oberoende kopior av vissa eller alla meddelanden som skickas till kön.You can envision an eventual migration from queue-based point-to-point communication to a message exchange pattern that enables seamless integration of additional receivers (subscribers), each of which receives independent copies of either some or all messages sent to the queue. Det senare refererar till att publicera/prenumerera funktioner internt av Service Bus.The latter refers to the publish/subscribe capability natively provided by Service Bus.
  • Din meddelandelösning måste kunna stödja garanti om leverans för ”i de flesta – en gång” utan att behöva du skapa ytterligare infrastrukturkomponenter.Your messaging solution must be able to support the "At-Most-Once" delivery guarantee without the need for you to build the additional infrastructure components.
  • Du skulle vilja att kunna publicera och använda batchar av meddelanden.You would like to be able to publish and consume batches of messages.

Jämföra Storage-köer och Service Bus-köerComparing Storage queues and Service Bus queues

Tabellerna i följande avsnitt är en logisk gruppering av köfunktioner och kan du jämföra, på ett ögonblick, funktioner som ingår i både Azure Storage-köer och Service Bus-köer.The tables in the following sections provide a logical grouping of queue features and let you compare, at a glance, the capabilities available in both Azure Storage queues and Service Bus queues.

Grundläggande funktionerFoundational capabilities

Det här avsnittet jämför några av de grundläggande funktioner för meddelandeköer som tillhandahålls av Storage-köer och Service Bus-köer.This section compares some of the fundamental queuing capabilities provided by Storage queues and Service Bus queues.

JämförelsevillkorComparison Criteria Storage-köerStorage queues Service Bus-köerService Bus queues
Sorteringen garantiOrdering guarantee NejNo

Mer information finns i den första anteckningen i avsnittet ”Mer Information”.For more information, see the first note in the “Additional Information” section.
Ja - först-In-först-ut (FIFO)Yes - First-In-First-Out (FIFO)

(med hjälp av messaging sessioner)(through the use of messaging sessions)
Garanti om leveransDelivery guarantee På minst en gångAt-Least-Once På minst en gångAt-Least-Once

I de flesta – en gångAt-Most-Once
Stöd för atomisk åtgärdAtomic operation support NejNo JaYes

Ta emot beteendeReceive behavior Icke-blockerandeNon-blocking

(slutförs omedelbart om inget nytt meddelande hittas)(completes immediately if no new message is found)
Blockerar med och utan tidsgränsBlocking with/without timeout

(erbjuder longpolling eller ”Comet-tekniken”)(offers long polling, or the "Comet technique")

Icke-blockerandeNon-blocking

(med hjälp av .NET-hanterade API: et endast)(through the use of .NET managed API only)
Push-style-APIPush-style API NejNo JaYes

OnMessage och OnMessage sessioner .NET API.OnMessage and OnMessage sessions .NET API.
Ta emot lägeReceive mode Peek & lånPeek & Lease Peek & LåsPeek & Lock

Ta emot och ta bortReceive & Delete
Exklusivt lägeExclusive access mode Lån-baseradLease-based Lås-baseradLock-based
/ Utlämningslås varaktighetLease/Lock duration 30 sekunder (standard)30 seconds (default)

7 dagar (max) (du kan förnya eller frigöra en meddelande lån med hjälp av den UpdateMessage API.)7 days (maximum) (You can renew or release a message lease using the UpdateMessage API.)
60 sekunder (standard)60 seconds (default)

Du kan förnya ett meddelande Lås med den RenewLock API.You can renew a message lock using the RenewLock API.
/ Utlämningslås precisionLease/Lock precision MeddelandenivåMessage level

(varje meddelande kan ha ett annat timeout-värde som du kan sedan uppdatera efter behov när behandlingen av meddelandet med hjälp av den UpdateMessage API)(each message can have a different timeout value, which you can then update as needed while processing the message, by using the UpdateMessage API)
Kö-nivåQueue level

(varje kö har en Lås-precision som tillämpas på alla dess meddelanden, men du kan förnya låset med hjälp av den RenewLock API.)(each queue has a lock precision applied to all of its messages, but you can renew the lock using the RenewLock API.)
Batchar fårBatched receive JaYes

(uttryckligen anger antal meddelanden vid hämtning av meddelanden, upp till maximalt 32 meddelanden)(explicitly specifying message count when retrieving messages, up to a maximum of 32 messages)
JaYes

(implicit aktiverar en före fetch-egenskapen eller uttryckligen med hjälp av transaktioner)(implicitly enabling a pre-fetch property or explicitly through the use of transactions)
Satsvis skickaBatched send NejNo JaYes

(med hjälp av transaktioner eller klientsidan batchbearbetning)(through the use of transactions or client-side batching)

Ytterligare informationAdditional information

  • Meddelanden i Storage-köer är vanligtvis först-in-först-ut, men de kan ibland vara ur funktion, till exempel när ett meddelande synlighet tidslängden upphör att gälla (till exempel till följd av ett klientprogram som kraschar under bearbetning).Messages in Storage queues are typically first-in-first-out, but sometimes they can be out of order; for example, when a message's visibility timeout duration expires (for example, as a result of a client application crashing during processing). När synlighet tidsgränsen upphör blir meddelandet synligt igen i kön för en annan worker att ta bort från kön den.When the visibility timeout expires, the message becomes visible again on the queue for another worker to dequeue it. I det här läget kan nyligen visas meddelandet placeras i kö (för att vara tagits bort från kön igen) efter ett meddelande som ursprungligen i kön efter den.At that point, the newly visible message might be placed in the queue (to be dequeued again) after a message that was originally enqueued after it.
  • Garanterad FIFO-mönstret i Service Bus-köer måste du använda meddelanden sessioner.The guaranteed FIFO pattern in Service Bus queues requires the use of messaging sessions. I händelse av att programmet kraschar vid bearbetning av ett meddelande tas emot i den Granska & låsa läge, nästa gång en kö mottagare tar emot en meddelandesession, den börjar med misslyckade meddelandet efter dess time to live (TTL) period har löpt ut.In the event that the application crashes while processing a message received in the Peek & Lock mode, the next time a queue receiver accepts a messaging session, it will start with the failed message after its time-to-live (TTL) period expires.
  • Storage-köer är utformade för att stödja standard queuing scenarier, t.ex. Frikoppling programkomponenter att öka skalbarheten och tolerans för fel, läsa in Utjämning och utveckling av processarbetsflöden.Storage queues are designed to support standard queuing scenarios, such as decoupling application components to increase scalability and tolerance for failures, load leveling, and building process workflows.
  • Stöd för Service Bus-köer i på minst en gång garanti om leverans.Service Bus queues support the At-Least-Once delivery guarantee.
  • Inkonsekvenser avseende meddelandehantering i samband med Service Bus-sessioner kan undvikas genom att använda sessionstillstånd för att lagra programtillstånd i förhållande till förloppet hantera sessionens Meddelandeordningen och genom att använda transaktioner runt reglera emot meddelanden och uppdatera sessionens tillstånd.Inconsistencies with regard to message handling in the context of Service Bus sessions can be avoided by using session state to store the application's state relative to the progress of handling the session's message sequence, and by using transactions around settling received messages and updating the session state. Den här typen av konsekvens funktionen klassificerades ibland exakt-bearbetning av en gång fel leder naturligtvis meddelanden som levereras i andra leverantörens produkter, men transaktion och därför termen är inte exakt tillräckligt.This kind of consistency feature is sometimes labeled Exactly-Once Processing in other vendor's products, but transaction failures will obviously cause messages to be redelivered and therefore the term is not exactly adequate.
  • Storage-köer ger en enhetlig och konsekvent programmeringsmodell på köer, tabeller och Blobbar – både för utvecklare och för driftteam.Storage queues provide a uniform and consistent programming model across queues, tables, and BLOBs – both for developers and for operations teams.
  • Service Bus-köer ger stöd för lokala transaktioner i kontexten för en enskild kö.Service Bus queues provide support for local transactions in the context of a single queue.
  • Den ta emot och ta bort läge som stöds av Service Bus gör möjligheten att minska antal meddelanden (och associerade kostnader) i utbyte mot sänkt leverans assurance.The Receive and Delete mode supported by Service Bus provides the ability to reduce the messaging operation count (and associated cost) in exchange for lowered delivery assurance.
  • I lagringsköer finns lån med möjlighet att utöka lån för meddelanden.Storage queues provide leases with the ability to extend the leases for messages. På så sätt kan arbetare att underhålla korta lån på meddelanden.This allows the workers to maintain short leases on messages. Därför om en arbetsroll kraschar kan meddelandet snabbt bearbetas igen som en annan arbetsprocess.Thus, if a worker crashes, the message can be quickly processed again by another worker. Dessutom kan en worker förlänga lånet på ett meddelande om det behöver bearbeta den längre än den aktuella tiden för lånet.In addition, a worker can extend the lease on a message if it needs to process it longer than the current lease time.
  • Storage-köer erbjuder en synlighetstimeout som du kan ange vid enqueuing eller mellan köer för ett meddelande.Storage queues offer a visibility timeout that you can set upon the enqueuing or dequeuing of a message. Du kan också uppdatera ett meddelande med olika lånet värden vid körning och uppdatera olika värden över meddelanden i samma kö.In addition, you can update a message with different lease values at run-time, and update different values across messages in the same queue. Service Bus lås-timeout har definierats i kö metadata; men du kan förnya låset genom att anropa den RenewLock metod.Service Bus lock timeouts are defined in the queue metadata; however, you can renew the lock by calling the RenewLock method.
  • Den maximala tidsgränsen är för en blockerar mottagningsåtgärd i Service Bus-köer 24 dagar.The maximum timeout for a blocking receive operation in Service Bus queues is 24 days. REST-baserad tidsgränser har dock ett maxvärde 55 sekunder.However, REST-based timeouts have a maximum value of 55 seconds.
  • Klientsidan batchbearbetning tillhandahålls av Service Bus gör att klienter kön kan batch-flera meddelanden till en enda skicka-åtgärd.Client-side batching provided by Service Bus enables a queue client to batch multiple messages into a single send operation. Batchbearbetning är endast tillgängligt för skicka asynkrona åtgärder.Batching is only available for asynchronous send operations.
  • Funktioner, till exempel 200 TB taket lagringsköer (mer när du virtualisera konton) och ett obegränsat antal köer gör det en utmärkt plattform för SaaS-leverantörer.Features such as the 200 TB ceiling of Storage queues (more when you virtualize accounts) and unlimited queues make it an ideal platform for SaaS providers.
  • Storage-köer ger en flexibel och högpresterande delegerad åtkomstkontroll.Storage queues provide a flexible and performant delegated access control mechanism.

Avancerade funktionerAdvanced capabilities

Det här avsnittet jämför avancerade funktioner som tillhandahålls av Storage-köer och Service Bus-köer.This section compares advanced capabilities provided by Storage queues and Service Bus queues.

JämförelsevillkorComparison Criteria Storage-köerStorage queues Service Bus-köerService Bus queues
Schemalagd leveransScheduled delivery JaYes JaYes
Automatisk obeställbaraAutomatic dead lettering NejNo JaYes
Öka värdet för kön time-to-liveIncreasing queue time-to-live value JaYes

(via plats-uppdatering av synlighetstimeout)(via in-place update of visibility timeout)
JaYes

(tillhandahålls via en dedikerad API-funktion)(provided via a dedicated API function)
Skadliga meddelande supportPoison message support JaYes JaYes
Uppdatering på platsIn-place update JaYes JaYes
Transaktionsloggen för serversidanServer-side transaction log JaYes NejNo
Storage-måttStorage metrics JaYes

Minut mått: innehåller realtidsstatistisk för API för tillgänglighet, TPS, antal, antal fel med mera, allt i realtid (samman per minut och rapporterats inom några minuter från vad hände bara i produktion.Minute Metrics: provides real-time metrics for availability, TPS, API call counts, error counts, and more, all in real time (aggregated per minute and reported within a few minutes from what just happened in production. Mer information finns i om Storage Analytics mätvärden.For more information, see About Storage Analytics Metrics.
JaYes

(bulk frågor genom att anropa GetQueues)(bulk queries by calling GetQueues)
TillståndshanteringState management NejNo JaYes

Microsoft.ServiceBus.Messaging.EntityStatus.Active, Microsoft.ServiceBus.Messaging.EntityStatus.Disabled, Microsoft.ServiceBus.Messaging.EntityStatus.SendDisabled, Microsoft.ServiceBus.Messaging.EntityStatus.ReceiveDisabledMicrosoft.ServiceBus.Messaging.EntityStatus.Active, Microsoft.ServiceBus.Messaging.EntityStatus.Disabled, Microsoft.ServiceBus.Messaging.EntityStatus.SendDisabled, Microsoft.ServiceBus.Messaging.EntityStatus.ReceiveDisabled
Automatisk vidarebefordring av meddelandeMessage auto-forwarding NejNo JaYes
Rensa kön funktionPurge queue function JaYes NejNo
Meddelande-grupperMessage groups NejNo JaYes

(med hjälp av messaging sessioner)(through the use of messaging sessions)
Programtillstånd per meddelande gruppApplication state per message group NejNo JaYes
DubblettidentifieringDuplicate detection NejNo JaYes

(kan konfigureras på avsändarsidan)(configurable on the sender side)
Bläddra meddelande grupperBrowsing message groups NejNo JaYes
Hämtar meddelandesessioner efter IDFetching message sessions by ID NejNo JaYes

Ytterligare informationAdditional information

  • Båda teknikerna för meddelandeköer kan ett meddelande som ska schemaläggas för leverans vid ett senare tillfälle.Both queuing technologies enable a message to be scheduled for delivery at a later time.
  • Kön automatisk vidarebefordran kan tusentals olika köer för att skicka meddelanden till en enskild kö, varifrån det mottagande programmet förbrukar meddelandet automatisk vidarebefordring.Queue auto-forwarding enables thousands of queues to auto-forward their messages to a single queue, from which the receiving application consumes the message. Du kan använda den här mekanismen för att uppnå säkerhet, Kontrollflöde och isolera lagring mellan varje meddelande-utgivare.You can use this mechanism to achieve security, control flow, and isolate storage between each message publisher.
  • Storage-köer ger support för att uppdatera meddelandeinnehåll.Storage queues provide support for updating message content. Du kan använda den här funktionen för att bevara statusinformation och inkrementella statusuppdateringar till meddelandet så att de kan bearbetas från den senaste kända kontrollpunkten, i stället för att börja om från början.You can use this functionality for persisting state information and incremental progress updates into the message so that it can be processed from the last known checkpoint, instead of starting from scratch. Du kan aktivera för samma scenario genom att använda meddelandesessioner med Service Bus-köer.With Service Bus queues, you can enable the same scenario through the use of message sessions. Sessioner kan du spara och hämta programmets Bearbetningsstatus (med hjälp av SetState och GetState).Sessions enable you to save and retrieve the application processing state (by using SetState and GetState).
  • Död oljekategori, vilket är endast stöds av Service Bus-köer kan vara användbart för att isolera meddelanden som kan inte bearbetas av det mottagande programmet eller när meddelanden kan inte nå sitt mål på grund av en har upphört att gälla (time to live Egenskapen TTL).Dead lettering, which is only supported by Service Bus queues, can be useful for isolating messages that cannot be processed successfully by the receiving application or when messages cannot reach their destination due to an expired time-to-live (TTL) property. TTL-värdet anger hur länge ett meddelande finns kvar i kön.The TTL value specifies how long a message remains in the queue. Med Service Bus flyttas meddelandet till en särskild kö som kallas $DeadLetterQueue när TTL-perioden upphör.With Service Bus, the message will be moved to a special queue called $DeadLetterQueue when the TTL period expires.
  • Att hitta ”skadliga” meddelanden i Storage-köer, när mellan köer programmet går du igenom den DequeueCount för meddelandet.To find "poison" messages in Storage queues, when dequeuing a message the application examines the DequeueCount property of the message. Om DequeueCount är större än ett visst tröskelvärde programmet flyttar meddelandet till en programdefinierad ”” kö för obeställbara.If DequeueCount is greater than a given threshold, the application moves the message to an application-defined "dead letter" queue.
  • Storage-köer kan du få en detaljerad logg över alla transaktioner körs mot kön, som även som aggregerade mätvärden.Storage queues enable you to obtain a detailed log of all of the transactions executed against the queue, as well as aggregated metrics. Båda dessa alternativ är användbara för felsökning och förstå hur programmet använder Storage-köer.Both of these options are useful for debugging and understanding how your application uses Storage queues. De är också användbara för prestandajustering programmet och minska kostnaderna med köer.They are also useful for performance-tuning your application and reducing the costs of using queues.
  • Begreppet ”meddelandesessioner” stöds av Service Bus kan meddelanden som tillhör en viss logisk grupp som ska associeras med en viss mottagare, vilket i sin tur skapar en session-liknande tillhörighet mellan meddelanden och deras respektive mottagare.The concept of "message sessions" supported by Service Bus enables messages that belong to a certain logical group to be associated with a given receiver, which in turn creates a session-like affinity between messages and their respective receivers. Du kan aktivera den här avancerade funktioner i Service Bus genom att ange den SessionID egenskap på ett meddelande.You can enable this advanced functionality in Service Bus by setting the SessionID property on a message. Mottagare kan lyssna på en specifik sessions-ID och ta emot meddelanden som delar angivna sessions-ID.Receivers can then listen on a specific session ID and receive messages that share the specified session identifier.
  • Duplicering identifiering av funktioner som stöds av Service Bus-köer automatiskt tar bort dubbletter av meddelanden skickas till en kö eller ämne, baserat på värdet för den MessageId egenskapen.The duplication detection functionality supported by Service Bus queues automatically removes duplicate messages sent to a queue or topic, based on the value of the MessageId property.

Kapacitet och kvoterCapacity and quotas

Det här avsnittet jämför Storage-köer och Service Bus-köer ur kapacitet och kvoter som kan tillkomma.This section compares Storage queues and Service Bus queues from the perspective of capacity and quotas that may apply.

JämförelsevillkorComparison Criteria Storage-köerStorage queues Service Bus-köerService Bus queues
Maximal köstorlekMaximum queue size 500 TB500 TB

(begränsat till en enkel kapacitet för lagringskonton)(limited to a single storage account capacity)
1 GB till 80 GB1 GB to 80 GB

(definieras när den har skapats av en kö och aktiverar partitionering – finns i avsnittet ”Mer Information”)(defined upon creation of a queue and enabling partitioning – see the “Additional Information” section)
Största meddelandestorlekMaximum message size 64 KB64 KB

(48 KB när du använder Base64 kodning)(48 KB when using Base64 encoding)

Azure har stöd för stora meddelanden genom att kombinera köer och blobbar – då du kan sätta upp till 200 GB för ett enskilt objekt.Azure supports large messages by combining queues and blobs – at which point you can enqueue up to 200 GB for a single item.
256 KB eller 1 MB256 KB or 1 MB

(inklusive både rubriken och brödtexten, maximalt huvudstorlek: 64 KB).(including both header and body, maximum header size: 64 KB).

Beror på den tjänstnivå.Depends on the service tier.
Maximal meddelande TTLMaximum message TTL Oändlig (från och med api-version 2017-07-27)Infinite (as of api-version 2017-07-27) TimeSpan.MaxTimeSpan.Max
Maximalt antal köerMaximum number of queues ObegränsatUnlimited 10,00010,000

(per namnområde för tjänsten)(per service namespace)
Högsta antal samtidiga klienterMaximum number of concurrent clients ObegränsatUnlimited ObegränsatUnlimited

(100 samtidiga anslutningsgräns gäller endast för TCP-protokollsbaserade-kommunikation)(100 concurrent connection limit only applies to TCP protocol-based communication)

Ytterligare informationAdditional information

  • Service Bus framtvingar storleksbegränsningar för kön.Service Bus enforces queue size limits. Maximal köstorlek har angetts vid skapande av kön och kan ha ett värde mellan 1 och 80 GB.The maximum queue size is specified upon creation of the queue and can have a value between 1 and 80 GB. Om storleksvärdet kö på att skapa kön har uppnåtts kan ytterligare inkommande meddelanden kommer att avvisas och ett undantag som tas emot av den anropande koden.If the queue size value set on creation of the queue is reached, additional incoming messages will be rejected and an exception will be received by the calling code. Mer information om kvoter i Service Bus finns i Service Bus-kvoter.For more information about quotas in Service Bus, see Service Bus Quotas.
  • Partitionering stöds inte i den premiumnivån.Partitioning is not supported in the Premium tier. Du kan skapa Service Bus-köer i 1, 2, 3, 4 eller 5 GB storlekar (standardvärdet är 1 GB) i Standard-nivån.In the Standard tier, you can create Service Bus queues in 1, 2, 3, 4, or 5 GB sizes (the default is 1 GB). I Standard-nivån med partitionering aktiverad (vilket är standard), Service Bus skapar 16 partitioner för varje GB som du anger.In Standard tier, with partitioning enabled (which is the default), Service Bus creates 16 partitions for each GB you specify. Därmed, om du skapar en kö som är 5 GB i storlek med 16 partitioner största köstorlek blir (5 * 16) = 80 GB.As such, if you create a queue that is 5 GB in size, with 16 partitions the maximum queue size becomes (5 * 16) = 80 GB. Du kan se den maximala storleken för din partitionerad kö eller ämne genom att titta på posten den Azure-portalen.You can see the maximum size of your partitioned queue or topic by looking at its entry on the Azure portal.
  • Med Storage-köer om meddelandets innehåll inte är XML-safe måste den vara Base64 kodad.With Storage queues, if the content of the message is not XML-safe, then it must be Base64 encoded. Om du Base64-koda meddelandet, användaren nyttolasten kan vara upp till 48 KB, i stället för 64 KB.If you Base64-encode the message, the user payload can be up to 48 KB, instead of 64 KB.
  • Med Service Bus-köer, varje meddelande som lagras i en kö består av två delar: en rubrik och en brödtext.With Service Bus queues, each message stored in a queue is composed of two parts: a header and a body. Den totala storleken på meddelandet får inte överskrida den maximala meddelandestorleken som stöds av tjänstnivån.The total size of the message cannot exceed the maximum message size supported by the service tier.
  • När klienterna 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.When clients communicate with Service Bus queues over the TCP protocol, the maximum number of concurrent connections to a single Service Bus queue is limited to 100. Det här talet delas mellan avsändarna och mottagarna.This number is shared between senders and receivers. Om den här kvoten har uppnåtts kan efterföljande begäranden om ytterligare anslutningar kommer att avvisas och ett undantag som tas emot av den anropande koden.If this quota is reached, subsequent requests for additional connections will be rejected and an exception will be received by the calling code. Den här gränsen har inte införts på klienter som ansluter till köer med hjälp av REST-baserad API.This limit is not imposed on clients connecting to the queues using REST-based API.
  • Om du behöver fler än 10 000 köer i ett enda Service Bus-namnområde kan du kontakta Azure-supporten och begära en ökning.If you require more than 10,000 queues in a single Service Bus namespace, you can contact the Azure support team and request an increase. Om du vill skala utöver 10 000 köer med Service Bus, kan du också skapa ytterligare namnområden med hjälp av den Azure-portalen.To scale beyond 10,000 queues with Service Bus, you can also create additional namespaces using the Azure portal.

Hantering och åtgärderManagement and operations

Det här avsnittet jämför hanteringsfunktionerna som tillhandahålls av Storage-köer och Service Bus-köer.This section compares the management features provided by Storage queues and Service Bus queues.

JämförelsevillkorComparison Criteria Storage-köerStorage queues Service Bus-köerService Bus queues
Management-protokolletManagement protocol REST-via HTTP/HTTPSREST over HTTP/HTTPS REST-över HTTPSREST over HTTPS
Runtime-protokolletRuntime protocol REST-via HTTP/HTTPSREST over HTTP/HTTPS REST-över HTTPSREST over HTTPS

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

(.NET Lagringsklient-API)(.NET Storage Client API)
JaYes

(.NET Service Bus API)(.NET Service Bus API)
Native C++Native C++ JaYes JaYes
Java-APIJava API JaYes JaYes
PHP APIPHP API JaYes JaYes
Node.js APINode.js API JaYes JaYes
Stöd för valfria metadataArbitrary metadata support JaYes NejNo
Regler för namngivning av könQueue naming rules Upp till 63 teckenUp to 63 characters long

(Bokstäver i ett könamn måste vara versaler.)(Letters in a queue name must be lowercase.)
Upp till 260 teckenUp to 260 characters long

(Kö sökvägar och namn är skiftlägesokänsliga.)(Queue paths and names are case-insensitive.)
Hämta kö längd funktionenGet queue length function JaYes

(Ungefärligt värde om meddelanden förfaller utanför TTL-Perioden utan tas bort.)(Approximate value if messages expire beyond the TTL without being deleted.)
JaYes

(Exakta, point-in-time-värde.)(Exact, point-in-time value.)
Peek-funktionPeek function JaYes JaYes

Ytterligare informationAdditional information

  • Storage-köer ger stöd för valfria attribut som kan tillämpas på köbeskrivningen, i form av namn/värde-par.Storage queues provide support for arbitrary attributes that can be applied to the queue description, in the form of name/value pairs.
  • Båda teknikerna för kön erbjuder möjligheten att granska ett meddelande utan att låsa den, vilket kan vara användbart när du implementerar en kö webbläsaren och explorer-verktyget.Both queue technologies offer the ability to peek a message without having to lock it, which can be useful when implementing a queue explorer/browser tool.
  • Service Bus .NET asynkrona meddelanden API: er utnyttjar full duplex TCP-anslutningar för bättre prestanda jämfört med REST över HTTP och stöd för AMQP 1.0-standardprotokollet.The Service Bus .NET brokered messaging APIs leverage full-duplex TCP connections for improved performance when compared to REST over HTTP, and they support the AMQP 1.0 standard protocol.
  • Namnen på Storage-köer kan vara 3 – 63 tecken långt, kan innehålla gemena bokstäver, siffror och bindestreck.Names of Storage queues can be 3-63 characters long, can contain lowercase letters, numbers, and hyphens. Mer information finns i namngivning av köer och Metadata.For more information, see Naming Queues and Metadata.
  • Service Bus könamn kan vara upp till 260 tecken och har mindre restriktivt namngivningsregler.Service Bus queue names can be up to 260 characters long and have less restrictive naming rules. Service Bus könamn får innehålla bokstäver, siffror, punkter, bindestreck och understreck.Service Bus queue names can contain letters, numbers, periods, hyphens, and underscores.

Autentisering och auktoriseringAuthentication and authorization

Det här avsnittet beskrivs autentisering och auktorisering funktioner som stöds av Storage-köer och Service Bus-köer.This section discusses the authentication and authorization features supported by Storage queues and Service Bus queues.

JämförelsevillkorComparison Criteria Storage-köerStorage queues Service Bus-köerService Bus queues
AutentiseringAuthentication Symmetrisk nyckelSymmetric key Symmetrisk nyckelSymmetric key
SäkerhetsmodellSecurity model Delegerad åtkomst via SAS-token.Delegated access via SAS tokens. SASSAS
Provider för identitetsfederationIdentity provider federation NejNo JaYes

Ytterligare informationAdditional information

  • Varje begäran till någon av de Meddelandeköer teknikerna måste autentiseras.Every request to either of the queuing technologies must be authenticated. Offentliga köer med anonym åtkomst stöds inte.Public queues with anonymous access are not supported. Med hjälp av SAS, du kan lösa det här scenariot genom att publicera en lässkyddad SAS, skrivskyddad SAS eller även en fullständig åtkomst SAS.Using SAS, you can address this scenario by publishing a write-only SAS, read-only SAS, or even a full-access SAS.
  • Schema för autentiseringsmetoder som anges av Storage köer innebär användning av en symmetrisk nyckel, vilket är en hashbaserad meddelandeautentiseringskod (HMAC), beräknas med SHA-256-algoritmen och kodat som en Base64 sträng.The authentication scheme provided by Storage queues involves the use of a symmetric key, which is a hash-based Message Authentication Code (HMAC), computed with the SHA-256 algorithm and encoded as a Base64 string. Mer information om respektive-protokollet finns i autentisering för Azure Storage-tjänster.For more information about the respective protocol, see Authentication for the Azure Storage Services. Service Bus-köer stöder en liknande modell med symmetriska nycklar.Service Bus queues support a similar model using symmetric keys. Mer information finns i signatur autentisering för delad åtkomst med Service Bus.For more information, see Shared Access Signature Authentication with Service Bus.

SammanfattningConclusion

Du kan göra ett mer välgrundade beslut om vilken kö-teknik för att använda, genom att få en djupare förståelse för de två teknikerna, och när.By gaining a deeper understanding of the two technologies, you will be able to make a more informed decision on which queue technology to use, and when. Beslutet om när du ska använda Storage-köer eller Service Bus-köer tydligt beror på ett antal faktorer.The decision on when to use Storage queues or Service Bus queues clearly depends on a number of factors. De här faktorerna kan kraftigt beroende individuella behov av ditt program och dess arkitektur.These factors may depend heavily on the individual needs of your application and its architecture. Om programmet redan använder de viktigaste funktionerna i Microsoft Azure kan överväga du att välja Storage-köer, särskilt om du kräver grundläggande kommunikation och skickar meddelanden mellan tjänster eller behöver köer som kan vara större än 80 GB i storlek.If your application already uses the core capabilities of Microsoft Azure, you may prefer to choose Storage queues, especially if you require basic communication and messaging between services or need queues that can be larger than 80 GB in size.

Eftersom Service Bus-köer ger ett antal avancerade funktioner, till exempel sessioner, transaktioner, dubblettidentifiering, automatisk dead-lettering och varaktiga Publicera/prenumerera på funktioner, de kan vara ett önskade alternativ om du skapar en hybrid programmet eller om programmet annars kräver dessa funktioner.Because Service Bus queues provide a number of advanced features, such as sessions, transactions, duplicate detection, automatic dead-lettering, and durable publish/subscribe capabilities, they may be a preferred choice if you are building a hybrid application or if your application otherwise requires these features.

Nästa stegNext steps

Följande artiklar innehåller mer vägledning och information om hur du använder Storage-köer eller Service Bus-köer.The following articles provide more guidance and information about using Storage queues or Service Bus queues.