存储队列和服务总线队列 - 比较与对照Storage queues and Service Bus queues - compared and contrasted

本文分析 Azure 提供的以下两种队列类型之间的差异和相似性:存储队列和服务总线队列。This article analyzes the differences and similarities between the two types of queues offered by Azure: Storage queues and Service Bus queues. 通过使用此信息,可以更明智地选出最适合你需求的解决方案。By using this information, you can make a more informed decision about which solution best meets your needs.


Azure 支持两种队列机制:“存储队列”和“服务总线队列” 。Azure supports two types of queue mechanisms: Storage queues and Service Bus queues.

存储队列是 Azure 存储基础结构的一部分。Storage queues are part of the Azure Storage infrastructure. 存储队列允许存储大量消息。They allow you to store large numbers of messages. 可以使用 HTTP 或 HTTPS 通过经验证的调用从世界任何位置访问消息。You access messages from anywhere in the world via authenticated calls using HTTP or HTTPS. 队列消息大小最大可为 64 KB。A queue message can be up to 64 KB in size. 一个队列可以包含数百万条消息,直至达到存储帐户的总容量限值。A queue may contain millions of messages, up to the total capacity limit of a storage account. 队列通常用于创建要异步处理的积压工作 (backlog)。Queues are commonly used to create a backlog of work to process asynchronously. 有关详细信息,请参阅什么是 Azure 存储队列For more information, see What are Azure Storage queues.

服务总线队列是更广泛的 Azure 消息传递基础结构的一部分,可支持队列、发布/订阅和更高级的集成模式。Service Bus queues are part of a broader Azure messaging infrastructure that supports queuing, publish/subscribe, and more advanced integration patterns. 服务总线队列旨在集成可能跨多个通信协议、数据约定、信任域或网络环境的应用程序或应用程序组件。They're designed to integrate applications or application components that may span multiple communication protocols, data contracts, trust domains, or network environments. 有关服务总线队列/话题/订阅的详细信息,请参阅服务总线队列、主题和订阅For more information about Service Bus queues/topics/subscriptions, see the Service Bus queues, topics, and subscriptions.

技术选择注意事项Technology selection considerations

存储队列和服务总线队列具有略微不同的功能集。Storage queues and Service Bus queues have a slightly different feature set. 可以选择其中一种或两者,具体取决于特定解决方案的需求。You can choose either one or both, depending on the needs of your particular solution.

在确定哪种队列技术适合给定的解决方案时,解决方案架构师和开发人员应考虑以下建议。When determining which queuing technology fits the purpose of a given solution, solution architects and developers should consider these recommendations.

考虑使用存储队列Consider using Storage queues

作为解决方案架构师/开发人员,在以下情况下, 应考虑使用存储队列As a solution architect/developer, you should consider using Storage queues when:

  • 应用程序必须在队列中存储超过 80 GB 的消息。Your application must store over 80 gigabytes of messages in a queue.
  • 应用程序需要跟踪队列中消息的处理进度。Your application wants to track progress for processing a message in the queue. 如果处理消息的工作进程发生崩溃,这非常有用。It's useful if the worker processing a message crashes. 其他工作进程可以使用该信息从之前的工作进程停止处继续。Another worker can then use that information to continue from where the prior worker left off.
  • 你需要针对队列执行的所有事务的服务器端日志。You require server side logs of all of the transactions executed against your queues.

考虑使用服务总线队列Consider using Service Bus queues

