Fronty úložiště a fronty Service Bus – porovnání a kontrastStorage queues and Service Bus queues - compared and contrasted

Tento článek analyzuje rozdíly a podobnosti mezi dvěma typy front, které nabízí Microsoft Azure: fronty úložiště a fronty Service Bus.This article analyzes the differences and similarities between the two types of queues offered by Microsoft Azure: Storage queues and Service Bus queues. Pomocí těchto informací můžete učinit podrobnější rozhodnutí o tom, které řešení nejlépe vyhovuje vašim potřebám.By using this information, you can make a more informed decision about which solution best meets your needs.

ÚvodIntroduction

Azure podporuje dva typy mechanismů fronty: fronty úložiště a fronty Service Bus.Azure supports two types of queue mechanisms: Storage queues and Service Bus queues.

Fronty úložiště jsou součástí infrastruktury Azure Storage .Storage queues are part of the Azure Storage infrastructure. Umožňují ukládat velký počet zpráv.They allow you to store large numbers of messages. Přístup ke zprávám odkudkoli na světě prostřednictvím ověřených volání pomocí protokolu HTTP nebo HTTPS.You access messages from anywhere in the world via authenticated calls using HTTP or HTTPS. Zpráva fronty může mít velikost až 64 KB.A queue message can be up to 64 KB in size. Fronta může obsahovat miliony zpráv až do celkového limitu kapacity účtu úložiště.A queue may contain millions of messages, up to the total capacity limit of a storage account. Fronty se běžně používají k vytváření nevyřízených položek pro asynchronní zpracování.Queues are commonly used to create a backlog of work to process asynchronously. Další informace najdete v tématu co jsou Azure Storage fronty.For more information, see What are Azure Storage queues.

Fronty Service Bus jsou součástí širší infrastruktury zasílání zpráv Azure , která podporuje řazení do fronty, publikování a odběru a pokročilejší způsoby integrace.Service Bus queues are part of a broader Azure messaging infrastructure that supports queuing, publish/subscribe, and more advanced integration patterns. Jsou navržené tak, aby se integroval aplikace nebo součásti aplikací, které můžou zahrnovat víc komunikačních protokolů, kontraktů dat, důvěřujících domén nebo síťových prostředí.They're designed to integrate applications or application components that may span multiple communication protocols, data contracts, trust domains, or network environments. Další informace o Service Bus frontách, tématech a předplatných najdete v tématu Service Bus fronty, témata apředplatná.For more information about Service Bus queues/topics/subscriptions, see the Service Bus queues, topics, and subscriptions.

Požadavky na výběr technologieTechnology selection considerations

Fronty úložiště a Service Bus fronty mají mírně odlišnou sadu funkcí.Storage queues and Service Bus queues have a slightly different feature set. V závislosti na potřebách konkrétního řešení si můžete vybrat buď jednu, nebo obě.You can choose either one or both, depending on the needs of your particular solution.

Při určování technologie zařazené do fronty vyhovuje účelu daného řešení, architekti a vývojářům řešení by měli tato doporučení vzít v úvahu.When determining which queuing technology fits the purpose of a given solution, solution architects and developers should consider these recommendations.

Zvažte použití front úložištěConsider using Storage queues

Jako architekt nebo vývojář řešení byste měli zvážit použití front úložiště v těchto případech:As a solution architect/developer, you should consider using Storage queues when:

  • Vaše aplikace musí ukládat více než 80 gigabajtů zpráv ve frontě.Your application must store over 80 gigabytes of messages in a queue.
  • Vaše aplikace chce sledovat průběh zpracování zprávy ve frontě.Your application wants to track progress for processing a message in the queue. To je užitečné v případě, že pracovní proces zpracovává selhání zprávy.It's useful if the worker processing a message crashes. Další pracovník pak může tyto informace použít k pokračování z místa, kde předchozí pracovní proces skončil.Another worker can then use that information to continue from where the prior worker left off.
  • Vyžadujete, aby byly v protokolech na straně serveru všechny transakce spouštěny na vašich frontách.You require server side logs of all of the transactions executed against your queues.

Zvažte použití front Service Bus.Consider using Service Bus queues

