Azure Service Bus消息锁超时重复处理的消息完成机制咨询

观测到的日志断流是Azure Service Bus PeekLock模式下的标准表现，不存在未公开的隐式逻辑：

• 节点通过PeekLock模式获取消息时，拿到的仅为配置时长内的临时独占访问权，并非消息的永久所有权。队列配置的最大锁时长为5分钟时，第一个进程拿到消息后如果没有主动续期，5分钟后锁自动失效，其他节点可以正常获取同一条消息的新锁并启动处理，这就是7分钟左右第二个进程启动的根因——此时第一个进程已经处于无有效锁的处理状态。
• 当任意持有该消息有效/过期锁令牌的节点调用complete()方法时，只要服务端校验到该消息仍存在于队列中（未被其他节点标记为完成、死信或转移），就会直接将消息从队列永久移除，不会额外校验发起请求的节点是否持有当前有效的锁。
• 消息被移除后，其余正在处理该消息的节点不会收到服务端主动推送的中断信号，节点进程本身不会崩溃，但后续所有和该消息绑定的服务端操作（包括自动锁续期、手动调用complete/abandon/deadletter等）都会收到服务端返回的MessageNotFound错误。观测到第二个进程日志直接中断，本质是Node.js SDK默认不会在业务日志中打印后台任务抛出的这类错误，如果没有手动注册错误回调，异常会被直接吞掉，表现为日志毫无征兆地中断，实际上第二个进程的业务逻辑可能还在运行，只是最终处理完提交结果时才会触发报错。

不要手动实现定时续期逻辑，官方SDK已经内置了生产可用的自动续期能力，手动写逻辑很容易出现续期超时、定时器泄漏、续期时机偏差导致锁提前失效的问题：

• 请使用官方维护的正式版SDK包@azure/service-bus（版本≥7.0.0，旧版azure-sb包已停止维护，不要使用），该SDK原生支持自动锁续期，不需要额外编写续期逻辑。
• 配置时只需在初始化接收器、注册消息处理回调时，传入maxAutoLockRenewalDurationInMs参数，将值设置为比单条消息最大处理时长多20%~50%的冗余即可，比如单条消息平均处理时长15分钟的场景，可设置为20分钟（即1200000毫秒），SDK会在每次锁到期前自动在后台发起续期请求，不需要业务代码干预。
• 最小可用代码示例：

const { ServiceBusClient } = require("@azure/service-bus");

// 初始化客户端
const sbClient = new ServiceBusClient("<你的Service Bus连接字符串>");
// 创建队列接收器
const receiver = sbClient.createReceiver("<你的队列名称>", {
  receiveMode: "peekLock",
  // 配置自动锁续期最长时长，覆盖业务处理耗时
  maxAutoLockRenewalDurationInMs: 20 * 60 * 1000,
});

// 注册消息处理监听
receiver.subscribe({
  // 消息处理逻辑
  processMessage: async (message) => {
    // 直接执行业务长耗时任务即可，SDK自动维护锁续期
    await your15MinuteLongBusinessTask(message);
    // 处理完成后提交结果，SDK会自动清理该消息对应的续期定时器
    await receiver.completeMessage(message);
  },
  // 全局错误回调，必须实现
  processError: async (errorInfo) => {
    // 所有SDK后台异常（包括锁续期失败、消息已被删除的NotFound错误）都会进入这里
    console.error("Service Bus消息处理异常", errorInfo);
  }
});

• 配置注意事项：
  • 不要将maxAutoLockRenewalDurationInMs设置为无限大，建议按业务峰值处理时长的1.5倍配置上限，避免业务逻辑死锁导致锁被无限续期、消息无法被其他节点重新消费。
  • 必须实现processError回调，之前观测到的第二个进程日志断流问题，就是因为没有实现该回调，SDK后台抛出的消息不存在、续期失败等错误被默认吞掉，没有任何日志输出。
  • 即使配置了自动锁续期，业务逻辑仍然需要做幂等校验，极端场景下（比如网络分区、服务端闪断）仍可能出现多节点同时处理同一条消息的情况，不要依赖锁机制实现消息仅被处理一次的语义。

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