作为解决方案架构师/开发人员,在以下情况下, 应考虑使用服务总线队列As a solution architect/developer, you should consider using Service Bus queues when:

  • 解决方案需要在无需轮询队列的情况下接收消息。Your solution needs to receive messages without having to poll the queue. 有了服务总线,就可以使用服务总线支持的基于 TCP 的协议,通过长轮询接收操作来实现此目的。With Service Bus, you can achieve it by using a long-polling receive operation using the TCP-based protocols that Service Bus supports.
  • 解决方案要求队列必须遵循先入先出 (FIFO) 的传递顺序。Your solution requires the queue to provide a guaranteed first-in-first-out (FIFO) ordered delivery.
  • 解决方案需要支持自动重复检测。Your solution needs to support automatic duplicate detection.
  • 希望应用程序将消息作为长时间运行的并行流进行处理(使用消息的 SessionId 属性,将消息与流相关联)。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). 在这种模式下,消费应用程序中的每个节点会竞争流而不是消息。In this model, each node in the consuming application competes for streams, as opposed to messages. 当流被提供给某个消费节点时,该节点可以使用事务检查应用程序流的状态。When a stream is given to a consuming node, the node can examine the state of the application stream state using transactions.
  • 解决方案在发送或接收来自队列的多个消息时,需要事务行为和原子性。Your solution requires transactional behavior and atomicity when sending or receiving multiple messages from a queue.
  • 应用程序处理的消息介于 64 KB 和 256 KB 之间。Your application handles messages that can exceed 64 KB but won't likely approach the 256-KB limit.
  • 需要向队列提供基于角色的访问模型,为发送方和接收方提供不同权限。You deal with a requirement to provide a role-based access model to the queues, and different rights/permissions for senders and receivers. 有关详细信息,请参阅以下文章:For more information, see the following articles:
  • 队列大小不会增长到超过 80 GB。Your queue size won't grow larger than 80 GB.
  • 希望使用基于 AMQP 1.0 标准的消息传送协议。You want to use the AMQP 1.0 standards-based messaging protocol. 有关 AMQP 的详细信息,请参阅服务总线 AMQP 概述For more information about AMQP, see Service Bus AMQP Overview.
  • 设想最终会从基于队列的点对点通信迁移到发布-订阅消息传递模式。You envision an eventual migration from queue-based point-to-point communication to a publish-subscribe messaging pattern. 此模式可以集成其他接收器(订阅者)。This pattern enables integration of additional receivers (subscribers). 每个接收方都接收发送到队列的部分或全部消息的独立副本。Each receiver receives independent copies of either some or all messages sent to the queue.
  • 消息传送解决方案需要支持“至多一次”传递保证,而无需构建其他基础结构组件。Your messaging solution needs to support the "At-Most-Once" delivery guarantee without the need for you to build the additional infrastructure components.
  • 解决方案需要发布并使用消息批处理。Your solution needs to publish and consume batches of messages.

比较存储队列和服务总线队列Compare Storage queues and Service Bus queues

以下各部分中的表提供队列功能的逻辑分组。The tables in the following sections provide a logical grouping of queue features. 通过下面的表,可以清楚地比较 Azure 存储队列和服务总线队列中的可用功能。They let you compare, at a glance, the capabilities available in both Azure Storage queues and Service Bus queues.

基础功能Foundational capabilities

本部分比较存储队列和服务总线队列提供的一些基础队列功能。This section compares some of the fundamental queuing capabilities provided by Storage queues and Service Bus queues.

比较条件Comparison Criteria 存储队列Storage queues 服务总线队列Service Bus queues
排序保障Ordering guarantee No

有关详细信息,请参阅其他信息部分的第一条说明。For more information, see the first note in the Additional Information section.
是 - 先进先出 (FIFO)Yes - First-In-First-Out (FIFO)

