Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Durable Functions предоставляет durable timers для использования в функциях оркестрации для реализации задержек или настройки тайм-аутов для асинхронных действий. Используйте устойчивые таймеры в функциях оркестратора вместо sleepdelay API, которые могут быть встроены в язык.
Пакеты SDK для устойчивых задач предоставляют устойчивые таймеры для использования в оркестрации для реализации задержек или настройки времени ожидания для асинхронных действий. Применяйте стойкие таймеры в оркестрациях вместо sleep или delay API, которые могут быть встроены в язык.
Это важно
В настоящее время пакет SDK для устойчивых задач PowerShell недоступен.
Устойчивые таймеры — это задачи, создаваемые с помощью соответствующего create timer API для выбранного языка, как показано в следующих примерах, и принимают время срабатывания или продолжительность в качестве аргумента.
// Put the orchestrator to sleep for 72 hours
DateTime dueTime = context.CurrentUtcDateTime.AddHours(72);
await context.CreateTimer(dueTime, CancellationToken.None);
// Put the orchestration to sleep for 72 hours
await context.CreateTimer(TimeSpan.FromHours(72), CancellationToken.None);
await При выполнении задачи таймера функция оркестратора спит до указанного времени окончания срока действия.
await При выполнении задачи таймера оркестрация спит до указанного времени окончания срока действия.
Замечание
Оркестрации продолжают обрабатывать другие входящие события, ожидая истечения срока действия задачи таймера.
Ограничения таймера
При создании таймера, истекающего в 4:30 вечера UTC, базовая платформа устойчивых задач включает сообщение, которое становится видимым только в 4:30 вечера UTC. Если приложение-функция масштабируется до нуля экземпляров в то же время, новое видимое сообщение таймера гарантирует, что приложение-функция активируется снова на соответствующей виртуальной машине.
Замечание
- Для приложений JavaScript, Python и PowerShell устойчивые таймеры ограничены шестью днями. Чтобы обойти это ограничение, используйте API таймера в цикле
whileдля имитации длительной задержки. Актуальные приложения .NET и Java поддерживают произвольные таймеры. - В зависимости от используемой версии пакета SDK и поставщика хранилища долговременные таймеры в течение шести дней или более могут быть реализованы с помощью ряда более коротких таймеров (например, трехдневных периодов), пока не будет достигнуто требуемое время истечения срока действия. Это поведение наблюдается в базовом хранилище данных, но не влияет на поведение оркестрации.
- Не используйте встроенные API даты и времени для получения текущего времени. При вычислении будущей даты истечения срока действия таймера всегда используйте API текущего времени функции оркестратора. Дополнительные сведения см. в статье об ограничениях кода функции оркестратора.
При создании таймера, истекающего в 4:30 вечера UTC, базовая платформа устойчивых задач включает сообщение, которое становится видимым только в 4:30 вечера UTC. Сообщение таймера гарантирует, что работник активируется снова после истечения срока действия таймера.
Замечание
- Указание длительной задержки (например, задержка в течение нескольких дней или более) может привести к созданию нескольких внутренних управляемых устойчивых таймеров. Код оркестрации не должен знать об этом поведении. Однако он может отображаться в журналах фреймворка и сохраненном состоянии истории.
- Не используйте встроенные API даты и времени для получения текущего времени. При вычислении будущей даты истечения срока действия таймера всегда используйте текущее свойство контекста оркестрации (например,
context.CurrentUtcDateTimeв .NET,ctx.current_utc_datetimeв Python илиctx.currentUtcDateTimeв JavaScript).
Применение задержек
В следующем примере показано, как использовать устойчивые таймеры для задержки выполнения. Пример выдает уведомление о выставлении счетов каждый день в течение 10 дней.
[FunctionName("BillingIssuer")]
public static async Task Run(
[OrchestrationTrigger] IDurableOrchestrationContext context)
{
for (int i = 0; i < 10; i++)
{
DateTime deadline = context.CurrentUtcDateTime.Add(TimeSpan.FromDays(1));
await context.CreateTimer(deadline, CancellationToken.None);
await context.CallActivityAsync("SendBillingEvent");
}
}
Замечание
Предыдущий пример C# предназначен для Durable Functions 2.x. Для Durable Functions 1.x используйте DurableOrchestrationContext вместо IDurableOrchestrationContext. Дополнительные сведения о различиях между версиями см. в статье о версиях устойчивых функций .
public class BillingIssuer : TaskOrchestrator<object?, string>
{
public override async Task<string> RunAsync(TaskOrchestrationContext context, object? input)
{
for (int i = 0; i < 10; i++)
{
await context.CreateTimer(TimeSpan.FromDays(1), CancellationToken.None);
await context.CallActivityAsync("SendBillingEvent");
}
return "done";
}
}
Предупреждение
Избегайте бесконечных циклов в функциях оркестратора. Сведения о том, как безопасно и эффективно реализовать бесконечные сценарии цикла, см. в разделе "Вечные оркестрации".
Предупреждение
Избегайте бесконечных циклов в оркестрации. Сведения о том, как безопасно и эффективно реализовать бесконечные сценарии цикла, см. в разделе "Вечные оркестрации".
Использование времени ожидания
В этом примере показано, как использовать устойчивые таймеры для организации тайм-аутов.
[FunctionName("TryGetQuote")]
public static async Task<bool> Run(
[OrchestrationTrigger] IDurableOrchestrationContext context)
{
TimeSpan timeout = TimeSpan.FromSeconds(30);
DateTime deadline = context.CurrentUtcDateTime.Add(timeout);
using (var cts = new CancellationTokenSource())
{
Task activityTask = context.CallActivityAsync("GetQuote");
Task timeoutTask = context.CreateTimer(deadline, cts.Token);
Task winner = await Task.WhenAny(activityTask, timeoutTask);
if (winner == activityTask)
{
// success case
cts.Cancel();
return true;
}
else
{
// timeout case
return false;
}
}
}
Замечание
Предыдущий пример C# предназначен для Durable Functions 2.x. Для Durable Functions 1.x используйте DurableOrchestrationContext вместо IDurableOrchestrationContext. Дополнительные сведения о различиях между версиями см. в статье о версиях устойчивых функций .
public class TryGetQuote : TaskOrchestrator<object?, bool>
{
public override async Task<bool> RunAsync(TaskOrchestrationContext context, object? input)
{
using var cts = new CancellationTokenSource();
Task<double> activityTask = context.CallActivityAsync<double>("GetQuote");
Task timeoutTask = context.CreateTimer(TimeSpan.FromSeconds(30), cts.Token);
Task winner = await Task.WhenAny(activityTask, timeoutTask);
if (winner == activityTask)
{
// success case
cts.Cancel();
return true;
}
else
{
// timeout case
return false;
}
}
}
Предупреждение
В .NET, JavaScript, Python и PowerShell отменяйте все созданные устойчивые таймеры, если ваш код не ожидает их завершения. См. предыдущие примеры, чтобы узнать, как отменить ожидающие таймеры. Платформа устойчивых задач не изменяет состояние оркестрации на "Завершено" до тех пор, пока не будут выполнены все невыполненные задачи, включая устойчивые задачи таймера, либо завершены, либо отменены.
Предупреждение
Если ваш SDK поддерживает отмену таймера (например, .NET), отмените любые созданные долговременные таймеры, если ваш код не ожидает их завершения. См. предыдущие примеры, чтобы узнать, как отменить ожидающие таймеры. Платформа устойчивых задач не изменяет состояние оркестрации на "Завершено" до тех пор, пока не будут выполнены все невыполненные задачи, включая устойчивые задачи таймера, либо завершены, либо отменены.
Этот механизм отмены, использующий шаблон when-any, не завершает выполнение функций активности или выполнения подоркестраций, которые находятся в процессе выполнения. Скорее, это позволяет функции оркестратора игнорировать результат и двигаться дальше. Если ваше приложение-функция использует план потребления, вам по-прежнему выставляется плата за любое время и память, которые использует брошенная функция активности. По умолчанию функции, работающие в плане потребления, имеют время ожидания в течение пяти минут. Если это ограничение превышено, хост Azure Functions перезагружается, чтобы остановить все выполнение и предотвратить неконтролируемую ситуацию выставления счетов. Время ожидания функции настраивается.
Более подробный пример реализации времени ожидания в функциях оркестратора см. в статье о взаимодействии с человеком .
Этот механизм отмены, использующий шаблон when-any, не завершает выполнение текущих активностей или исполнения под-оркестраций. Скорее, это просто позволяет оркестрации игнорировать результат и двигаться дальше.