Table of contents

限制指南 | Graph API 概念Throttling guidance | Graph API concepts

Pat Altimore|上次更新日期: 2018/6/19
2 参与人员

强烈建议使用 Microsoft Graph 代替 Azure AD Graph API 来访问 Azure Active Directory 资源。We strongly recommend that you use Microsoft Graph instead of Azure AD Graph API to access Azure Active Directory resources.现在我们的开发工作将重点集中在 Microsoft Graph 上,没有计划对 Azure AD Graph API 进行进一步的改进。Our development efforts are now concentrated on Microsoft Graph and no further enhancements are planned for Azure AD Graph API.Azure AD Graph API 仍适用的方案数量非常有限;有关详细信息,请参阅 Office 开发人员中心中的博客文章 Microsoft Graph 或 Azure AD GraphThere are a very limited number of scenarios for which Azure AD Graph API might still be appropriate; for more information, see the Microsoft Graph or the Azure AD Graph blog post in the Office Dev Center.

什么是限制?What is throttling?

限制可限制对服务的并发调用数,防止过度使用资源。Throttling limits the number of concurrent calls to a service to prevent overuse of resources.Azure Active Directory (AD) Graph 旨在处理量很大的请求。Azure Active Directory (AD) Graph is designed to handle a very high volume of requests.在请求过多的情况下,限制有助于维持 Azure AD Graph 服务的最佳性能和可靠性。In the event of an overwhelming number of requests, throttling helps maintain optimal performance and reliability of the Azure AD Graph service.

限制因具体情况而异。Throttling limits vary based on the scenario.例如,如果要向租户执行大量写入,则这种情况下限制的可能性要大于只执行读取的情况。For example, if you are performing a large volume of writes to your tenant, the possibility for throttling is higher than if you are only performing reads.

发生限制时,会出现什么情况?What happens when throttling occurs?

超出限制阈值时,限制生效的同时,Azure AD Graph 会限制任何来自该客户端的进一步请求。When a throttling threshold is exceeded, Azure AD Graph limits any further requests from that client while the throttle is in effect.发生限制时,Azure AD Graph 会返回 HTTP 状态代码 429(“请求过多”),请求会失败。When throttled, Azure AD Graph returns HTTP status code 429 ("Too many requests"), and the requests fail.限制行为可取决于请求的类型和数目。Throttling behavior can be dependent on the type and number of requests.例如,如果请求量很大,将限制所有请求类型。For example, if you have a very high volume of requests, all requests types are throttled.限制因请求类型而异。Threshold limits vary based on the request type.因此,可能会遇到限制写入但仍允许读取的情况。Therefore, you could encounter a scenario where writes are throttled but reads are still permitted.

常见限制方案Common throttling scenarios

客户端限制的最常见原因包括:The most common causes of throttling of clients include:

  • 某租户的所有应用程序中存在大量请求。A large number of requests across all applications in a tenant.
  • 所有租户存在来自某特定应用程序的大量请求。A large number of requests from a particular application across all tenants.

处理限制的最佳做法Best practices to handle throttling

  • 减少每个请求的操作数量。Reduce the number of operations per request.
  • 减少调用频率。Reduce the frequency of calls.
  • 请求失败并收到 HTTP 错误代码 429 时,待经过“稍后重试”响应标头字段中指定的秒数后重试请求。When requests fail with a HTTP error code 429, wait the number of seconds specified in the Retry-After response header field and retry the request.

实现错误处理时,使用 HTTP 错误代码 429 检测限制。When implementing error handling, use the HTTP error code 429 to detect throttling.失败的响应将在响应标头中包括“稍后重试”字段。The failed response will include the Retry-After field in the response header.

  1. 等待“稍后重试”字段内指定的秒数。Wait the number of seconds specified in the Retry-After field.
  2. 重试请求。Retry the request.
  3. 如果请求再次失败且出现 429 错误代码,则仍处于限制状态,请继续使用建议的“稍后重试”延迟,然后重试请求,直到成功为止。If the request fails again with a 429 error code, you are still being throttled, continue to use the recommended Retry-After delay and retry the request until it succeeds.

使用“稍后重试”延迟缓和请求数是从限制恢复的最快方法,因为限制某客户端时,AAD Graph 会持续记录资源使用情况。Backing off requests using the Retry-After delay is the fastest way to recover from throttling because AAD Graph continues to log resource usage while a client is being throttled.由于待响应的请求总数会因使用限制而累积激增,因此应避免立即重试。You should avoid immediate retries since all requests accrue against your usage limits.

有关 Microsoft 云上限制的更多信息,请参阅限制模式For a broader discussion of throttling on the Microsoft Cloud, see Throttling Pattern.

© 2018 Microsoft