Azure 服务总线中的限制操作Throttling operations on Azure Service Bus

云原生解决方案提供了一种无限资源概念,可以根据工作负荷的需求来缩放资源。Cloud native solutions give a notion of unlimited resources that can scale with your workload. 尽管这种概念在云中比在本地系统中体现得更为透彻,但云中仍然存在一些限制。While this notion is more true in the cloud than it is with on-premises systems, there are still limitations that exist in the cloud.

这些限制可能会导致标准层和高级层中的客户端应用程序请求受到限制,如本文中所述。These limitations may cause throttling of client application requests in both Standard and Premium tiers as discussed in this article.

Azure 服务总线标准层中的限制Throttling in Azure Service Bus Standard tier

Azure 服务总线标准层以多租户设置形式运行,采用标准预付费套餐定价模型。The Azure Service Bus Standard tier operates as a multi-tenant setup with a Standard Pay-in-Advance Offer pricing model. 此处,同一群集中的多个命名空间共享已分配的资源。Here multiple namespaces in the same cluster share the allocated resources. 标准层是建议用于开发人员、测试和 QA 环境以及低吞吐量生产系统的选项。Standard tier is the recommended choice for developer, testing, and QA environments along with low throughput production systems.

过去,Azure 服务总线根据资源利用率严格实施粗略限制。In the past, Azure Service Bus had coarse throttling limits strictly dependent on resource utilization. 但是,仍有机会优化限制逻辑,并为共享这些资源的所有命名空间提供可预测的限制行为。However, there is an opportunity to refine the throttling logic and provide predictable throttling behavior to all namespaces that are sharing these resources.

为了尝试在使用相同资源的所有 Azure 服务总线标准命名空间之间确保公平的资源使用和分配,我们已将限制逻辑修改为基于额度。In an attempt to ensure fair usage and distribution of resources across all the Azure Service Bus Standard namespaces that use the same resources, the throttling logic has been modified to be credit-based.


必须注意的是,限制并不是 Azure 服务总线或任何云原生服务中的新概念。It is important to note that throttling is not new to Azure Service Bus, or any cloud native service.

基于额度的限制只是优化了不同命名空间在多租户标准层环境中共享资源的方式,从而使得共享资源的所有命名空间的资源使用公平化。Credit based throttling is simply refining the way various namespaces share resources in a multi-tenant Standard tier environment and thus enabling fair usage by all namespaces sharing the resources.

什么是基于额度的限制?What is credit-based throttling?

基于额度的限制用于限制特定时间段内可以针对给定命名空间执行的操作数目。Credit-based throttling limits the number of operations that can be performed on a given namespace in a specific time period.

下面是基于额度的限制的工作流 -Below is the workflow for credit-based throttling -

  • 在每个时间段开始时,我们为每个命名空间提供特定数目的额度。At the start of each time period, we provide a certain number of credits to each namespace.
  • 发送方或接收方客户端应用程序执行的任何操作都会计入这些额度(并从可用额度中扣除)。Any operations performed by the sender or receiver client applications will be counted against these credits (and subtracted from the available credits).
  • 如果用尽了额度,后续操作将一直受到限制,直到下一个时间段开始。If the credits are depleted, subsequent operations will be throttled until the start of the next time period.
  • 在下一个时间段开始时时,将会补充额度。Credits are replenished at the start of the next time period.

什么是额度限制?What are the credit limits?

额度限制当前设置为每秒(每个命名空间)“1000”额度。The credit limits are currently set to '1000' credits every second (per namespace).

并非所有操作都是均等创建的。Not all operations are created equal. 下面是每个操作的额度成本 -Here are the credit costs of each of the operations -

操作Operation 额度成本Credit cost
数据操作(发送、异步发送、接收、异步接收、扫视)Data operations (Send, SendAsync, Receive, ReceiveAsync, Peek) 每条消息 1 个额度1 credit per message
管理操作(针对队列、主题、订阅和筛选器执行的创建、读取、更新、删除)Management operations (Create, Read, Update, Delete on Queues, Topics, Subscriptions, Filters) 10 个额度10 credits


