通过

请求速率限制策略

  • 项目

适用于：✅Azure 数据资源管理器

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

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

策略对象

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

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

并发请求速率限制

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

名称 Type 说明 支持的值
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 的请求速率限制包含以下属性：

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

当 ResourceKind 为 TotalCpuSeconds 时，将基于已完成请求的 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 10 = 160。

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

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

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
    }
  },
]

相关内容