多房间并发处理：并发连接管理、房间锁机制、性能优化思路

说实话，多房间并发处理是信令服务器从「玩具」走向「生产环境」的关键一步。我记得自己第一次做线上会议系统时，单房间跑得好好的，一上线十几个房间同时开，服务器直接卡死。嗯，那场面挺尴尬的。

今天我们就来聊聊，怎么让信令服务器扛住多房间的并发压力。

并发连接管理：别让连接变成灾难

每个WebRTC房间，本质上是一组PeerConnection的集合。当房间数量从1变成100时，连接管理的复杂度不是线性增长，而是指数级爆炸。

我个人习惯把连接管理分成三层：

• 连接池层：维护所有WebSocket连接的生命周期
• 房间映射层：记录每个房间有哪些连接
• 用户状态层：跟踪每个用户的在线状态、媒体状态

来看一个简单的连接管理结构：

// 连接管理器
class ConnectionManager {
  constructor() {
    this.connections = new Map();   // connectionId -> WebSocket
    this.roomMap = new Map();       // roomId -> Set<connectionId>
    this.userMap = new Map();       // userId -> connectionId
  }

  addConnection(connId, ws) {
    this.connections.set(connId, ws);
  }

  joinRoom(connId, roomId, userId) {
    if (!this.roomMap.has(roomId)) {
      this.roomMap.set(roomId, new Set());
    }
    this.roomMap.get(roomId).add(connId);
    this.userMap.set(userId, connId);
  }

  leaveRoom(connId, roomId) {
    const room = this.roomMap.get(roomId);
    if (room) {
      room.delete(connId);
      if (room.size === 0) {
        this.roomMap.delete(roomId);  // 空房间自动清理
      }
    }
  }
}

房间锁机制：别让两个人同时当房主

多房间并发时，最头疼的问题是什么？竞态条件。

你想想看，两个用户同时加入同一个房间，同时发起offer，同时尝试修改房间状态。如果没有锁机制，房间状态就乱套了。

我曾经遇到过一个线上事故：两个用户同时申请成为房主，结果房间出现了两个房主，其他用户收到两份不同的offer，整个会议直接崩了。

从那以后，我设计了一套房间锁机制：

// 房间锁实现
class RoomLock {
  constructor() {
    this.locks = new Map();
    this.queue = new Map();
  }

  async acquire(roomId, timeout = 5000) {
    if (!this.locks.has(roomId)) {
      this.locks.set(roomId, false);
      this.queue.set(roomId, []);
    }

    if (!this.locks.get(roomId)) {
      this.locks.set(roomId, true);
      return true;
    }

    // 锁被占用，排队等待
    return new Promise((resolve) => {
      const timer = setTimeout(() => {
        this._dequeue(roomId);
        resolve(false);
      }, timeout);

      this.queue.get(roomId).push({ resolve, timer });
    });
  }

  release(roomId) {
    this._dequeue(roomId);
  }

  _dequeue(roomId) {
    const queue = this.queue.get(roomId);
    if (queue && queue.length > 0) {
      const next = queue.shift();
      clearTimeout(next.timer);
      next.resolve(true);
    } else {
      this.locks.set(roomId, false);
    }
  }
}

性能优化思路：从单机到集群

性能优化这件事，说白了就是「找瓶颈、拆瓶颈」。多房间并发场景下，常见的瓶颈有三个：

瓶颈类型	表现	优化方案
CPU	信令处理延迟高	异步处理、消息队列
内存	连接对象占用过多	连接池复用、对象池
网络IO	消息广播延迟大	批量发送、压缩

我个人比较推荐的做法是：

1. 消息队列化：所有信令消息先入队列，再异步处理。这样即使某个房间处理慢了，也不会影响其他房间。
2. 批量广播：不要一条一条发消息。攒够一批，或者每隔10ms发一次批量消息。我在项目中用这个优化，CPU占用直接降了40%。
3. 连接复用：同一个用户如果同时加入多个房间，复用同一个WebSocket连接。别给每个房间都建一个新连接。

架构图：多房间并发处理的核心逻辑

下面这张图展示了我常用的多房间并发处理架构：

这张图展示的是我常用的三层架构。客户端连接进来后，先经过连接管理器统一管理。连接管理器负责心跳、重连这些脏活累活。然后才是房间管理器，它负责房间锁、状态同步。最后所有消息都走消息队列，保证异步处理。

性能优化的几个实战技巧

最后分享几个我在项目中验证过的优化技巧：

• 使用对象池：频繁创建和销毁对象是性能杀手。我习惯预分配一批连接对象，用完了回收复用。
• 减少锁粒度：不要锁整个房间，只锁需要保护的关键操作。比如房主变更、房间销毁这些操作才需要锁。
• 定期清理：僵尸房间、过期连接要定期清理。我一般每5分钟跑一次清理任务。
• 监控先行：没有监控的优化都是盲人摸象。先加好连接数、消息延迟、锁等待时间的监控，再动手优化。

嗯，多房间并发处理这块内容不少，但核心就是这三件事：管好连接、用好锁、优化性能。把这三点做好，你的信令服务器就能扛住生产环境的压力了。