Azure Service Bus队列消息接收异常：Node.js接收延迟及重启问题

这个问题我之前帮不少开发者排查过，核心原因大概率是你的Node.js接收端没有保持持续的长连接监听，或者SDK的空闲超时配置导致连接被自动断开后需要重新建立——刚好就是你看到的1分钟延迟窗口。下面是针对性的排查和解决步骤：

1. 检查接收代码的实现方式（最常见原因） #

如果你的代码是用单次调用receiveMessages来获取消息，比如像下面这种写法：

// 错误示例：单次接收，处理完后就停止监听
async function receiveOnce() {
  const receiver = sbClient.createReceiver(queueName);
  const messages = await receiver.receiveMessages(10, { maxWaitTimeInMs: 5000 });
  // 处理消息...
  await receiver.close();
}

这种写法只会一次性拉取现有消息，之后客户端会断开连接。当新消息进入队列时，客户端需要等待SDK的自动重连机制触发（默认约1分钟）才能再次拉取消息。

正确的做法：使用subscribe持续监听 #

新版@azure/service-bus SDK（v7+）推荐用subscribe方法建立持续的消息监听，它会保持长连接，新消息到达时立即推送：

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

const connectionString = "<你的Service Bus连接字符串>";
const queueName = "<你的队列名称>";

async function startContinuousReceiver() {
  const sbClient = new ServiceBusClient(connectionString);
  // 创建接收器（默认是PeekLock模式，推荐生产环境使用）
  const receiver = sbClient.createReceiver(queueName);

  // 订阅消息流，持续接收
  const subscription = receiver.subscribe({
    processMessage: async (message) => {
      console.log(`收到新消息: ${JSON.stringify(message.body)}`);
      // 处理完消息后确认完成（PeekLock模式必须调用）
      await message.complete();
    },
    processError: async (errorArgs) => {
      console.error(`接收出错: ${errorArgs.error.message}`, errorArgs);
      // 可以在这里处理错误，比如重试、死信队列等
    }
  });

  // 保持程序运行，监听中断信号以便优雅关闭
  process.on("SIGINT", async () => {
    console.log("正在停止接收...");
    await subscription.close();
    await sbClient.close();
    process.exit(0);
  });

  console.log("持续接收器已启动，等待消息...");
}

// 启动接收器
startContinuousReceiver().catch(err => {
  console.error("启动接收器失败:", err);
  process.exit(1);
});

2. 调整SDK的空闲超时配置 #

如果你的代码已经用了subscribe但还是有延迟，那可能是SDK默认的空闲超时设置导致连接被自动断开。新版SDK中，ServiceBusClient的connectionOptions里的idleTimeoutInMs默认是60000毫秒（1分钟）——当客户端1分钟内没收到消息，就会主动断开连接，之后新消息到来需要重新建立连接，这就产生了1分钟的延迟。

你可以在创建ServiceBusClient时把这个值调大，或者设为0（表示永不超时，注意资源占用）：

const sbClient = new ServiceBusClient(connectionString, {
  connectionOptions: {
    idleTimeoutInMs: 300000 // 设为5分钟，根据你的业务需求调整
  }
});

3. 确认SDK版本是否正确 #

如果你还在使用旧版的azure-service-bus（v1.x），它的API设计存在一些连接稳定性问题，建议直接升级到最新版的@azure/service-bus（v7+）：

# 卸载旧版
npm uninstall azure-service-bus
# 安装新版
npm install @azure/service-bus

新版SDK完全重写了底层连接逻辑，在持续监听场景下的稳定性和实时性要好得多。

4. 排查队列配置（次要检查项） #

虽然概率较低，但可以确认一下Service Bus队列的以下配置：

• Lock Duration：默认30秒，这个是消息的锁定时间，和接收延迟无关，但如果设置过长可能影响重试逻辑；
• Enable Partitioning：如果开启了分区，确保SDK版本支持分区队列（新版SDK默认支持）；
• Session Enabled：如果队列开启了会话，你的接收器必须指定会话ID才能接收消息，否则会收不到（但你的情况是重启能收到，所以这个可能性不大）。

按照上面的步骤调整后，应该就能解决后续消息延迟1分钟的问题了。

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