如何借助Azure Function实现作业创建24小时后的超时触发处理？

完全可以用Azure Function替代轮询数据库的定时任务，以下是两种最优实现方案，可根据你的应用架构选择：

方案一：Azure Durable Functions 延迟编排 #

Durable Functions原生支持延迟任务和流程状态管理，非常适合处理这种带超时的业务逻辑：

核心逻辑 #

1. 作业创建时，启动一个Durable Orchestrator函数，传入作业ID等关键信息。
2. Orchestrator同时启动两个任务：
   • 一个24小时后的延迟定时器（CreateTimer）
   • 监听用户处理作业的外部事件（WaitForExternalEvent）
3. 若用户在24小时内接受/拒绝作业，触发外部事件，取消定时器并终止Orchestrator。
4. 若超时未触发外部事件，执行记过逻辑（调用Activity函数更新数据库状态）。

代码示例 #

[FunctionName("JobTimeoutOrchestrator")]
public static async Task RunOrchestrator(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    var jobId = context.GetInput<string>();
    var timeoutTime = context.CurrentUtcDateTime.AddHours(24);
    
    using var timeoutCts = new CancellationTokenSource();
    var timeoutTask = context.CreateTimer(timeoutTime, timeoutCts.Token);
    var userActionTask = context.WaitForExternalEvent<string>("UserCompletedJob");

    var completedTask = await Task.WhenAny(timeoutTask, userActionTask);
    
    if (completedTask == userActionTask)
    {
        // 用户已处理作业，取消超时定时器
        timeoutCts.Cancel();
    }
    else
    {
        // 超时未处理，执行记过逻辑
        await context.CallActivityAsync("ApplyPenalty", jobId);
    }
}

[FunctionName("ApplyPenalty")]
public static async Task ApplyPenalty(
    [ActivityTrigger] string jobId, 
    ILogger log,
    [Sql("UPDATE Jobs SET Status = 'Penalized' WHERE Id = @JobId", CommandType.Text)] IAsyncCollector<MyJob> output)
{
    log.LogInformation($"Applying penalty for job {jobId} (24h timeout)");
    await output.AddAsync(new MyJob { Id = jobId, Status = "Penalized" });
}

优势 #

• 内置状态管理，无需额外存储跟踪超时任务
• 原生支持任务取消，逻辑清晰
• 支持更长时间的延迟（最长7天，满足24小时需求）

方案二：Azure Service Bus 计划消息 + Function #

如果你的应用更倾向于轻量的消息驱动架构，可使用Service Bus的计划消息特性结合Azure Function：

核心逻辑 #

1. 作业创建时，向Service Bus队列发送一条计划24小时后投递的消息，消息ID关联作业ID。
2. 用户接受/拒绝作业时，调用Service Bus API删除对应消息ID的未投递计划消息。
3. Azure Function以Service Bus队列为触发源，收到消息后先检查作业当前状态（避免消息重复投递），若未处理则执行记过逻辑。

代码示例 #

发送计划消息（作业创建时）

var serviceBusClient = new ServiceBusClient(Environment.GetEnvironmentVariable("ServiceBusConnection"));
var sender = serviceBusClient.CreateSender("job-timeout-queue");

var message = new ServiceBusMessage(jobId)
{
    MessageId = $"timeout-{jobId}",
    ScheduledEnqueueTimeUtc = DateTime.UtcNow.AddHours(24)
};

await sender.SendMessageAsync(message);

删除计划消息（用户处理作业时）

var receiver = serviceBusClient.CreateReceiver("job-timeout-queue");
await receiver.CancelScheduledMessageAsync($"timeout-{jobId}");

触发记过的Function

[FunctionName("ProcessJobTimeout")]
public static async Task Run(
    [ServiceBusTrigger("job-timeout-queue", Connection = "ServiceBusConnection")] string jobId,
    ILogger log,
    [Sql("SELECT Status FROM Jobs WHERE Id = @JobId", CommandType.Text)] string jobStatus)
{
    if (jobStatus != "Pending")
    {
        log.LogInformation($"Job {jobId} already processed, skipping penalty");
        return;
    }

    // 执行记过逻辑
    log.LogInformation($"Applying penalty for job {jobId}");
    // 更新数据库代码...
}

优势 #

• Service Bus计划消息是原生特性，可靠性高
• 无需维护复杂的编排流程，轻量易部署
• 天然支持消息重试和死信队列，容错性强

方案选择建议 #

• 若你的应用已经使用Durable Functions或需要复杂的流程编排（比如后续扩展多阶段超时逻辑），优先选Durable Functions方案。
• 若追求轻量、低耦合的消息驱动架构，优先选Service Bus + Function方案。

两种方案均能彻底替代轮询数据库的定时任务，大幅降低数据库查询负载，符合业务需求。

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