存储队列和服务总线队列 - 比较与对照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 today: Storage queues and Service Bus queues. 使用该信息可以比较和对照这两种技术,并可以明智地决定哪种解决方案最符合需要。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.

简介Introduction

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

存储队列是 Azure 存储基础结构的一部分,具有简单的基于 REST 的 GET/PUT/PEEK 接口,可在服务内部和服务之间提供可靠、持久的消息传送。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.

服务总线队列是更广的 Azure 消息传送基础结构的一部分,可支持队列以及发布/订阅和更高级的集成模式。Service Bus queues are part of a broader Azure messaging infrastructure that supports queuing as well as publish/subscribe, and more advanced integration patterns. 有关服务总线队列/主题/订阅的详细信息,请参阅服务总线概述For more information about Service Bus queues/topics/subscriptions, see the overview of Service Bus.

两种队列技术同时存在时,首先引入的是存储队列,这是一种基于 Azure 存储服务构建的专用队列存储机制。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 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.

技术选择注意事项Technology selection considerations

存储队列和服务总线队列都是 Azure 目前提供的消息队列服务的实现形式。Both Storage queues and Service Bus queues are implementations of the message queuing service currently offered by Azure. 两种队列的功能集略有不同,这意味着可以选择其中一种,或者同时使用这两种,具体取决于特定解决方案或要解决的业务/技术问题的需要。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.

在确定哪种队列技术适合给定的解决方案时,解决方案架构师和开发人员应考虑以下建议。When determining which queuing technology fits the purpose for a given solution, solution architects and developers should consider these recommendations. 有关更多详细信息,请参阅下一部分。For more details, see the next section.

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

  • 应用程序必须在队列中存储超过 80 GB 的消息。Your application must store over 80 GB of messages in a queue.
  • 应用程序需要跟踪队列内部消息的处理进度。Your application wants to track progress for processing a message inside of the queue. 这在处理消息的工作进程发生崩溃时很有用。This is useful if the worker processing a message crashes. 然后,后续的工作线程可以使用该信息从之前的工作线程停止处继续。A subsequent 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.

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

  • 解决方案必须能够在无需轮询队列的情况下接收消息。Your solution must be able to receive messages without having to poll the queue. 有了服务总线,就可以使用服务总线支持的基于 TCP 的协议,通过长轮询接收操作实现这一点。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.
  • 解决方案要求队列必须遵循先入先出 (FIFO) 的传递顺序。Your solution requires the queue to provide a guaranteed first-in-first-out (FIFO) ordered delivery.
  • 解决方案必须能够支持自动重复检测。Your solution must be able 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 will not 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.
  • 队列大小不会增长到超过 80 GB。Your queue size will not 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 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. 消息交换模式是服务总线本机提供的发布/订阅功能。The latter refers to the publish/subscribe capability natively provided by Service Bus.
  • 消息传送解决方案必须能够支持“至多一次”传递保障,而无需构建其他基础结构组件。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.
  • 希望能够发布并使用消息批处理。You would like to be able to publish and consume batches of messages.

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

以下部分中的表提供了队列特征的逻辑分组,使你可以快速比较 Azure 存储队列和服务总线队列提供的功能。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.

基础功能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 messaging sessions)
传递保障Delivery guarantee 至少一次At-Least-Once 至少一次At-Least-Once

至多一次At-Most-Once
原子操作支持Atomic operation support No Yes

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

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

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

非阻止Non-blocking

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

OnMessageOnMessage 会话 .NET API。OnMessage and 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)
Yes

(隐式启用预提取属性或通过使用事务显式启用)(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 a message's visibility timeout duration expires (for example, as a result of a client application crashing during processing). 当可见性超时到期时,消息会再次变成在队列上可见,让另一个工作进程能够取消它的排队。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) after a message that was originally enqueued after it.
  • 服务总线队列中有保障的 FIFO 模式要求使用消息传送会话。The guaranteed FIFO pattern in Service Bus queues requires the use of messaging sessions. 处理以“扫视与锁定”模式接收的消息时,如果应用程序发生崩溃,下一次队列接收者接受消息传送会话时,它将在失败消息的生存时间 (TTL) 期限过期后开始传递此消息。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 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.
  • 服务总线队列支持“至少一次”传递保障 。Service Bus queues support the At-Least-Once delivery guarantee.
  • 可以避免在服务总线会话上下文中处理消息时出现的不一致,方法是:使用会话状态来存储应用程序的状态(与处理会话的消息序列的进程相关),以及使用与处理接收的消息和更新会话状态相关的事务。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, but transaction failures will obviously cause messages to be redeliveried and therefore the term is not 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 allows the workers to maintain short leases on messages. 因此,如果某个工作进程崩溃,则其他工作进程可以再次快速处理该消息。Thus, if a worker crashes, the message can be quickly processed again by another worker. 此外,如果工作进程处理消息所需的时间比当前租赁时间长,则工作进程可以延长该消息的租赁时间。In addition, 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. 此外,可以在运行时使用不同租赁值更新消息,并且可以跨同一队列的消息更新不同值。In addition, you can update a message with different lease values at run-time, and update different values across messages in the same queue. 服务总线锁定超时值在队列元数据中定义,但是可通过调用 RenewLock 方法续订该锁。Service Bus lock timeouts are defined in the queue metadata; 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)