Jako architekt nebo vývojář řešení byste měli zvážit použití Service Busch front v těchto případech:As a solution architect/developer, you should consider using Service Bus queues when:

  • Vaše řešení musí přijímat zprávy bez nutnosti cyklického dotazování fronty.Your solution needs to receive messages without having to poll the queue. Pomocí Service Bus můžete dosáhnout pomocí dlouhotrvajících protokolů založených na protokolu TCP, které Service Bus podporuje.With Service Bus, you can achieve it by using a long-polling receive operation using the TCP-based protocols that Service Bus supports.
  • Vaše řešení vyžaduje, aby fronta poskytovala zaručené doručování FIFO (First-in-first-out).Your solution requires the queue to provide a guaranteed first-in-first-out (FIFO) ordered delivery.
  • Vaše řešení musí podporovat automatickou detekci duplicit.Your solution needs to support automatic duplicate detection.
  • Chcete, aby aplikace zpracovala zprávy jako paralelní dlouhodobé proudy (zprávy jsou přidruženy ke streamu pomocí vlastnosti ID relace ve zprávě).You want your application to process messages as parallel long-running streams (messages are associated with a stream using the session ID property on the message). V tomto modelu každý uzel v náročné aplikaci soutěží na datové proudy, nikoli na zprávy.In this model, each node in the consuming application competes for streams, as opposed to messages. Když je datový proud přidělen k náročnému uzlu, uzel může prošetřit stav stavu datového proudu aplikace pomocí transakcí.When a stream is given to a consuming node, the node can examine the state of the application stream state using transactions.
  • Vaše řešení vyžaduje transakční chování a nedělitelnost při odesílání nebo přijímání více zpráv z fronty.Your solution requires transactional behavior and atomicity when sending or receiving multiple messages from a queue.
  • Vaše aplikace zpracovává zprávy, které mohou překročit 64 KB, ale nezpůsobí přístup k limitu 256-KB.Your application handles messages that can exceed 64 KB but won't likely approach the 256-KB limit.
  • Vyřešíte požadavek na poskytování modelu přístupu na základě role do front a různá práva a oprávnění pro odesílatele a příjemce.You deal with a requirement to provide a role-based access model to the queues, and different rights/permissions for senders and receivers. Další informace najdete v následujících článcích:For more information, see the following articles:
  • Velikost fronty nebude větší než 80 GB.Your queue size won't grow larger than 80 GB.
  • Chcete použít protokol zasílání zpráv založený na standardu AMQP 1,0.You want to use the AMQP 1.0 standards-based messaging protocol. Další informace o AMQP najdete v tématu Přehled služby Service Bus AMQP.For more information about AMQP, see Service Bus AMQP Overview.
  • V konečném důsledku je jakákoli migrace z typu Point-to-Point na základě fronty na vzor zasílání zpráv pro publikování a odběr.You envision an eventual migration from queue-based point-to-point communication to a publish-subscribe messaging pattern. Tento model umožňuje integraci dalších přijímačů (předplatitelů).This pattern enables integration of additional receivers (subscribers). Každý příjemce obdrží nezávislé kopie buď některých nebo všech zpráv odesílaných do fronty.Each receiver receives independent copies of either some or all messages sent to the queue.
  • Vaše řešení pro zasílání zpráv musí podporovat záruku doručení "na nejvyšší úrovni", aniž byste museli sestavovat další součásti infrastruktury.Your messaging solution needs to support the "At-Most-Once" delivery guarantee without the need for you to build the additional infrastructure components.
  • Vaše řešení potřebuje publikovat a využívat dávky zpráv.Your solution needs to publish and consume batches of messages.

Porovnání front úložiště a Service Bus frontCompare Storage queues and Service Bus queues

Tabulky v následujících částech poskytují logické seskupení funkcí fronty.The tables in the following sections provide a logical grouping of queue features. Umožňují vám na první pohled porovnávat možnosti dostupné v Azure Storage frontách a Service Busch frontách.They let you compare, at a glance, the capabilities available in both Azure Storage queues and Service Bus queues.

Základní možnostiFoundational capabilities

V této části jsou porovnávány některé základní možnosti služby Řízení front zpráv poskytované frontami úložiště a Service Bus frontami.This section compares some of the fundamental queuing capabilities provided by Storage queues and Service Bus queues.

Kritéria porovnáníComparison Criteria Fronty úložištěStorage queues Fronty služby Service BusService Bus queues
Záruka řazeníOrdering guarantee NeNo

Další informace najdete v první poznámce v části Další informace .For more information, see the first note in the Additional Information section.
Yes – first-in-first-out (FIFO)Yes - First-In-First-Out (FIFO)