(通过使用消息会话(through the use of message sessions)
传递保障Delivery guarantee 至少一次At-Least-Once 至少一次(使用 PeekLock 接收模式。At-Least-Once (using PeekLock receive mode. 这是默认值)It's the default)

最多一次(使用 ReceiveAndDelete 接收模式)At-Most-Once (using ReceiveAndDelete receive mode)

详细了解各种接收模式Learn more about various Receive modes
原子操作支持Atomic operation support No Yes

接收行为Receive behavior 非阻止Non-blocking

(如果没有发现新消息,则立即完成)(completes immediately if no new message is found)
阻止超时或未超时Blocking with or without a timeout

(提供长轮询,或“Comet 技术”(offers long polling, or the "Comet technique")


(通过仅使用 .NET 托管的 API)(through the use of .NET managed API only)
推送样式 APIPush-style API No Yes

QueueClient.OnMessageMessageSessionHandler.OnMessage 会话 .NET API。QueueClient.OnMessage and MessageSessionHandler.OnMessage sessions .NET API.
接收模式Receive mode 扫视与租赁Peek & Lease 扫视与锁定Peek & Lock

接收并删除Receive & Delete
独占访问模式Exclusive access mode 基于租赁Lease-based 基于锁定Lock-based
租赁/锁定持续时间Lease/Lock duration 30 秒(默认值)30 seconds (default)

7 天(最大值) (可使用 UpdateMessage API 续订或释放消息租赁。)7 days (maximum) (You can renew or release a message lease using the UpdateMessage API.)
60 秒(默认值)60 seconds (default)

可使用 RenewLock API 续订消息锁。You can renew a message lock using the RenewLock API.
租赁/锁定精度Lease/Lock precision 消息级别Message level

(每条消息可具有不同的超时值,可在处理消息时,根据需要使用 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)
队列级别Queue level

(每个队列都具有一个适用于其中所有消息的锁定精度,但是可使用 RenewLock API 续订该锁。)(each queue has a lock precision applied to all of its messages, but you can renew the lock using the RenewLock API.)
成批接收Batched receive Yes

(在检索消息时显式指定消息计数,最多可达 32 条消息)(explicitly specifying message count when retrieving messages, up to a maximum of 32 messages)

(隐式启用预提取属性或通过使用事务显式启用)(implicitly enabling a pre-fetch property or explicitly through the use of transactions)
成批发送Batched send No Yes

(通过使用事务或客户端批处理)(through the use of transactions or client-side batching)

其他信息Additional information

  • 存储队列中的消息通常先进先出,但有时可能会不按顺序进出。Messages in Storage queues are typically first-in-first-out, but sometimes they can be out of order. 例如,由于客户端应用程序在处理消息时崩溃而导致消息的可见性超时持续时间到期时。For example, when the visibility-timeout duration of a message expires because a client application crashed while processing a message. 当可见性超时到期时,消息会再次变成在队列上可见,让另一个工作进程能够取消它的排队。When the visibility timeout expires, the message becomes visible again on the queue for another worker to dequeue it. 此时,重新变成可见的消息可以放置在队列中以再次取消其排队。At that point, the newly visible message might be placed in the queue to be dequeued again.
  • 服务总线队列中有保障的 FIFO 模式要求使用消息传送会话。The guaranteed FIFO pattern in Service Bus queues requires the use of messaging sessions. 如果应用程序处理在“速览与锁定”模式下接收的消息时发生崩溃,则当下次队列接收方接受消息传递会话时,它将在失败消息的生存时间 (TTL) 期限过期后从失败的消息开始。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.
  • 存储队列旨在支持标准加入队列方案,例如以下方案:Storage queues are designed to support standard queuing scenarios, such as the following ones:
    • 解耦应用程序组件,提高可伸缩性和故障容错能力Decoupling application components to increase scalability and tolerance for failures
    • 负载分级Load leveling
    • 构建过程工作流。Building process workflows.
  • 可以避免在服务总线会话上下文中处理消息时出现的不一致,方法是:使用会话状态来存储应用程序的状态(与处理会话的消息序列的进程相关),以及使用与处理接收的消息和更新会话状态相关的事务。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. 这种一致性功能有时在其他供应商的产品中标记为“只需处理一次”。This kind of consistency feature is sometimes labeled exactly once processing in other vendor's products. 任何事务失败显然都将导致消息重新传递,这就是该术语不够恰当的原因。Any transaction failures will obviously cause messages to be redelivered and that's why the term isn't exactly adequate.
  • 存储队列可在多个队列、表和 Blob 上提供统一和一致的编程模型 - 对于开发人员和运营团队都是如此。Storage queues provide a uniform and consistent programming model across queues, tables, and BLOBs - both for developers and for operations teams.
  • 服务总线队列为单个队列的上下文中的本地事务提供支持。Service Bus queues provide support for local transactions in the context of a single queue.
  • 服务总线支持的“接收与删除”模式提供了减少消息传送操作计数(和相关成本)以换取降低安全传递保证的能力。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.
  • 存储队列提供租赁且可延长消息租赁时间。Storage queues provide leases with the ability to extend the leases for messages. 此功能允许工作进程对消息保持短的租赁时间。This feature allows the worker processes to maintain short leases on messages. 因此,如果某个工作进程崩溃,则其他工作进程可以再次快速处理该消息。So, if a worker crashes, the message can be quickly processed again by another worker. 此外,如果工作进程处理消息所需的时间比当前租赁时间长,则工作进程可以延长该消息的租赁时间。Also, a worker can extend the lease on a message if it needs to process it longer than the current lease time.
  • 存储队列提供了可见性超时,可针对消息入队或出队进行设置。Storage queues offer a visibility timeout that you can set upon the enqueuing or dequeuing of a message. 此外,可以在运行时使用不同租赁值更新消息,并且可以跨同一队列的消息更新不同值。Also, you can update a message with different lease values at run-time, and update different values across messages in the same queue. 服务总线锁定超时在队列元数据中定义。Service Bus lock timeouts are defined in the queue metadata. 但是,可以通过调用 RenewLock 方法来续订锁。However, you can renew the lock by calling the RenewLock method.
  • 服务总线队列中阻塞接收操作的最大超时值为 24 天。The maximum timeout for a blocking receive operation in Service Bus queues is 24 days. 但是,基于 REST 的最大超时值为 55 秒。However, REST-based timeouts have a maximum value of 55 seconds.
  • 服务总线提供的客户端批处理允许队列客户端将多个消息纳入一个发送操作中进行批处理。Client-side batching provided by Service Bus enables a queue client to batch multiple messages into a single send operation. 批处理仅适用于异步发送操作。Batching is only available for asynchronous send operations.
  • 有些特性,例如存储队列的 200 TB 上限(虚拟化帐户时更多)和无限制队列,使得它成为 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.
  • 存储队列提供灵活且性能良好的委托访问控制机制。Storage queues provide a flexible and performant delegated access control mechanism.

高级功能Advanced capabilities

本部分对存储队列和服务总线队列提供的高级功能进行了比较。This section compares advanced capabilities provided by Storage queues and Service Bus queues.

比较条件Comparison Criteria 存储队列Storage queues 服务总线队列Service Bus queues
计划的传递Scheduled delivery Yes Yes
自动死信Automatic dead lettering No Yes
提高队列生存时间值Increasing queue time-to-live value Yes

(通过就地更新可见性超时)(via in-place update of visibility timeout)

(通过一个专用 API 功能提供)(provided via a dedicated API function)
有害消息支持Poison message support Yes Yes
就地更新In-place update Yes Yes
服务器端事务日志Server-side transaction log Yes No
存储度量值Storage metrics Yes

分钟指标提供有关可用性、TPS、API 调用计数、错误计数等的实时指标。Minute Metrics provides real-time metrics for availability, TPS, API call counts, error counts, and more. 它们都是实时的,每分钟聚合一次,并在几分钟内报告生产环境中刚刚发生的事件。They're all in real time, aggregated per minute and reported within a few minutes from what just happened in production. 有关详细信息,请参阅关于存储分析度量值For more information, see About Storage Analytics Metrics.

(通过调用 GetQueues 进行大容量查询)(bulk queries by calling GetQueues)
状态管理State management No Yes

Microsoft.ServiceBus.Messaging.EntityStatus.ActiveMicrosoft.ServiceBus.Messaging.EntityStatus.DisabledMicrosoft.ServiceBus.Messaging.EntityStatus.SendDisabledMicrosoft.ServiceBus.Messaging.EntityStatus.ReceiveDisabledMicrosoft.ServiceBus.Messaging.EntityStatus.Active, Microsoft.ServiceBus.Messaging.EntityStatus.Disabled, Microsoft.ServiceBus.Messaging.EntityStatus.SendDisabled, Microsoft.ServiceBus.Messaging.EntityStatus.ReceiveDisabled
消息自动转发Message autoforwarding No Yes
清除队列函数Purge queue function Yes No
消息组Message groups No Yes

(通过使用消息传送会话)(through the use of messaging sessions)
每个消息组的应用程序状态Application state per message group No Yes
重复检测Duplicate detection No Yes

(可在发送端配置)(configurable on the sender side)
浏览消息组Browsing message groups No Yes
按 ID 提取消息会话Fetching message sessions by ID No Yes

其他信息Additional information

  • 两种队列技术都允许将消息安排在以后传送。Both queuing technologies enable a message to be scheduled for delivery at a later time.
  • 利用队列自动转发功能,数千个队列可将它们的消息自动转发至单个队列,而接收应用程序将使用来自该队列的消息。Queue autoforwarding enables thousands of queues to autoforward their messages to a single queue, from which the receiving application consumes the message. 可以使用此机制来实现安全性和控制流,并且隔离每个消息发布者的存储。You can use this mechanism to achieve security, control flow, and isolate storage between each message publisher.
  • 存储队列为更新消息内容提供支持。Storage queues provide support for updating message content. 可以使用此功能将状态信息和递增进度更新持久保留到消息中,以便能够从上一个已知的检查点处理该消息,而不是从头开始。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. 借助服务总线队列,可以通过使用消息会话实现相同的方案。With Service Bus queues, you can enable the same scenario through the use of message sessions. 会话允许保存和检索应用程序处理状态(通过使用 SetStateGetState)。Sessions enable you to save and retrieve the application processing state (by using SetState and GetState).
  • 服务总线队列支持死信Service Bus queues support dead lettering. 若要隔离满足以下条件的消息,这很有用:It can be useful for isolating messages that meet the following criteria:
    • 接收应用程序无法成功处理消息Messages can't be processed successfully by the receiving application
    • 消息因生存时间 (TTL) 属性过期而无法到达目的地。Messages can't reach their destination because of an expired time-to-live (TTL) property. TTL 值指定消息在队列中保留的时间。The TTL value specifies how long a message remains in the queue. 对于服务总线,在 TTL 期限过期时,该消息将移到一个特殊的队列(称为 $DeadLetterQueue)。With Service Bus, the message will be moved to a special queue called $DeadLetterQueue when the TTL period expires.
  • 为了在存储队列中查找“病毒”消息,在将某个消息取消排队时,应用程序将检查该消息的 DequeueCount 属性。To find "poison" messages in Storage queues, when dequeuing a message the application examines the DequeueCount property of the message. 如果 DequeueCount 大于给定的阈值,应用程序会将消息移到应用程序定义的“死信”队列。If DequeueCount is greater than a given threshold, the application moves the message to an application-defined "dead letter" queue.
  • 利用存储队列,可以获取针对该队列执行的所有事务的详细日志以及聚合指标。Storage queues enable you to obtain a detailed log of all of the transactions executed against the queue, and aggregated metrics. 这两个选项可用于调试和了解应用程序如何使用存储队列。Both of these options are useful for debugging and understanding how your application uses Storage queues. 它们还用于对应用程序进行性能优化并降低使用队列的成本。They're also useful for performance-tuning your application and reducing the costs of using queues.
  • 服务总线支持的消息会话使属于逻辑组的消息能够与接收方关联。Message sessions supported by Service Bus enable messages that belong to a logical group to be associated with a receiver. 它会在消息及其各自的接收方之间创建类似于会话的关联。It creates a session-like affinity between messages and their respective receivers. 可以通过对消息设置 SessionID 属性,在服务总线中启用此高级功能。You can enable this advanced functionality in Service Bus by setting the SessionID property on a message. 然后,接收者可以侦听特定会话 ID,并接收共享特定会话标识符的消息。Receivers can then listen on a specific session ID and receive messages that share the specified session identifier.
  • 服务总线队列的重复检测功能会根据 MessageId 属性的值自动删除发送到队列或主题的重复消息。The duplication detection feature of Service Bus queues automatically removes duplicate messages sent to a queue or topic, based on the value of the MessageId property.

容量和配额Capacity and quotas

本节从适用的容量和配额角度比较存储队列和服务总线队列。This section compares Storage queues and Service Bus queues from the perspective of capacity and quotas that may apply.

比较条件Comparison Criteria 存储队列Storage queues 服务总线队列Service Bus queues
最大队列大小Maximum queue size 500 TB500 TB

(限制为单个存储帐户容量(limited to a single storage account capacity)
1 GB 到 80 GB1 GB to 80 GB

(在创建队列和启用分区时定义 - 请参阅“其他信息”部分)(defined upon creation of a queue and enabling partitioning - see the "Additional Information" section)
最大消息大小Maximum message size 64 KB64 KB

(使用 Base64 编码时为 48 KB)(48 KB when using Base64 encoding)

Azure 可以通过合并队列和 Blob 支持大消息 - 此时单个项目排队的消息最多可达到 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 KB1 MB256 KB or 1 MB

(包含标头和正文,最大标头大小:64 KB)。(including both header and body, maximum header size: 64 KB).

取决于服务层级Depends on the service tier.
最大消息 TTLMaximum message TTL 无限(API 版本 2017-07-27 或更高版本)Infinite (api-version 2017-07-27 or later) TimeSpan.MaxTimeSpan.Max
最大队列数Maximum number of queues 不受限制Unlimited 10,00010,000

(按服务命名空间)(per service namespace)
并发客户端的最大数目Maximum number of concurrent clients 无限制Unlimited 5,0005,000

其他信息Additional information

  • 服务总线强制实施队列大小限制。Service Bus enforces queue size limits. 创建队列时指定最大队列大小。The maximum queue size is specified when creating a queue. 大小可以介于 1 GB 和 80 GB 之间。It can be between 1 GB and 80 GB. 如果队列的大小达到此限制,则其他传入消息将遭到拒绝,并且调用方会收到异常。If the queue's size reaches this limit, additional incoming messages will be rejected and the caller receives an exception. 有关服务总线中配额的详细信息,请参阅服务总线配额For more information about quotas in Service Bus, see Service Bus Quotas.
  • 高级层不支持分区。Partitioning isn't supported in the Premium tier. 在标准消息传递层中,可以创建 1(默认值)、2、3、4 或 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. 启用分区后,服务总线将创建实体的 16 个副本(16 个分区),每个副本具有指定的相同大小。With partitioning enabled, Service Bus creates 16 copies (16 partitions) of the entity, each of the same size specified. 因此,如果你创建了一个大小为 5 GB 的队列,共有 16 个分区,最大队列大小为 (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. 可以在 Azure 门户中查看分区队列或主题的最大大小。You can see the maximum size of your partitioned queue or topic in the Azure portal.
  • 在存储队列中,如果消息的内容不属于 XML 安全内容,则必须对其进行 Base64 编码。With Storage queues, if the content of the message isn't XML-safe, then it must be Base64 encoded. 如果使用 Base64 编码此消息,则用户负载可高达 48 KB,而不是 64 KB。If you Base64-encode the message, the user payload can be up to 48 KB, instead of 64 KB.
  • 对于服务总线队列,存储在队列中的每条消息由两个部分组成:标头和正文。With Service Bus queues, each message stored in a queue is composed of two parts: a header and a body. 消息的总大小不能超过服务层级支持的最大消息大小。The total size of the message can't exceed the maximum message size supported by the service tier.
  • 当客户端通过 TCP 协议与服务总线队列进行通信时,到单个服务总线队列的最大并发连接数不得超过 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. 此数值在发送方和接收方之间共享。This number is shared between senders and receivers. 如果达到此配额,则其他连接请求将遭到拒绝,并且调用代码将收到异常。If this quota is reached, requests for additional connections will be rejected and an exception will be received by the calling code. 使用基于 REST 的 API 连接到队列的客户端不受此限制。This limit isn't imposed on clients connecting to the queues using REST-based API.
  • 如果在单个服务总线服务命名空间中需要超过 10,000 个队列,可以联系 Azure 支持团队并请求增加数目。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. 若要使用服务总线扩展到 10,000 个以上的队列,还可使用 Azure 门户创建其他服务命名空间。To scale beyond 10,000 queues with Service Bus, you can also create additional namespaces using the Azure portal.

管理和操作Management and operations

本部分对存储队列和服务总线队列提供的管理功能进行了比较。This section compares the management features provided by Storage queues and Service Bus queues.

比较条件Comparison Criteria 存储队列Storage queues 服务总线队列Service Bus queues
管理协议Management protocol 基于 HTTP/HTTPS 的 RESTREST over HTTP/HTTPS 基于 HTTPS 的 RESTREST over HTTPS
运行时协议Runtime protocol 基于 HTTP/HTTPS 的 RESTREST over HTTP/HTTPS 基于 HTTPS 的 RESTREST over HTTPS

AMQP 1.0 标准(具有 TLS 的 TCP)AMQP 1.0 Standard (TCP with TLS)

(.NET 存储客户端 API)(.NET Storage Client API)

(.NET 服务总线 API)(.NET Service Bus API)
本机 C++Native C++ Yes Yes
Java APIJava API Yes Yes
Node.js APINode.js API Yes Yes
任意元数据支持Arbitrary metadata support Yes No
队列命名规则Queue naming rules 长度最多为 63 个字符Up to 63 characters long

(队列名称中的字母必须小写。)(Letters in a queue name must be lowercase.)
长度最多为 260 个字符Up to 260 characters long

(队列路径和名称不区分大小写。)(Queue paths and names are case-insensitive.)
获取队列长度函数Get queue length function Yes

(在消息超出 TTL 但未删除的情况下的近似值。)(Approximate value if messages expire beyond the TTL without being deleted.)

(精确时间点值。)(Exact, point-in-time value.)
Peek 函数Peek function Yes Yes

其他信息Additional information

  • 存储队列为可应用于队列说明的任意属性提供支持(以名称/值对形式)。Storage queues provide support for arbitrary attributes that can be applied to the queue description, in the form of name/value pairs.
  • 两种队列技术还提供无需锁定消息即可进行消息扫视的功能,这在实现队列资源管理器/浏览器工具时可能非常有用。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.
  • 服务总线 .NET 中转消息传送 API 使用全双工 TCP 连接,因此与基于 HTTP 的 REST 相比提高了性能,另外它们还支持 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.
  • 存储队列名称长度可以在 3-63 个字符之间,可以包含小写字母、数字和连字符。Names of Storage queues can be 3-63 characters long, can contain lowercase letters, numbers, and hyphens. 有关详细信息,请参阅 命名队列和元数据For more information, see Naming Queues and Metadata.
  • 服务总线队列名称长度最大可达 260 个字符,且命名规则限制较少。Service Bus queue names can be up to 260 characters long and have less restrictive naming rules. 服务总线队列名称可以包含字母、数字、句点、连字符和下划线。Service Bus queue names can contain letters, numbers, periods, hyphens, and underscores.

身份验证和授权Authentication and authorization

本部分讨论存储队列和服务总线队列支持的身份验证和授权功能。This section discusses the authentication and authorization features supported by Storage queues and Service Bus queues.

比较条件Comparison Criteria 存储队列Storage queues 服务总线队列Service Bus queues
身份验证Authentication 对称密钥Symmetric key 对称密钥Symmetric key
安全模型Security model 通过 SAS 令牌进行的委托访问。Delegated access via SAS tokens. SASSAS
标识提供者联合Identity provider federation No Yes

其他信息Additional information

  • 针对任一队列技术的每个请求都必须进行身份验证。Every request to either of the queuing technologies must be authenticated. 不支持使用匿名访问的公共队列。Public queues with anonymous access aren't supported. 使用 SAS,可以通过发布只写 SAS、只读 SAS 甚至完全访问权限 SAS 来满足这种方案的需求。Using SAS, you can address this scenario by publishing a write-only SAS, read-only SAS, or even a full-access SAS.
  • 由存储队列提供的身份验证方案涉及对称密钥的使用。The authentication scheme provided by Storage queues involves the use of a symmetric key. 此密钥是基于哈希的消息身份验证码 (HMAC),使用 SHA-256 算法进行计算并编码为 Base64 字符串。This key is a hash-based Message Authentication Code (HMAC), computed with the SHA-256 algorithm and encoded as a Base64 string. 有关相应协议的详细信息,请参阅 Authentication for the Azure Storage Services(Azure 存储服务的身份验证)。For more information about the respective protocol, see Authentication for the Azure Storage Services. 服务总线队列支持使用对称密钥的类似模型。Service Bus queues support a similar model using symmetric keys. 有关详细信息,请参阅 使用服务总线进行共享访问签名身份验证For more information, see Shared Access Signature Authentication with Service Bus.


通过更深入地了解这两种技术,可以就使用哪种队列技术以及何时使用做出更明智的决策。By gaining a deeper understanding of the two technologies, you can make a more informed decision on which queue technology to use, and when. 决定何时使用存储队列或服务总线队列时,显然要考虑很多因素。The decision on when to use Storage queues or Service Bus queues clearly depends on a number of factors. 这些因素很大程度上取决于应用程序及其体系结构的独特需要。These factors may depend heavily on the individual needs of your application and its architecture.

出于以下原因,可能更愿意选择存储队列:You may prefer to choose Storage queues for reasons such as the following ones:

  • 如果应用程序已使用 Azure 的核心功能If your application already uses the core capabilities of Azure
  • 如果需要在服务之间进行基本通信和消息传递If you require basic communication and messaging between services
  • 需要大小超过 80 GB 的队列Need queues that can be larger than 80 GB in size

服务总线队列提供了许多高级功能,例如以下功能。Service Bus queues provide a number of advanced features such as the following ones. 因此,如果要构建混合应用程序,或者应用程序需要这些功能,则应首选这些功能。So, they may be a preferred choice if you're building a hybrid application or if your application otherwise requires these features.

后续步骤Next steps

以下文章提供了有关使用存储队列或服务总线队列的更多指导和信息。The following articles provide more guidance and information about using Storage queues or Service Bus queues.