Yes

(通过一个专用 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, 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.
Yes

(通过调用 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 auto-forwarding 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 auto-forwarding enables thousands of queues to auto-forward 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).
  • 死信(仅受服务总线队列支持)可用于隔离接收应用程序无法成功处理的消息,或隔离由于生存时间 (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 值指定消息在队列中保留的时间。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, as well as aggregated metrics. 这两个选项可用于调试以及了解应用程序如何使用存储队列。Both of these options are useful for debugging and understanding how your application uses Storage queues. 它们还用于对应用程序进行性能优化并降低使用队列的成本。They are also useful for performance-tuning your application and reducing the costs of using queues.
  • 服务总线支持的“消息会话”概念允许属于特定逻辑组的消息与给定的接收方关联,而这样一来又能在消息与其各自接收方之间创建类似于会话的关联。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. 可以通过对消息设置 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 functionality supported by 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-version 2017-07-27 开始)Infinite (as of api-version 2017-07-27) TimeSpan.MaxTimeSpan.Max
最大队列数Maximum number of queues 不受限制Unlimited 10,00010,000

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

(100 个并发连接限制仅适用于基于 TCP 协议的通信)(100 concurrent connection limit only applies to TCP protocol-based communication)

其他信息Additional information

  • 服务总线强制实施队列大小限制。Service Bus enforces queue size limits. 在创建队列时指定最大队列大小,其值可以在 1 至 80 GB 之间。The maximum queue size is specified upon creation of the queue and can have a value between 1 and 80 GB. 如果达到创建队列时设置的队列大小值,则将拒绝其他传入消息,并且调用代码收到一个异常。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. 有关服务总线中配额的详细信息,请参阅服务总线配额For more information about quotas in Service Bus, see Service Bus Quotas.

  • 高级层不支持分区。Partitioning is not supported in the Premium tier. 在标准层中,可以创建 1GB、2GB、3GB、4GB 或 5GB 大小的服务总线队列(默认值为 1GB)。In the Standard tier, you can create Service Bus queues in 1, 2, 3, 4, or 5 GB sizes (the default is 1 GB). 在标准层中,启用分区(这是默认值)时,服务总线将指定的每个 GB 创建 16 个分区。In Standard tier, with partitioning enabled (which is the default), Service Bus creates 16 partitions for each GB you specify. 因此,如果你创建了一个大小为 5 GB 的队列,由于每 GB 16 个分区,最大队列大小将变为 (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. 可以通过在 Azure 门户中查看分区队列或主题的条目来了解该队列或主题的最大大小。You can see the maximum size of your partitioned queue or topic by looking at its entry on the Azure portal.

  • 在存储队列中,如果消息的内容不属于 XML 安全内容,则必须对其进行 Base64 编码。With Storage queues, if the content of the message is not 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 cannot 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, subsequent requests for additional connections will be rejected and an exception will be received by the calling code. 使用基于 REST 的 API 连接到队列的客户端不受此限制。This limit is not 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 API Yes

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

(.NET 服务总线 API)(.NET Service Bus API)
本机 C++Native C++ Yes Yes
Java APIJava API Yes Yes
PHP APIPHP 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.)
Yes

(精确时间点值。)(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 leverage 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 are not 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.
  • 存储队列提供的身份验证方案涉及对称密钥的运用,该密钥是基于哈希的消息身份验证代码 (HMAC),使用 SHA-256 算法计算并编码为 Base64 字符串。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. 有关相应协议的详细信息,请参阅 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.

结论Conclusion

通过更深入地了解这两种技术,能够就使用哪种队列技术以及何时使用做出更明智的决策。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. 决定何时使用存储队列或服务总线队列时,显然要考虑很多因素。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. 如果应用程序已使用 Azure 的核心功能,则可能更倾向于选择存储队列,尤其在服务之间需要基本通信和消息传送或需要大小可大于 80 GB 的队列时。If your application already uses the core capabilities of 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.

因为服务总线队列提供许多高级功能(如会话、事务、重复检测、自动死信和持久发布/订阅功能),所以,如果正在构建混合应用程序或应用程序需要这些功能,这些队列将是首选。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.

后续步骤Next steps

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