如何实现Azure Function互斥执行，避免超时导致误阻塞？

核心场景 #

两个独立Function App中的定时器函数：

• TimerFunctionOne：长耗时进程，每小时触发一次
• TimerFunctionTwo：短耗时进程，每分钟触发一次
  需求：TimerFunctionOne运行期间，阻止TimerFunctionTwo执行，同时避免因One崩溃导致的永久阻塞问题。

现有方案的痛点 #

用数据库标记启停的方式，无法处理One崩溃/超时后标记未更新的情况，会导致Two被永久阻塞。以下是几种更可靠的替代方案：

方案1：Azure Blob存储租约（推荐） #

利用Azure Blob的排他租约机制实现分布式锁：

• TimerFunctionOne启动时，针对指定Blob获取排他租约，租期设置为略长于One的预估最长执行时间（比如1小时30分钟）
• One执行期间，定期续租租约（比如每15分钟一次），确保租约不会在执行过程中过期
• One执行完成后主动释放租约；若One崩溃，租约到期后会自动释放
• TimerFunctionTwo每次运行前，尝试获取同一个Blob的租约：
  • 成功获取：说明One未在运行，正常执行
  • 获取失败：说明One仍在运行，直接退出

优势：

• 原生Azure服务，可靠性高，无需手动处理崩溃后的锁清理
• 实现简单，Azure SDK提供完整的租约操作API
• 无需额外维护数据库表结构

代码示例（C#）：

// TimerFunctionOne 租约操作
var blobClient = new BlobClient(connectionString, "lock-container", "function-lock");
await blobClient.CreateIfNotExistsAsync();

// 获取租约，租期90分钟
var leaseResponse = await blobClient.AcquireLeaseAsync(TimeSpan.FromMinutes(90));
var leaseId = leaseResponse.Value.LeaseId;

try
{
    // 启动后台任务定期续租（每15分钟）
    using var cts = new CancellationTokenSource();
    _ = Task.Run(async () =>
    {
        while (!cts.Token.IsCancellationRequested)
        {
            await Task.Delay(TimeSpan.FromMinutes(15), cts.Token);
            await blobClient.RenewLeaseAsync(new BlobLeaseClientOptions { LeaseId = leaseId });
        }
    }, cts.Token);

    // 执行核心业务逻辑
    await RunLongRunningProcess();
}
finally
{
    // 释放租约
    await blobClient.ReleaseLeaseAsync(new BlobLeaseClientOptions { LeaseId = leaseId });
}

// TimerFunctionTwo 检查租约
var blobClient = new BlobClient(connectionString, "lock-container", "function-lock");
try
{
    var leaseResponse = await blobClient.AcquireLeaseAsync(TimeSpan.FromMinutes(1));
    await blobClient.ReleaseLeaseAsync(new BlobLeaseClientOptions { LeaseId = leaseResponse.Value.LeaseId });
    // 获取租约成功，执行业务逻辑
    await RunShortProcess();
}
catch (RequestFailedException ex) when (ex.Status == 409)
{
    // 租约被占用，退出
    return;
}

方案2：Azure Redis分布式锁 #

借助Redis的键过期特性实现分布式锁：

• TimerFunctionOne启动时，在Redis中设置一个锁键（如function-one-running），并设置过期时间（比如1小时30分钟）
• One执行期间，定期刷新锁键的过期时间（比如每10分钟），防止执行过程中锁过期
• TimerFunctionTwo运行前，检查Redis中该锁键是否存在：
  • 不存在/已过期：说明One未在运行，正常执行
  • 存在：说明One仍在运行，直接退出

优势：

• Redis性能极高，锁检查操作延迟极低，适合高频触发的TimerFunctionTwo
• 过期时间自动清理崩溃后的锁，无需额外处理
• 支持更复杂的锁场景（如可重入锁）

方案3：优化时间戳方案 #

基于你原本的思路做针对性优化，降低误判概率：

• TimerFunctionOne每N秒更新一次数据库中的时间戳（比如10秒），执行完成后将标记设为已完成并重置时间戳
• TimerFunctionTwo检查时，若满足以下任一条件则允许执行：
  1. 标记为已完成
  2. 当前时间 - 最后更新时间 > 2*N秒（判定One已崩溃）

优势：

• 基于现有数据库实现，无需引入新服务
• 逻辑简单，开发成本低

注意：N的取值要平衡数据库写入频率和崩溃检测灵敏度，比如10秒更新一次，20秒无更新则判定崩溃，既不会频繁写库，也能较快检测到异常。

方案选择建议 #

• 若已使用Azure Blob存储：优先选Blob租约，原生集成，可靠性最高
• 对性能要求高或已有Redis集群：选Redis分布式锁，适合高频触发场景
• 不想引入新服务：优化时间戳方案，快速迭代实现

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