Question

我们正在高级计划上使用基于队列触发器的功能应用程序，其中消息包含一些详细信息，例如天蓝色的订阅名称。根据每个订阅的内容，我们会专门针对天蓝色的存储帐户（大约400至500）执行许多api调用。由于对存储帐户的“列表” api调用限制为100次调用/每分钟5分钟，因此在第101次调用时会收到429个响应错误。为了减轻这种情况，我们应用了指数重试逻辑（尝试使用我们自己的或polly库），该逻辑在一定时间延迟后调用。这适用于某些订阅，但对于许多尝试失败的地方，在第一次尝试后重试逻辑不尝试的情况下（我们以60秒的延迟保留了3次重试）。即使在通过实时指标监视功能应用程序时，我们也观察到有时某些功能实例的cpu使用率会变为零（尽管我们进行了某些操作，例如记录日志或在延迟操作中使用for循环，以便该功能可以运行），这会导致终止该特定的函数实例，然后将消息推回队列，并使用一个新的实例再次开始该过程。

请注意，由于许多订阅是并行处理的，因此功能应用程序会根据需要自动扩展。另外，由于我们使用高级计划，因此一个VM始终处于状态。所以杀死任何实例（对于任何特定的订阅调用大约400到500个存储api调用）是很奇怪的，因为在我们的延迟中，线程休眠时间仅为大约6、12、18（Time_delay）迭代的10秒。下面的延迟函数用于我们的重试逻辑代码。

private void Delay(int Time_delay, string requestUri, int retryCount)
{
   for (int i = 0; i < Time_delay; i++)
   {
       _logger.LogWarning($"Sleep initiated for id: {requestUri.ToString()}, RetryCount: {retryCount} CurrentTimeDelay: {Time_delay}");
        Thread.Sleep(10000);
        _logger.LogWarning($"Sleep completed for id: {requestUri.ToString()}, RetryCount: {retryCount} CurrentTimeDelay: {Time_delay}");
    }
}

注意**函数应用程序除了引发429错误响应的依赖关系外，不会引发任何其他异常。

Answer 1

您是否可以重新排队而不使用Thread.Sleep？重新排队时，您可以使用初始可见性延迟：

public class Function1
{
    [FunctionName(nameof(TryDoWork))]
    public static async Task TryDoWork(
        [QueueTrigger("some-queue")] SomeItem item,
        [Queue("some-queue")] CloudQueue queue)
    {
        var result = _SomeService.SomeWork(item);
            
        if (result == 429)
        {
            item.Retries++;
            var json = JsonConvert.SerializeObject(item);
            var message = new CloudQueueMessage(json);
            var delay = TimeSpan.FromSeconds(item.Retries);
            await queue.AddMessageAsync(message, null, delay, null, null);
        }
    }
}

可能是由于睡眠导致某些功能不正常的应用程序行为。我想我记得读过一些与Thread.Sleep的用法有关的问题，但我现在找不到。

此外，您可能希望添加对消息的某种处理，这些消息最终重试3次以上（或者您认为合理的多次尝试）。

基于队列触发的功能应用未完成

1 个答案: