如何延迟Azure函数对Storage队列消息的拾取时间，规避MS Graph API 429错误？

针对你遇到的Azure Storage队列触发函数调用MS Graph API时的429限流问题，结合临时流量高峰的场景，提供以下可行方案：

1. 调整队列触发规则+单消息处理后延迟 #

默认情况下，队列触发函数会批量拉取最多32条消息并并发处理，极易触发Graph限流。你可以通过配置限制批量拉取数量为1，再在每条消息处理完成后添加30秒延迟，实现拾取消息的间隔控制：

修改host.json配置 #

{
  "version": "2.0",
  "extensions": {
    "queues": {
      "batchSize": 1,
      "maxDequeueCount": 5,
      "newBatchThreshold": 0
    }
  },
  "functionTimeout": "00:10:00"
}

• batchSize: 1：每次仅拉取1条消息
• newBatchThreshold: 0：当前消息处理完成后才会拉取下一条

函数内添加延迟（以C#为例） #

public static async Task Run([QueueTrigger("your-queue-name")] string myQueueItem, ILogger log)
{
    try
    {
        // 执行MS Graph API调用及业务逻辑
        await CallGraphApiAsync(myQueueItem);
    }
    catch (ServiceException ex) when (ex.StatusCode == HttpStatusCode.TooManyRequests)
    {
        // 优先使用Graph返回的Retry-After头确定等待时间，无则用30秒
        var retrySeconds = ex.ResponseHeaders.RetryAfter?.Delta?.TotalSeconds ?? 30;
        await Task.Delay(TimeSpan.FromSeconds(retrySeconds));
        // 可选：将消息重新入队等待后续处理
        await ReEnqueueMessageAsync(myQueueItem);
    }
    // 处理完成后延迟30秒再取下一条消息
    await Task.Delay(30000);
}

2. 利用队列消息可见性延迟替代函数内等待 #

如果担心函数内延迟导致超时，可在处理消息（或触发429时）将消息重新入队并设置可见性延迟，让队列30秒后才允许再次拾取该消息，函数处理完成后直接结束，彻底避免10分钟超时问题：

代码示例（C#，使用Azure.Storage.Queues SDK） #

public static async Task Run([QueueTrigger("your-queue-name")] QueueMessage message, QueueClient queueClient, ILogger log)
{
    try
    {
        // 执行MS Graph API调用及业务逻辑
        await CallGraphApiAsync(message.Body.ToString());
        // 处理成功，删除消息
        await queueClient.DeleteMessageAsync(message.MessageId, message.PopReceipt);
    }
    catch (ServiceException ex) when (ex.StatusCode == HttpStatusCode.TooManyRequests)
    {
        // 设置消息30秒后可见，重新入队
        await queueClient.UpdateMessageAsync(
            message.MessageId,
            message.PopReceipt,
            message.Body,
            TimeSpan.FromSeconds(30));
    }
}

3. 临时降低函数并发实例数 #

在Azure Portal进入你的Function App，找到配置 > 常规设置，将“最大实例数”调整为较小值（比如2-3），减少同时运行的函数实例数量，从而降低整体调用Graph API的频率。等临时流量高峰过去后再调回原有值。

4. 优先遵循MS Graph的Retry-After响应头 #

MS Graph返回的429响应中会包含Retry-After头，指示需要等待的秒数，建议优先使用这个值而非固定30秒，能更精准适配Graph的限流策略，减少不必要的等待。

内容的提问来源于stack exchange，提问作者AndreasTC