请注意,发送到主题时,在将消息显示在订阅中之前,会先根据筛选器评估每条消息。Please note that when sending to a Topic, each message is evaluated against filter(s) before being made available on the Subscription. 每个筛选器评估也会计入额度限制(即,每个筛选器评估 1 个额度)。Each filter evaluation also counts against the credit limit (i.e. 1 credit per filter evaluation).

如何知道我受到了限制?How will I know that I'm being throttled?

当客户端应用程序请求受到限制时,应用程序会收到并记录以下服务器响应。When the client application requests are being throttled, the below server response will be received by your application and logged.

The request was terminated because the entity is being throttled. Error code: 50009. Please wait 2 seconds and try again.

如何避免受到限制?How can I avoid being throttled?

使用共享资源时,必须在共享这些资源的各个服务总线命名空间之间强制实施某种公平使用方案。With shared resources, it is important to enforce some sort of fair usage across various Service Bus namespaces that share those resources. 限制可以确保单个工作负荷中出现任何高峰不会导致同一资源上的其他工作负荷受到限制。Throttling ensures that any spike in a single workload does not cause other workloads on the same resources to be throttled.

如本文稍后所述,受到限制不会带来任何风险,因为客户端 SDK(以及其他 Azure PaaS 产品/服务)内置了默认重试策略。As mentioned later in the article, there is no risk in being throttled because the client SDKs (and other Azure PaaS offerings) have the default retry policy built into them. 将使用指数退避重试任何受限请求,在补充额度后,这些请求最终将会顺利传送。Any throttled requests will be retried with exponential backoff and will eventually go through when the credits are replenished.

可以理解的是,某些应用程序可能对限制非常敏感。Understandably, some applications may be sensitive to being throttled. 在这种情况下,建议将当前服务总线标准命名空间迁移到高级层In that case, it is recommended to migrate your current Service Bus Standard namespace to Premium.

迁移时,可将专用资源分配到服务总线命名空间,在工作负荷中出现高峰时适当地纵向扩展资源,并减少受到限制的可能性。On migration, you can allocate dedicated resources to your Service Bus namespace and appropriately scale up the resources if there is a spike in your workload and reduce the likelihood of being throttled. 此外,当工作负荷降低到正常水平时,可以纵向缩减分配给命名空间的资源。Additionally, when your workload reduces to normal levels, you can scale down the resources allocated to your namespace.

Azure 服务总线高级层中的限制Throttling in Azure Service Bus Premium tier

Azure 服务总线高级层以消息传送单元的形式向客户设置的每个命名空间分配专用资源。The Azure Service Bus Premium tier allocates dedicated resources, in terms of messaging units, to each namespace setup by the customer. 这些专用资源提供可预测的吞吐量和延迟,建议将其用于高吞吐量或敏感型的生产级系统。These dedicated resources provide predictable throughput and latency and are recommended for high throughput or sensitive production grade systems.

此外,高级层还可让客户在工作负荷中出现高峰时纵向扩展其吞吐量容量。Additionally, the Premium tier also enables customers to scale up their throughput capacity when they experience spikes in the workload.

服务总线高级层中的限制的工作原理是什么?How does throttling work in Service Bus Premium?

为服务总线高级层使用独占资源分配时,限制是由分配给命名空间的资源限制驱动的。With exclusive resource allocation for Service Bus Premium, throttling is purely driven by the limitations of the resources allocated to the namespace.

如果请求数超过了当前资源可以服务的数量,则请求将受到限制。If the number of requests are more than the current resources can service, then the requests will be throttled.

如何知道我受到了限制?How will I know that I'm being throttled?

