Azure 服务总线中的限制操作
云原生解决方案提供了一种无限资源概念，可以根据工作负荷的需求来缩放资源。 尽管这种概念在云中比在本地系统中体现得更为透彻，但云中仍然存在一些限制。 这些限制可能会导致标准层和高级层中的客户端应用程序请求受到限制，如本文中所述。
标准层中的限制
Azure 服务总线标准层以多租户设置形式运行，采用标准预付费套餐定价模型。 此处，同一群集中的多个命名空间共享已分配的资源。 标准层是建议用于开发人员环境、QA 环境和低吞吐量生产系统的选项。
过去，服务总线根据资源利用率严格实施粗略限制。 但是，仍有机会微调限制逻辑，并为共享这些资源的所有命名空间提供可预测的限制行为。
为了尝试在使用相同资源的所有服务总线标准命名空间之间确保公平的资源使用和分配，服务总线标准层当前使用基于额度的限制逻辑。
注意
必须注意的是，限制并不是 Azure 服务总线或任何云原生服务中的新概念。
基于额度的限制只是优化了不同命名空间在多租户标准层环境中共享资源的方式，从而使得共享资源的所有命名空间的资源使用公平化。
什么是基于额度的限制？
基于额度的限制用于限制特定时间段内可以针对给定命名空间执行的操作数目。 下面是基于额度的限制的工作流。
- 在每个时间段开始时，服务总线为每个命名空间提供一些额度。
- 发送方或接收方客户端应用程序执行的任何操作都计入这些额度（并从可用额度中扣除）。
- 如果用尽了额度，后续操作将一直受到限制，直到下一个时间段开始。
- 在下一个时间段开始时时，将会补充额度。
什么是额度限制？
额度限制当前设置为每秒 1000 额度（每个命名空间）。 并非所有操作都是均等创建的。 下面是每个操作的额度成本。
| 操作 | 额度成本 |
|---|---|
数据操作（Send、SendAsync、Receive、ReceiveAsync、Peek） |
每条消息 1 个额度 |
管理操作（对队列、主题、订阅和筛选器执行的 Create、Read、Update、Delete） |
10 个额度 |
注意
发送到主题时，在将消息显示在订阅中之前，会先根据筛选器评估每条消息。 每个筛选器评估也会计入额度限制（即，每个筛选器评估 1 个额度）。
如何知道我受到了限制？
当客户端应用程序请求受到限制时，客户端应用程序将收到以下服务器响应。
The request was terminated because the entity is being throttled. Error code: 50009. Please wait 2 seconds and try again.
如何避免受到限制？
使用共享资源时，必须在共享这些资源的各个服务总线命名空间之间强制实施某种公平使用方案。 限制可以确保单个工作负载中出现任何高峰不会导致同一资源上的其他工作负载受到限制。 如本文稍后所述，受到限制不会带来任何风险，因为客户端软件开发工具包 (SDK)（以及其他 Azure PaaS 产品/服务）内置了默认重试策略。 使用指数退避重试任何受限请求，在补充额度后，这些请求最终会顺利传送。
可以理解的是，某些应用程序可能对限制非常敏感。 在这种情况下，我们建议将当前服务总线标准命名空间迁移到高级层。 迁移时，可将专用资源分配到服务总线命名空间，在工作负载中出现高峰时适当地纵向扩展资源，并减少受到限制的可能性。 此外，当工作负荷降低到正常水平时，可以纵向缩减分配给命名空间的资源。
高级层中的限制
服务总线高级层以消息传送单元的形式向客户设置的每个命名空间分配专用资源。 这些专用资源提供可预测的吞吐量和延迟，建议将其用于高吞吐量或敏感型的生产级系统。
服务总线高级层中的限制的工作原理是什么？
为高级层使用独占资源分配时，限制是由分配给命名空间的资源限制驱动的。 如果请求数超过了当前资源可以服务的数量，则请求会受到限制。
如何知道我受到了限制？
可以通过多种方式确定在 Azure 服务总线高级层中是否受到了限制。
- 可以通过 Azure Monitor 请求指标中显示的“限制的请求数”来确定有多少个请求受到限制。
- 较高的“CPU 使用率”表示当前资源分配量较高，如果当前工作负荷没有降低，则请求可能会受到限制。
- 较高的“内存使用率”表示当前资源分配量较高，如果当前工作负荷没有降低，则请求可能会受到限制。
如何避免受到限制？
由于服务总线高级层命名空间已有专用资源，因此，在工作负载中出现高峰（或预期会出现高峰）时，可以通过增加分配给命名空间的消息传送单元数来减少受到限制的可能性。
常见问题
限制会对我的应用程序造成什么影响？
某个请求受到限制意味着服务繁忙，因为该服务面对的请求数超过了资源允许的数量。 如果在一段时间后重试相同的操作，一旦服务处理完其当前工作负荷，就可以满足该请求的要求。
由于限制是任何云原生服务的预期行为，因此服务总线 SDK 本身中内置了重试逻辑。 默认重试逻辑设置为使用指数退避自动重试，以确保不会每次都限制同一个请求。 默认重试逻辑应用于每个操作。
注意
调用其他第三方服务的消息处理代码也可能受到这些其他服务的限制。 有关如何处理这些场景的详细信息，请参阅有关限制模式的文档。
限制是否会导致数据丢失？
Azure 服务总线针对持久性进行了优化。 我们会确保在服务确认请求成功之前，发送到服务总线的所有数据将提交到存储。
一旦服务总线成功确认请求，即表示服务总线已成功处理该请求。 如果服务总线返回失败响应，则表示服务总线无法处理该请求，客户端应用程序必须重试该请求。
但是，如果某个请求受到限制，则表示服务当前无法接受并处理该请求，因为存在资源限制。 这并不意味着发生了任何形式的数据丢失，因为服务总线只是未查看该请求。 在这种情况下，依赖于服务总线 SDK 的默认重试策略可确保该请求最终会得到处理。
相关内容
有关使用服务总线消息传送的详细信息和示例，请参阅以下高级主题：