(pomocí relací zpráv)(by using message sessions)
Záruka na doručeníDelivery guarantee Nejméně jednouAt-Least-Once Nejméně jednou (pomocí režimu příjmu PeekLock.At-Least-Once (using PeekLock receive mode. Je to výchozí nastavení.It's the default)

Ve více než jednou (pomocí režimu Receive ReceiveAndDelete)At-Most-Once (using ReceiveAndDelete receive mode)

Další informace o různých režimech příjmuLearn more about various Receive modes
Podpora atomických operacíAtomic operation support NeNo AnoYes

Chování při příjmuReceive behavior Bez blokováníNon-blocking

(hned se dokončí, pokud se nenalezne žádná nová zpráva.)(completes immediately if no new message is found)
Blokování s časovým limitem nebo bez nějBlocking with or without a timeout

(nabízí dlouhodobé cyklické dotazování nebo "Comet techniku")(offers long polling, or the "Comet technique")

Bez blokováníNon-blocking

(jenom pomocí rozhraní API spravovaného rozhraním .NET)(using .NET managed API only)
Rozhraní API pro vložení styluPush-style API NeNo AnoYes

Naše sady SDK pro .NET, Java, JavaScript a na cestách poskytují API ve stylu nabízených oznámení.Our .NET, Java, JavaScript, and Go SDKs provide push-style API.
Režim příjmuReceive mode Náhled & zapůjčeníPeek & Lease Náhled & zámekPeek & Lock

Přijmout & odstraněníReceive & Delete
Režim výhradního přístupuExclusive access mode Na základě zapůjčeníLease-based Na základě zámkuLock-based
Doba trvání zapůjčení/zámkuLease/Lock duration 30 sekund (výchozí)30 seconds (default)

7 dní (maximum) (můžete obnovit nebo vydat zapůjčení zprávy pomocí rozhraní UpdateMessage API.)7 days (maximum) (You can renew or release a message lease using the UpdateMessage API.)
30 sekund (výchozí)30 seconds (default)

Zámek zprávy můžete pro jednu dobu trvání zámku prodloužit pokaždé ručně nebo použít funkci automatického obnovení zámku, kde klient spravuje obnovení zámků za vás.You can renew the message lock for the same lock duration each time manually or use the automatic lock renewal feature where the client manages lock renewal for you.
Přesnost zapůjčení nebo zámkuLease/Lock precision Úroveň zprávyMessage level

Každá zpráva může mít jinou hodnotu časového limitu, kterou pak můžete podle potřeby aktualizovat při zpracování zprávy pomocí rozhraní 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.
Úroveň frontyQueue level

(u všech zpráv je použita přesnost zámku, ale zámek lze obnovit, jak je popsáno v předchozím řádku).(each queue has a lock precision applied to all of its messages, but the lock can be renewed as described in the previous row)
Dávková příjemBatched receive AnoYes

(explicitní určení počtu zpráv při načítání zpráv, až do maximálního počtu zpráv 32)(explicitly specifying message count when retrieving messages, up to a maximum of 32 messages)
AnoYes

(implicitní povolení předběžného načtení vlastnosti nebo explicitní použití transakcí)(implicitly enabling a pre-fetch property or explicitly by using transactions)
Dávkové odesláníBatched send NeNo AnoYes

(pomocí transakcí nebo dávkování na straně klienta)(by using transactions or client-side batching)

Další informaceAdditional information

  • Zprávy ve frontách úložiště jsou obvykle nejdříve první, ale někdy můžou být mimo pořadí.Messages in Storage queues are typically first-in-first-out, but sometimes they can be out of order. Například když vyprší doba trvání viditelnosti zprávy, protože při zpracování zprávy došlo k chybě v klientské aplikaci.For example, when the visibility-timeout duration of a message expires because a client application crashed while processing a message. Po vypršení časového limitu viditelnosti se zpráva znovu zobrazí ve frontě, aby ji jiný pracovní proces vyřadí do fronty.When the visibility timeout expires, the message becomes visible again on the queue for another worker to dequeue it. V tomto okamžiku je možné nově zobrazovanou zprávu umístit do fronty pro opětovné vyřazení z fronty.At that point, the newly visible message might be placed in the queue to be dequeued again.
  • Model garantované služby FIFO v Service Bus fronty vyžaduje použití relací zasílání zpráv.The guaranteed FIFO pattern in Service Bus queues requires the use of messaging sessions. Pokud aplikace selže, zatímco zpracovává zprávu přijatou v režimu náhledu & zámku , při dalším přijímači fronty po dobu platnosti relace zasílání zpráv se po vypršení časového limitu TTL (Time-to-Live) zahájí zpráva, která selhala.If the application crashes while it's 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 the message's time-to-live (TTL) period expires.
  • Fronty úložiště jsou navržené tak, aby podporovaly standardní scénáře zařazování do fronty, například následující:Storage queues are designed to support standard queuing scenarios, such as the following ones:
    • Oddělení součástí aplikace za účelem zvýšení škálovatelnosti a tolerance selháníDecoupling application components to increase scalability and tolerance for failures
    • Vyrovnávání zatíženíLoad leveling
    • Vytváření pracovních postupů procesu.Building process workflows.
  • Nekonzistence týkající se zpracování zpráv v kontextu Service Bus relací se mohou vyhnout pomocí stavu relace k uložení stavu aplikace relativně ke způsobu zpracování sekvence zpráv relace a pomocí transakcí týkajících se nedostatku přijatých zpráv a aktualizace stavu relace.Inconsistencies regarding 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. Tento druh funkce konzistence je někdy označený přesně po zpracování v produktech jiných dodavatelů.This kind of consistency feature is sometimes labeled exactly once processing in other vendor's products. Jakékoli chyby transakcí způsobí, že se zprávy znovu dostanou a že jsou důvody, proč se termín neshoduje.Any transaction failures will obviously cause messages to be redelivered and that's why the term isn't exactly adequate.
  • Fronty úložiště poskytují jednotný a konzistentní programovací model napříč frontami, tabulkami a objekty blob – jak pro vývojáře, tak pro provozní týmy.Storage queues provide a uniform and consistent programming model across queues, tables, and BLOBs – both for developers and for operations teams.
  • Fronty Service Bus poskytují podporu pro místní transakce v kontextu jedné fronty.Service Bus queues provide support for local transactions in the context of a single queue.
  • Režim přijímání a odstraňování podporovaný nástrojem Service Bus poskytuje možnost snížit počet operací zasílání zpráv (a související náklady) v systému Exchange pro zajištění nižšího objemu doručování.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.
  • Fronty úložiště poskytují zapůjčení možností rozšiřování zapůjčení pro zprávy.Storage queues provide leases with the ability to extend the leases for messages. Tato funkce umožňuje pracovním procesům udržovat krátká zapůjčení zpráv.This feature allows the worker processes to maintain short leases on messages. Pokud tedy dojde k selhání pracovního procesu, může být zpráva znovu zpracována jiným pracovním procesem.So, if a worker crashes, the message can be quickly processed again by another worker. Pracovník může také prodloužit zapůjčení zprávy v případě, že je potřebuje zpracovat delší dobu, než je aktuální zapůjčení.Also, a worker can extend the lease on a message if it needs to process it longer than the current lease time.
  • Fronty úložiště nabízejí časový limit viditelnosti, který můžete nastavit na enqueuing nebo v zařazování zpráv do fronty.Storage queues offer a visibility timeout that you can set upon the enqueuing or dequeuing of a message. Můžete také aktualizovat zprávu s různými hodnotami zapůjčení za běhu a aktualizovat různé hodnoty napříč zprávami ve stejné frontě.Also, you can update a message with different lease values at run-time, and update different values across messages in the same queue. V metadatech fronty jsou definovány Service Bus vypršení časových limitů zámků.Service Bus lock timeouts are defined in the queue metadata. Zámek zprávy pro předem definovanou dobu trvání zámku ale můžete obnovit ručně nebo použít funkci automatického obnovení zámků, kde klient spravuje obnovení zámků za vás.However, you can renew the message lock for the pre-defined lock duration manually or use the automatic lock renewal feature where the client manages lock renewal for you.
  • Maximální časový limit pro blokování operace přijímání v Service Bus frontách je 24 dní.The maximum timeout for a blocking receive operation in Service Bus queues is 24 days. Vypršení časového limitu založeného na REST ale mají maximální hodnotu 55 sekund.However, REST-based timeouts have a maximum value of 55 seconds.
  • Dávkování na straně klienta, které poskytuje Service Bus, umožňuje klientovi fronty dávkovat více zpráv do jediné operace odeslání.Client-side batching provided by Service Bus enables a queue client to batch multiple messages into a single send operation. Dávkování je k dispozici pouze pro operace asynchronního odeslání.Batching is only available for asynchronous send operations.
  • V případě funkcí, jako je 200 až TB front úložiště (více při virtualizaci účtů) a neomezené fronty, je ideální platformou pro poskytovatele SaaS.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.
  • Fronty úložiště poskytují flexibilní a výkonné mechanismy řízení přístupu.Storage queues provide a flexible and performant delegated access control mechanism.

Pokročilé možnostiAdvanced capabilities

Tato část porovnává rozšířené možnosti poskytované frontami úložiště a Service Bus frontami.This section compares advanced capabilities provided by Storage queues and Service Bus queues.

Kritéria porovnáníComparison Criteria Fronty úložištěStorage queues Fronty služby Service BusService Bus queues
Naplánované doručeníScheduled delivery AnoYes AnoYes
Automatické nedoručené dopisyAutomatic dead lettering NeNo AnoYes
Zvýšení hodnoty Time-to-Live pro frontuIncreasing queue time-to-live value AnoYes

(prostřednictvím místní aktualizace časového limitu viditelnosti)(via in-place update of visibility timeout)
AnoYes

(k dispozici prostřednictvím vyhrazené funkce rozhraní API)(provided via a dedicated API function)
Podpora nepoškozených zprávPoison message support AnoYes AnoYes
Místní aktualizaceIn-place update AnoYes AnoYes
Protokol transakcí na straně serveruServer-side transaction log AnoYes NeNo
Metriky úložištěStorage metrics AnoYes

Minutové metriky poskytují metriky v reálném čase pro dostupnost, TPS, počty volání rozhraní API, počty chyb a další.Minute Metrics provides real-time metrics for availability, TPS, API call counts, error counts, and more. Jsou všechny v reálném čase, agregované za minutu a nahlášeny během několika minut od toho, co se právě stalo v produkčním prostředí.They're all in real time, aggregated per minute and reported within a few minutes from what just happened in production. Další informace najdete v tématu o metrikách analýza úložiště.For more information, see About Storage Analytics Metrics.
AnoYes

Informace o metrikách podporovaných nástrojem Azure Service Bus najdete v tématu metriky zpráv.For information about metrics supported by Azure Service Bus, see Message metrics.
Správa stavuState management NeNo Ano (aktivní, zakázané, SendDisabled, ReceiveDisabled.Yes (Active, Disabled, SendDisabled, ReceiveDisabled. Podrobnosti o těchto stavech najdete v tématu Queue status).For details on these states, see Queue status)
Přeposílání zprávMessage autoforwarding NeNo AnoYes
Vyprázdnit funkci QueuePurge queue function AnoYes NeNo
Skupiny zprávMessage groups NeNo AnoYes

(pomocí relací zasílání zpráv)(by using messaging sessions)
Stav aplikace na jednu skupinu zprávApplication state per message group NeNo AnoYes
Vyhledávání duplicitDuplicate detection NeNo AnoYes

(konfigurovatelné na straně odesilatele)(configurable on the sender side)
Procházení skupin zprávBrowsing message groups NeNo AnoYes
Načítají se relace zpráv podle ID.Fetching message sessions by ID NeNo AnoYes

Další informaceAdditional information

  • Obě technologie pro řízení front umožňují, aby byla zpráva naplánována na doručení později.Both queuing technologies enable a message to be scheduled for delivery at a later time.
  • Při autopřesměrovávání do fronty je možné, že tisíce front mají na jednu frontu automatickou přeposílání zpráv do jediné fronty, ze které přijímající aplikace tuto zprávu spotřebovává.Queue autoforwarding enables thousands of queues to autoforward their messages to a single queue, from which the receiving application consumes the message. Tento mechanismus můžete použít k zajištění zabezpečení, řízení toku a izolace úložiště mezi jednotlivými vydavateli zpráv.You can use this mechanism to achieve security, control flow, and isolate storage between each message publisher.
  • Fronty úložiště poskytují podporu pro aktualizaci obsahu zpráv.Storage queues provide support for updating message content. Tuto funkci můžete použít pro trvalé informace o stavu a přírůstkové aktualizace průběhu do zprávy tak, aby se mohly zpracovat z posledního známého kontrolního bodu, a ne od začátku.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. U Service Busch front můžete pomocí relací zpráv povolit stejný scénář.With Service Bus queues, you can enable the same scenario by using message sessions. Další informace najdete v tématu stav relace zpráv.For more information, see Message session state.
  • Fronty Service Bus podporují nedoručené dopisy.Service Bus queues support dead lettering. Může být užitečný pro izolaci zpráv, které splňují následující kritéria:It can be useful for isolating messages that meet the following criteria:
    • Zprávy nelze úspěšně zpracovat přijímající aplikací.Messages can't be processed successfully by the receiving application
    • Zprávy se nemohou dostat do svého cíle z důvodu vypršení platnosti vlastnosti TTL (Time to Live).Messages can't reach their destination because of an expired time-to-live (TTL) property. Hodnota TTL určuje, jak dlouho zpráva zůstane ve frontě.The TTL value specifies how long a message remains in the queue. Při Service Bus bude zpráva přesunuta do speciální fronty nazvané $DeadLetterQueue po vypršení časového limitu TTL.With Service Bus, the message will be moved to a special queue called $DeadLetterQueue when the TTL period expires.
  • Chcete-li najít "poškozené" zprávy ve frontách úložiště při vyřazení zprávy, aplikace ověří vlastnost DequeueCount zprávy.To find "poison" messages in Storage queues, when dequeuing a message the application examines the DequeueCount property of the message. Pokud je DequeueCount větší než daná prahová hodnota, aplikace přesune zprávu do fronty nedoručených zpráv definované aplikací.If DequeueCount is greater than a given threshold, the application moves the message to an application-defined "dead letter" queue.
  • Fronty úložiště umožňují získat podrobný protokol všech transakcí provedených proti frontě a agregované metriky.Storage queues enable you to obtain a detailed log of all of the transactions executed against the queue, and aggregated metrics. Obě tyto možnosti jsou užitečné pro ladění a porozumění způsobu, jakým vaše aplikace používá fronty úložiště.Both of these options are useful for debugging and understanding how your application uses Storage queues. Jsou také užitečné pro vyladění výkonu aplikace a snížení nákladů na používání front.They're also useful for performance-tuning your application and reducing the costs of using queues.
  • Relace zpráv podporované nástrojem Service Bus umožňují, aby byly zprávy patřící do logické skupiny přidružené k přijímači.Message sessions supported by Service Bus enable messages that belong to a logical group to be associated with a receiver. Vytvoří spřažení podobné relaci mezi zprávami a jejich příslušnými přijímači.It creates a session-like affinity between messages and their respective receivers. Tuto rozšířenou funkci můžete v Service Bus povolit nastavením vlastnosti ID relace ve zprávě.You can enable this advanced functionality in Service Bus by setting the session ID property on a message. Přijímačé pak mohou naslouchat konkrétnímu ID relace a přijímat zprávy, které sdílejí zadaný identifikátor relace.Receivers can then listen on a specific session ID and receive messages that share the specified session identifier.
  • Funkce Detekce duplicitních dat ve frontách Service Bus automaticky odstraní duplicitní zprávy odeslané do fronty nebo tématu, a to na základě hodnoty vlastnosti ID zprávy.The duplication detection feature of Service Bus queues automatically removes duplicate messages sent to a queue or topic, based on the value of the message ID property.

Kapacita a kvótyCapacity and quotas

V této části se porovnávají fronty úložiště a Service Bus fronty z perspektivy kapacity a kvót , které mohou platit.This section compares Storage queues and Service Bus queues from the perspective of capacity and quotas that may apply.

Kritéria porovnáníComparison Criteria Fronty úložištěStorage queues Fronty služby Service BusService Bus queues
Maximální velikost frontyMaximum queue size 500 TB500 TB

(omezeno na jednu kapacitu účtu úložiště)(limited to a single storage account capacity)
1 GB až 80 GB1 GB to 80 GB

(definováno při vytváření fronty a Povolení dělení – viz část "Další informace")(defined upon creation of a queue and enabling partitioning – see the “Additional Information” section)
Maximální velikost zprávyMaximum message size 64 kB64 KB

(48 KB při použití kódování Base64 )(48 KB when using Base64 encoding)

Azure podporuje velké zprávy kombinováním front a objektů BLOB – v takovém bodě můžete každou položku zařadit do fronty až 200 GB.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 nebo 1 MB256 KB or 1 MB

(včetně záhlaví a textu, maximální velikost hlavičky: 64 KB).(including both header and body, maximum header size: 64 KB).

Závisí na úrovni služby.Depends on the service tier.
Maximální hodnota TTL zprávyMaximum message TTL Infinite (API-Version 2017-07-27 nebo novější)Infinite (api-version 2017-07-27 or later) TimeSpan. maxTimeSpan.Max
Maximální počet frontMaximum number of queues UnlimitedUnlimited 10 00010,000

(obor názvů pro službu)(per service namespace)
Maximální počet souběžných klientůMaximum number of concurrent clients UnlimitedUnlimited 5 0005,000

Další informaceAdditional information

  • Service Bus vynutila omezení velikosti fronty.Service Bus enforces queue size limits. Maximální velikost fronty je určena při vytváření fronty.The maximum queue size is specified when creating a queue. Může být v rozmezí 1 GB až 80 GB.It can be between 1 GB and 80 GB. Pokud velikost fronty dosáhne tohoto limitu, další příchozí zprávy se odmítnou a volající obdrží výjimku.If the queue's size reaches this limit, additional incoming messages will be rejected and the caller receives an exception. Další informace o kvótách v Service Bus najdete v tématu kvóty Service Bus.For more information about quotas in Service Bus, see Service Bus Quotas.
  • Dělení na úrovni Premiumse nepodporuje.Partitioning isn't supported in the Premium tier. Na úrovni Standard pro zasílání zpráv můžete vytvořit Service Bus fronty a témata ve velikosti 1 (výchozí), 2, 3, 4 nebo 5 GB.In the Standard messaging tier, you can create Service Bus queues and topics in 1 (default), 2, 3, 4, or 5-GB sizes. Když je zapnuté dělení, Service Bus vytvoří 16 kopií (16 oddílů) entity, každé zadané velikosti.With partitioning enabled, Service Bus creates 16 copies (16 partitions) of the entity, each of the same size specified. Pokud vytvoříte frontu o velikosti 5 GB, přičemž 16 oddílů se změní na maximální velikost fronty (5 × 16) = 80 GB.As such, if you create a queue that's 5 GB in size, with 16 partitions the maximum queue size becomes (5 * 16) = 80 GB. V Azure Portalmůžete zobrazit maximální velikost rozdělené fronty nebo tématu.You can see the maximum size of your partitioned queue or topic in the Azure portal.
  • Pokud se ve frontách úložiště nejedná o zabezpečený obsah zprávy, musí být kódovaný v kódování Base64 .With Storage queues, if the content of the message isn't XML-safe, then it must be Base64 encoded. Pokud zprávu zakódujete ve formátu base64, může být datová část uživatele až 48 kb namísto 64 KB.If you Base64-encode the message, the user payload can be up to 48 KB, instead of 64 KB.
  • U Service Busch front se každá zpráva uložená ve frontě skládá ze dvou částí: záhlaví a tělo.With Service Bus queues, each message stored in a queue is composed of two parts: a header and a body. Celková velikost zprávy nepřekračuje maximální velikost zprávy podporované vrstvou služby.The total size of the message can't exceed the maximum message size supported by the service tier.
  • Pokud klienti komunikují s Service Bus frontami přes protokol TCP, maximální počet souběžných připojení k jedné frontě Service Bus je omezený na 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. Toto číslo je sdíleno mezi odesílateli a přijímači.This number is shared between senders and receivers. Pokud je dosažena tato kvóta, žádosti o další připojení budou odmítnuty a volající kód bude přijímat výjimku.If this quota is reached, requests for additional connections will be rejected and an exception will be received by the calling code. Toto omezení není uloženo u klientů připojujících se k frontám pomocí rozhraní API založeného na REST.This limit isn't imposed on clients connecting to the queues using REST-based API.
  • Pokud potřebujete více než 10 000 front v jednom oboru názvů Service Bus, můžete kontaktovat tým podpory Azure a požádat o zvýšení.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. Pokud chcete škálovat více než 10 000 front pomocí Service Bus, můžete také vytvořit další obory názvů pomocí Azure Portal.To scale beyond 10,000 queues with Service Bus, you can also create additional namespaces using the Azure portal.

Správa a operaceManagement and operations

V této části se porovnávají funkce správy poskytované frontami úložiště a Service Bus frontami.This section compares the management features provided by Storage queues and Service Bus queues.

Kritéria porovnáníComparison Criteria Fronty úložištěStorage queues Fronty služby Service BusService Bus queues
Protokol pro správuManagement protocol REST přes HTTP/HTTPSREST over HTTP/HTTPS REST přes HTTPSREST over HTTPS
Protokol za běhuRuntime protocol REST přes HTTP/HTTPSREST over HTTP/HTTPS REST přes HTTPSREST over HTTPS

AMQP 1,0 Standard (TCP s TLS)AMQP 1.0 Standard (TCP with TLS)
.NET API.NET API AnoYes

(Klientské rozhraní API pro úložiště .NET)(.NET Storage Client API)
AnoYes

(Rozhraní .NET Service Bus API)(.NET Service Bus API)
Nativní C++Native C++ AnoYes AnoYes
Java APIJava API AnoYes AnoYes
ROZHRANÍ PHP APIPHP API AnoYes AnoYes
Node.js APINode.js API AnoYes AnoYes
Libovolná Podpora metadatArbitrary metadata support AnoYes NeNo
Queue pravidla pojmenováníQueue naming rules Až 63 znaků dlouhéUp to 63 characters long

(Písmena v názvu fronty musí být malá.)(Letters in a queue name must be lowercase.)
Až 260 znaků dlouhéUp to 260 characters long

(U cest a názvů fronty se nerozlišují malá a velká písmena.)(Queue paths and names are case-insensitive.)
Funkce Get Queue LengthGet queue length function AnoYes

(Přibližná hodnota, pokud vyprší platnost zpráv nad rámec hodnoty TTL bez odstranění.)(Approximate value if messages expire beyond the TTL without being deleted.)
AnoYes

(Přesně, hodnota bodu v čase.)(Exact, point-in-time value.)
Funkce prohlížetPeek function AnoYes AnoYes

Další informaceAdditional information

  • Fronty úložiště poskytují podporu pro libovolné atributy, které se dají použít pro popis fronty, a to ve formě párů název/hodnota.Storage queues provide support for arbitrary attributes that can be applied to the queue description, in the form of name/value pairs.
  • Obě technologie front nabízejí možnost prohlížet zprávu, aniž by ji museli zamknout, což může být užitečné při implementaci Průzkumníka/nástroje fronty.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.
  • Rozhraní API pro zprostředkované zasílání zpráv Service Bus používají plně duplexní připojení TCP pro zlepšení výkonu ve srovnání s REST přes protokol HTTP a podporují standardní protokol AMQP 1,0.The Service Bus .NET brokered messaging APIs use full-duplex TCP connections for improved performance when compared to REST over HTTP, and they support the AMQP 1.0 standard protocol.
  • Názvy front úložiště můžou být 3-63 znaků dlouhé, můžou obsahovat malá písmena, číslice a spojovníky.Names of Storage queues can be 3-63 characters long, can contain lowercase letters, numbers, and hyphens. Další informace najdete v tématu pojmenování front a metadat.For more information, see Naming Queues and Metadata.
  • Názvy front Service Bus mohou mít délku až 260 znaků a mají méně omezující pravidla pojmenování.Service Bus queue names can be up to 260 characters long and have less restrictive naming rules. Názvy front Service Bus můžou obsahovat písmena, číslice, tečky, spojovníky a podtržítka.Service Bus queue names can contain letters, numbers, periods, hyphens, and underscores.

Ověřování a autorizaceAuthentication and authorization

Tato část popisuje funkce pro ověřování a autorizaci podporované frontami úložiště a frontami Service Bus.This section discusses the authentication and authorization features supported by Storage queues and Service Bus queues.

Kritéria porovnáníComparison Criteria Fronty úložištěStorage queues Fronty služby Service BusService Bus queues
AuthenticationAuthentication Symetrický klíčSymmetric key Symetrický klíčSymmetric key
Model zabezpečeníSecurity model Delegovaný přístup prostřednictvím tokenů SAS.Delegated access via SAS tokens. SASSAS
Federace zprostředkovatele identityIdentity provider federation AnoYes AnoYes

Další informaceAdditional information

  • Každý požadavek na jednu z technologií služby Řízení front zpráv musí být ověřen.Every request to either of the queuing technologies must be authenticated. Veřejné fronty s anonymním přístupem se nepodporují.Public queues with anonymous access aren't supported. Pomocí SASmůžete vyřešit tento scénář publikováním SAS pouze pro zápis, SAS jen pro čtení nebo i pomocí SAS s úplným přístupem.Using SAS, you can address this scenario by publishing a write-only SAS, read-only SAS, or even a full-access SAS.
  • Schéma ověřování poskytované frontami úložiště zahrnuje použití symetrického klíče.The authentication scheme provided by Storage queues involves the use of a symmetric key. Tento klíč je ověřovací kód zprávy založený na hodnotě hash (HMAC), vypočítaný pomocí algoritmu SHA-256 a zakódovaný jako řetězec Base64 .This key is a hash-based Message Authentication Code (HMAC), computed with the SHA-256 algorithm and encoded as a Base64 string. Další informace o příslušném protokolu najdete v tématu ověřování pro službu Azure Storage Services.For more information about the respective protocol, see Authentication for the Azure Storage Services. Fronty Service Bus podporují podobný model pomocí symetrických klíčů.Service Bus queues support a similar model using symmetric keys. Další informace najdete v tématu ověřování pomocí sdíleného přístupového podpisu s Service Bus.For more information, see Shared Access Signature Authentication with Service Bus.

ZávěrConclusion

Díky lepšímu porozumění těmto dvěma technologiím si můžete učinit podrobnější rozhodnutí o tom, která technologie fronty se má použít, a kdy.By gaining a deeper understanding of the two technologies, you can make a more informed decision on which queue technology to use, and when. Rozhodnutí o tom, kdy používat fronty úložiště nebo Service Bus fronty, je jasně závislá na mnoha faktorech.The decision on when to use Storage queues or Service Bus queues clearly depends on many factors. Tyto faktory můžou záviset na jednotlivých potřebách vaší aplikace a její architektury.These factors may depend heavily on the individual needs of your application and its architecture.

Můžete chtít zvolit fronty úložiště z následujících důvodů:You may prefer to choose Storage queues for reasons such as the following ones:

  • Pokud už vaše aplikace používá základní funkce Microsoft AzureIf your application already uses the core capabilities of Microsoft Azure
  • Pokud požadujete základní komunikaci a zasílání zpráv mezi službamiIf you require basic communication and messaging between services
  • Potřebujete fronty, jejichž velikost může být větší než 80 GB.Need queues that can be larger than 80 GB in size

Fronty Service Bus poskytují mnoho pokročilých funkcí, jako jsou následující.Service Bus queues provide many advanced features such as the following ones. To může být Upřednostňovaná volba, pokud vytváříte hybridní aplikaci nebo pokud vaše aplikace jinak vyžaduje tyto funkce.So, they may be a preferred choice if you're building a hybrid application or if your application otherwise requires these features.

Další krokyNext steps

Následující články poskytují další doprovodné materiály a informace o používání front úložiště nebo Service Bus front.The following articles provide more guidance and information about using Storage queues or Service Bus queues.