可以通过多种方式确定在 Azure 服务总线高级层中是否受到了限制 -There are various ways to identifying throttling in Azure Service Bus Premium -

  • 可以通过 Azure Monitor 请求指标中显示的“限制的请求数”来确定有多少个请求受到限制。Throttled Requests show up on the Azure Monitor Request metrics to identify how many requests were throttled.
  • 较高的“CPU 使用率”表示当前资源分配量较高,如果当前工作负荷没有降低,则请求可能会受到限制。High CPU Usage indicates that current resource allocation is high and requests may get throttled if the current workload doesn't reduce.
  • 较高的“内存使用率”表示当前资源分配量较高,如果当前工作负荷没有降低,则请求可能会受到限制。High Memory Usage indicates that current resource allocation is high and requests may get throttled if the current workload doesn't reduce.

如何避免受到限制?How can I avoid being throttled?

由于服务总线高级层命名空间已有专用资源,因此,在工作负荷中出现高峰(或预期会出现高峰)时,可以通过增加分配给命名空间的消息传送单元数来减少受到限制的可能性。Since the Service Bus Premium namespace already has dedicated resources, you can reduce the possibility of getting throttled by scaling up the number of Messaging Units allocated to your namespace in the event (or anticipation) of a spike in the workload.

可以创建可由上述指标的更改触发的 Runbook,用以实现纵向扩展/缩减。Scaling up/down can be achieved by creating runbooks that can be triggered by changes in the above metrics.


限制会对我的应用程序造成什么影响?How does throttling affect my application?

某个请求受到限制意味着服务繁忙,因为该服务面对的请求数超过了资源允许的数量。When a request is throttled, it implies that the service is busy because it is facing more requests than the resources allow. 如果在一段时间后重试相同的操作,一旦服务处理完其当前工作负荷,就可以满足该请求的要求。If the same operation is tried again after a few moments, once the service has worked through its current workload, then the request can be honored.

由于限制是任何云原生服务的预期行为,因此我们已在 Azure 服务总线 SDK 本身中内置了重试逻辑。Since throttling is the expected behavior of any cloud native service, we have built the retry logic into the Azure Service Bus SDK itself. 默认重试逻辑设置为使用指数退避自动重试,以确保不会每次都限制同一个请求。The default is set to auto retry with an exponential back-off to ensure that we don't have the same request being throttled each time.

默认重试逻辑将应用于每个操作。The default retry logic will apply to every operation.

限制是否会导致数据丢失?Does throttling result in data loss?

Azure 服务总线已针对持久性进行优化,我们会确保在服务确认请求成功之前,发送到服务总线的所有数据将提交到存储。Azure Service Bus is optimized for persistence, we ensure that all the data sent to Service Bus is committed to storage before the service acknowledges the success of the request.

一旦服务总线成功“ACK”(确认)请求,即表示服务总线已成功处理该请求。Once the request is successfully 'ACK' (acknowledged) by Service Bus, it implies that Service Bus has successfully processed the request. 如果服务总线返回“NACK”(失败),则表示服务总线无法处理该请求,客户端应用程序必须重试该请求。If Service Bus returns a 'NACK' (failure), then it implies that Service Bus has not been able to process the request and the client application must retry the request.

但是,如果某个请求受到限制,则表示服务当前无法接受并处理该请求,因为存在资源限制。However, when a request is throttled, the service is implying that it cannot accept and process the request right now because of resource limitations. 这并意味着发生了任何形式的数据丢失,因为服务总线只是未查看该请求。This does not imply any sort of data loss because Service Bus simply hasn't looked at the request. 在这种情况下,依赖于服务总线 SDK 的默认重试策略可确保该请求最终会得到处理。In this case, relying on the default retry policy of the Service Bus SDK ensures that the request is eventually processed.

后续步骤Next steps

有关使用服务总线消息传送的详细信息和示例,请参阅以下高级主题:For more information and examples of using Service Bus messaging, see the following advanced topics: