Microsoft Graph SDK中的默认重试处理程序是否在发送请求之前检查端点是否受限制？

问题描述

我了解Graph SDK实现了默认重试处理程序，该处理程序可以在发生429时进行重试。经过GitHub上的 RetryHandler.cs 类之后，我可以看到正在检查每个响应中是否存在429，并且如果有429（请求过多）响应，它将使用Retry-After标头（如果可用）或指数补偿来确定任务延迟的时间。

对于我的问题，请考虑以下情形：

1. 我有一个使用客户端凭证流的azure函数
2. 它可以由另一个应用程序（不是用户）触发
3. 我有一个图形服务客户端，它是一个静态对象并使用图形
4. 其中一个请求最终被限制（429）并且任务被延迟
5. 任务正在等待（被延迟）时，另一个使用相同图形资源的应用程序发出了请求

问题：Graph Service Client是否认为这是同一个静态对象，而其他任务正在延迟，是否会在不考虑端点受限制的情况下再次将请求发送给Graph？

谢谢

解决方法

每个请求都发送到图端点，而不管当前的未决限制请求或端点限制状态（它不维护任何状态）。 GraphClient本质上使用HttpClient，而RetryHandler只是http客户端委托处理程序（concept）。另外，关于静态对象的观点，当上一个请求等待重试时，它不会阻止新请求（这是异步任务调度很方便的地方）。实际上，HttpClient旨在实例化一次，并在应用程序的整个生命周期内重复使用。为每个请求实例化HttpClient类将耗尽繁重负载下可用的套接字数量。这将导致SocketException错误。

如果由于请求量非常大而导致服务开始节流（通过GraphAPI专为高容量而设计），则应考虑首先重新访问应用程序，原因是为什么从应用程序获得如此大量的Graph API调用。如果您有可能批量处理图形API的请求，也可以考虑利用它。查看Graph API https://docs.microsoft.com/en-us/graph/throttling的限制指南。即使在此之后，如果您想以自定义方式处理重试，也可以使用支持电路中断和隔板https://github.com/App-vNext/Polly

的Polly

希望能回答您的问题。如果您有后续问题，请告诉我。