速率限制
Azure DevOps Services
Azure DevOps 与许多软件即服务解决方案一样，使用多租户来降低成本并提高性能。 此设计使用户容易受到性能问题的影响，甚至当其他用户（其共享资源）的使用量激增时，甚至中断。 为了解决这些问题，Azure DevOps 会限制个人可以消耗的资源，以及他们可以对某些命令发出的请求量。 超过这些限制时，可能会延迟或阻止将来的请求。
当用户的请求被大量延迟时，该用户会收到一封电子邮件，并在 Web 中看到警告横幅。 对于生成服务帐户和没有电子邮件地址的其他人，项目集合管理员组的成员将收到电子邮件。 有关详细信息，请参阅 使用情况监视。
当单个用户的请求被阻止时，收到 HTTP 代码为 429 的响应 (收到过多的请求) ，消息类似于以下消息：
TF400733: The request has been canceled: Request was blocked due to exceeding usage of resource <resource name> in namespace <namespace ID>.
有关详细信息，请参阅以下文章：
当前速率限制
Azure DevOps 目前具有全局消耗限制。 当共享资源面临不堪重负的危险时，此限制会延迟单个用户发出的请求超出阈值。
全局消耗限制
当共享资源接近不堪重负时，此限制专门侧重于避免中断。 单个用户通常仅在发生以下情况之一时延迟其请求：
- 其中一个共享资源面临不知所措的风险
- 其个人使用量超过典型用户在 (滑动) 5 分钟窗口内的消耗量超过 200 倍
延迟量取决于用户的持续消耗级别。 延迟范围从每个请求的毫秒到 30 秒不等。 一旦消耗量变为零，或者资源不再不知所措，延迟就会在五分钟内停止。 如果消耗量仍然很高，则延迟可能会无限期地继续保护资源。
azure DevOps 吞吐量单位 (TSTU)
Azure DevOps 用户使用许多共享资源，消耗取决于许多因素。 例如：
- 将大量文件上传到版本控制会在数据库和存储帐户上创建大量负载。
- 复杂的工作项跟踪查询根据搜索的工作项数创建数据库负载。
- 通过从版本控制下载文件、生成日志输出等来生成驱动器负载。
- 所有操作都会在服务的各个部分占用 CPU 和内存。
为了适应所有这些情况，Azure DevOps 资源消耗以称为 Azure DevOps 吞吐量单位或 TSTU 的抽象单元表示。
TSTU 最终合并了以下内容的混合：
- Azure SQL数据库 DTU 作为数据库消耗度量值
- 应用程序层和作业代理 CPU、内存和 I/O 作为计算消耗的度量值
- Azure 存储带宽作为存储消耗的度量值
目前，TTU 主要侧重于Azure SQL数据库 DTU，因为Azure SQL数据库是最常因过度消耗而不知所措的共享资源。
单个 TSTU 是预期 Azure DevOps 的单个普通用户每 5 分钟生成的平均负载。 普通用户还会在负载中生成峰值。 这些峰值通常是每五分钟 10 个或更少的 TTU。 频率较低，峰值高达 100 个 TTU。 在滑动五分钟的窗口中，全局消耗限制为 200 个 TTU。
管道
Azure Pipelines 的速率限制类似。 每个管道都被视为跟踪其自己的资源消耗的单个实体。 即使生成代理是自承载代理，它们也会以克隆和发送日志的形式生成负载。
我们在滑动 5 分钟窗口中为单个管道应用 200 个 TSTU 限制。 此限制与用户的全局消耗限制相同。 如果管道因速率限制而延迟或阻止，则会在附加的日志中显示一条消息。
API 客户端体验
延迟或阻止请求时，Azure DevOps 返回响应标头以帮助 API 客户端做出响应。 虽然未完全标准化，但这些标头 与其他常用服务大致一致。
下表列出了可用的标头及其含义。
X-RateLimit-Delay除了，所有这些标头在请求开始延迟之前都会发送。
此设计使客户有机会主动降低其请求速率。
标头名称
说明
Retry-After
发送 RFC 6585 指定的标头，告知发送下一个请求之前要等待多长时间才能低于检测阈值。 单位：秒。
X-RateLimit-Resource
一个自定义标头，指示已达到的服务和阈值类型。 阈值类型和服务名称可能会随时间而变化，且不会发出警告。 我们建议将此字符串显示给人类，但不依赖它进行计算。
X-RateLimit-Delay
请求延迟的时间。 单位：最多三个小数位数的秒数 (毫秒) 。
X-RateLimit-Limit
在实施延迟之前允许的 TSTU 总数。
X-RateLimit-Remaining
延迟之前剩余的 TSTU 数。 如果请求已被延迟或阻止，则为 0。
X-RateLimit-Reset
当所有资源消耗立即停止时，跟踪的使用情况将返回到 0 个 TTU。 以 Unix 纪元时间表示。
建议
建议至少响应 Retry-After 标头。 如果在任何响应中检测到 Retry-After 标头，请等到发送另一个请求之前经过该时间。 这样做有助于客户端应用程序体验更少的强制延迟。 请记住，响应为 200，因此无需将重试逻辑应用于请求。
如果可能，我们进一步建议监视 X-RateLimit-Remaining 和 X-RateLimit-Limit 标头。
这样做可以大致了解接近延迟阈值的速度。
客户端可以通过一段时间内分散其请求来智能地做出反应。