Azure WebApp中Node.js应用WebSocket重复订阅问题求解

方案1：基于分布式锁实现单实例订阅 #

借助Azure Redis Cache实现分布式锁，确保同一时间只有一个实例持有WebSocket订阅权限：

• 实例启动时，尝试向Redis申请一个带过期时间的锁（例如websocket-sub-lock），过期时间需长于WebSocket的心跳间隔
• 成功获取锁的实例初始化reconnecting-websockets连接并处理消息，同时定时刷新锁有效期，防止正常运行时锁过期
• 未获取到锁的实例定时重试抢锁，当持有锁的实例下线或锁过期时，其他实例会自动竞争补位，保证始终只有一个有效订阅
• Node.js实现示例（依赖ioredis库）：

const Redis = require('ioredis');
const redis = new Redis(process.env.REDIS_CONN_STR);

async function tryAcquireLock() {
  const lockKey = 'websocket-sub-lock';
  const lockTTL = 30; // 锁有效期30秒
  const lockResult = await redis.set(lockKey, Date.now().toString(), 'NX', 'EX', lockTTL);
  
  if (lockResult === 'OK') {
    // 初始化WebSocket连接
    initWebSocketConnection();
    // 每25秒刷新锁有效期
    setInterval(() => redis.expire(lockKey, lockTTL), 25000);
  } else {
    // 5秒后重试抢锁
    setTimeout(tryAcquireLock, 5000);
  }
}

function initWebSocketConnection() {
  // 你的reconnecting-websockets初始化逻辑
}

// 启动时执行抢锁逻辑
tryAcquireLock();

方案2：拆分订阅与业务处理实例 #

利用Azure WebApp部署槽分离订阅和业务处理：

• 创建一个仅部署1个实例的专用槽（例如subscription-slot），负责与外部服务建立WebSocket订阅
• 订阅槽将接收到的消息转发至Azure Service Bus Queue或Event Hub
• 主槽的多实例从Service Bus Queue竞争消费消息，借助Service Bus的竞争机制，每条消息只会被一个实例处理
• 此方案既避免重复订阅，又能利用多实例提升业务处理能力

方案3：外部服务端唯一订阅（需服务支持） #

如果外部WebSocket服务支持客户端标识或分组订阅：

• 用Azure WebApp内置的WEBSITE_INSTANCE_ID环境变量作为实例唯一标识
• 订阅时将该标识发送给外部服务，要求服务仅向一个活跃实例推送消息；或使用分组订阅功能，同一分组内仅推送至一个实例

方案4：消息幂等处理（兜底方案） #

若以上方案暂无法落地，先解决重复处理问题：

• 为每条外部消息分配唯一ID，处理前先校验该ID是否已被处理
• 用Redis记录已处理的消息ID（设置合理过期时间），或给数据库的消息ID字段添加唯一约束，避免重复更新
• 示例逻辑：

async function processMessage(message) {
  const msgId = message.uniqueId;
  // 检查是否已处理过该消息
  const isProcessed = await redis.get(`processed:${msgId}`);
  if (isProcessed) return;

  // 执行数据库更新等业务逻辑
  await updateDatabase(message);
  
  // 标记消息已处理，有效期1天
  await redis.set(`processed:${msgId}`, '1', 'EX', 86400);
}

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