你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

请求速率限制策略

通过工作负荷组的请求速率限制策略,可限制每个工作负荷组或每个主体的已归类到工作负荷组的并发请求数。

速率限制在工作负荷组的请求速率限制强制实施策略定义的级别强制实施。

策略对象

请求速率限制策略具有以下属性:

名称 支持的值 说明
IsEnabled true, false 指示是否启用策略。
范围 WorkloadGroup, Principal 应用限制的范围。
LimitKind ConcurrentRequests, ResourceUtilization 请求速率限制的类型。
属性 属性包 请求速率限制的属性。

并发请求速率限制

类型 ConcurrentRequests 的请求速率限制包含以下属性:

名称 类型 说明 支持的值
MaxConcurrentRequests int 最大并发请求数。 [0, 10000]

注意

  • 如果工作负荷组对最大并发请求数没有指定限制,则受 默认最大值 的约束 10000

在请求超出最大并发请求数限制时:

  • 系统信息命令呈现的请求状态将会是 Throttled
  • 错误消息会包括限制的源和已超过的容量 。

下表显示了一些超出最大限制的并发请求示例,以及这些请求返回的错误消息:

方案 错误消息
已归类到 default 工作负荷组的受限制的 .create table 命令,其在工作负荷组范围内的并发请求数限制为 80。 由于限制,管理命令已中止。 在进行某些回退后重试可能会成功。 CommandType: "TableCreate"、容量: 80、源: "RequestRateLimitPolicy/WorkloadGroup/default"。
已归类到名为 MyWorkloadGroup 工作负荷组的受限制的查询,其在工作负荷组范围内的并发请求数限制为 50。 由于限制,查询已中止。 在进行某些回退后重试可能会成功。 容量: 50,源: "RequestRateLimitPolicy/WorkloadGroup/MyWorkloadGroup"。
已归类到名为 MyWorkloadGroup 工作负荷组的受限制的查询,其在主体范围内的并发请求数限制为 10。 由于限制,查询已中止。 在进行某些回退后重试可能会成功。 容量: 10,源: "RequestRateLimitPolicy/WorkloadGroup/MyWorkloadGroup/Principal/aaduser=9e04c4f5-1abd-48d4-a3d2-9f58615b4724;6ccf3fe8-6343-4be5-96c3-29a128dd9570"。
  • HTTP 响应代码将会是 429。 子代码将会是 TooManyRequests
  • 异常类型将会是 QueryThrottledException(对于查询)和 ControlCommandThrottledException(对于管理命令)。

注意

  • 如果超出容量策略或请求速率限制策略定义的任何一种限制,则会限制管理命令。
  • 容量策略可能会限制属于特定类别的请求的请求速率,例如引入。

资源利用率速率限制

类型 ResourceUtilization 的请求速率限制包含以下属性:

名称 类型 说明 支持的值
ResourceKind ResourceKind 要限制的资源。

当 为 TotalCpuSecondsResourceKind,将根据已完成请求的 CPU 使用率的执行后报告强制执行限制。 报告 CPU 使用率为 0.005 秒或更低的请求不计入。 (MaxUtilization) 限制表示请求在指定时间范围内 (TimeWindow) 可以使用的总 CPU 秒数。 例如,运行即席查询的用户可能具有每小时 1000 CPU 秒的限制。 如果超出此限制,后续查询将受到限制,即使同时启动,因为累积 CPU 秒数已超过滑动窗口时间段内定义的限制。
RequestCount, TotalCpuSeconds
MaxUtilization long 可使用的资源的最大数量。 RequestCount:[1, 16777215];TotalCpuSeconds:[1, 828000]
TimeWindow timespan 应用限制的滑动时间窗口。 [00:01:00, 1.00:00:00]

在请求超出资源使用率的限制时:

  • 系统信息命令呈现的请求状态将会是 Throttled
  • 错误消息会包括限制的源和已超过的配额。 例如:

下表显示了一些超出资源利用率限制的请求示例,以及这些请求返回的错误消息:

方案 错误消息
已归类到名为 Automated Requests 工作负荷组的受限制的请求,其在主体范围内每小时的请求数限制为 1000。 该请求因超出配额限制而被拒绝。 资源: "RequestCount"、配额: "1000"、TimeWindow: "01:00:00"、源: "RequestRateLimitPolicy/WorkloadGroup/Automated Requests/Principal/aadapp=9e04c4f5-1abd-48d4-a3d2-9f58615b4724;6ccf3fe8-6343-4be5-96c3-29a128dd9570"。
已归类到名为 Automated Requests 工作负荷组的受限制的请求,其在工作负荷组范围内每小时的 CPU 总秒数限制为 2000。 该请求因超出配额限制而被拒绝。 资源: "TotalCpuSeconds"、配额: "2000"、TimeWindow: "01:00:00"、源: "RequestRateLimitPolicy/WorkloadGroup/Automated Requests"。
  • HTTP 响应代码将会是 429。 子代码将会是 TooManyRequests
  • 异常类型将会是 QuotaExceededException

一致性如何影响速率限制

使用强一致性时,最大并发请求数的默认限制取决于群集的 SKU,计算方式为: Cores-Per-Node x 10。 例如,使用 Azure D14_v2 节点设置的群集(其中每个节点有 16 个 vCore)的默认限制16为 x = 10160

对于弱一致性,最大并发请求数的有效默认限制取决于群集的 SKU 和查询头数,计算方式为: Cores-Per-Node x 10 x Number-Of-Query-Heads。 例如,使用 Azure D14_v2 和 5 个查询头设置的群集(其中每个节点有 16 个 vCore)的有效默认限制为 16 x 10 x8005 = 。

有关详细信息,请参阅 查询一致性

default 工作负荷组

默认情况下,default 工作负荷组定义了以下策略。 此策略可修改。

[
  {
    "IsEnabled": true,
    "Scope": "WorkloadGroup",
    "LimitKind": "ConcurrentRequests",
    "Properties": {
      "MaxConcurrentRequests": < Cores-Per-Node x 10 >
    }
  }
]

注意

  • 更改工作负荷组的策略 default 时,必须为最大并发请求数定义限制。

示例

以下策略最多允许:

  • 500 个并发请求(适用于工作负荷组)。
  • 每个主体 25 个并发请求。
  • 每个主体每小时 50 个请求。
[
  {
    "IsEnabled": true,
    "Scope": "WorkloadGroup",
    "LimitKind": "ConcurrentRequests",
    "Properties": {
      "MaxConcurrentRequests": 500
    }
  },
  {
    "IsEnabled": true,
    "Scope": "Principal",
    "LimitKind": "ConcurrentRequests",
    "Properties": {
      "MaxConcurrentRequests": 25
    }
  },
  {
    "IsEnabled": true,
    "Scope": "Principal",
    "LimitKind": "ResourceUtilization",
    "Properties": {
      "ResourceKind": "RequestCount",
      "MaxUtilization": 50,
      "TimeWindow": "01:00:00"
    }
  }
]

以下策略将阻止归类到工作负荷组的所有请求:

[
  {
    "IsEnabled": true,
    "Scope": "WorkloadGroup",
    "LimitKind": "ConcurrentRequests",
    "Properties": {
      "MaxConcurrentRequests": 0
    }
  },
]