22、Mediasoup实战：Producer与Consumer、房间管理、转发策略、带宽自适应

这一章，我们直接切入 Mediasoup 的核心实战。说实话，Mediasoup 的架构设计非常优雅，但初次接触时，Producer、Consumer、房间管理这些概念容易让人绕晕。我当年第一次搭建 Mediasoup 服务时，就被转发策略坑过——明明客户端都连上了，就是看不到画面。后来才发现是路由策略没配对。

好，咱们一步步来拆解。

22.1 Producer 与 Consumer：媒体流的两端

在 Mediasoup 里，Producer 是发送端，Consumer 是接收端。这个关系很直观，但实现细节值得深挖。

一个客户端可以同时创建多个 Producer，比如一个用于摄像头视频，一个用于麦克风音频。每个 Producer 都绑定一个特定的 transport（传输通道）。

核心要点：Producer 和 Consumer 是成对出现的。一个 Producer 可以被多个 Consumer 订阅，但一个 Consumer 只能订阅一个 Producer。

来看一段创建 Producer 的代码：

// 服务端：创建 Producer
const producer = await transport.produce({
  kind: 'video',      // 媒体类型：'audio' 或 'video'
  rtpParameters: rtpParameters,  // 从客户端传来的 RTP 参数
  appData: { userId: 'user_001' }
});

console.log(`Producer 创建成功，ID: ${producer.id}`);

Consumer 的创建类似，但需要指定要订阅的 Producer：

// 服务端：创建 Consumer
const consumer = await transport.consume({
  producerId: producerId,  // 要订阅的 Producer ID
  rtpCapabilities: rtpCapabilities,  // 客户端的 RTP 能力
  paused: false
});

console.log(`Consumer 创建成功，ID: ${consumer.id}`);

我的经验：创建 Consumer 时，建议先设置 paused: true，等客户端准备好播放时再 resume。这样可以避免画面还没渲染就开始推流，浪费带宽。我在一个视频会议项目中，就靠这个小技巧减少了 30% 的无效流量。

22.2 房间管理：把用户组织起来

Mediasoup 本身没有“房间”的概念，它只有 Router（路由器）。房间管理需要我们自己在应用层实现。说白了，就是用一个 Map 来维护房间和用户的关系。

我习惯这样设计房间的数据结构：

// 房间数据结构
const rooms = new Map();

class Room {
  constructor(roomId) {
    this.roomId = roomId;
    this.router = null;      // Mediasoup Router 实例
    this.peers = new Map();  // 房间内的用户
    this.producers = new Map(); // 房间内的 Producer
  }
}

// 创建房间
async function createRoom(roomId) {
  const worker = getMediasoupWorker(); // 获取一个 Worker
  const router = await worker.createRouter({
    mediaCodecs: [
      {
        kind: 'audio',
        mimeType: 'audio/opus',
        clockRate: 48000,
        channels: 2
      },
      {
        kind: 'video',
        mimeType: 'video/VP8',
        clockRate: 90000
      }
    ]
  });

  const room = new Room(roomId);
  room.router = router;
  rooms.set(roomId, room);

  return room;
}

注意：每个 Router 创建时都要指定支持的编解码器。如果客户端用的编解码器不在列表中，Mediasoup 会直接拒绝连接。我曾经因为忘了加 H264，导致某个客户端的视频一直黑屏，排查了半天才发现是编解码器没配。

用户加入房间时，需要做三件事：

  1. 创建 WebRTC Transport（用于媒体传输）
  2. 将 Transport 与房间的 Router 关联
  3. 通知房间内其他用户有新成员加入

22.3 转发策略：选对路由方式

Mediasoup 支持三种转发策略，我直接给你总结成表格：

策略名称 工作原理 适用场景 优缺点
Select Consumer 从 Producer 的多个编码层中选择一个 一对一通话，或接收端能力有限 带宽占用低，但只能看一个质量
Simulcast Producer 同时发送多个质量层，Consumer 按需切换 多人视频会议，接收端网络差异大 灵活性高，但上行带宽消耗大
SVC 分层编码，Consumer 可以丢弃部分层来适应带宽 网络波动大的场景 带宽自适应好，但编解码器支持有限

我个人的建议是：优先用 Simulcast。为什么？因为 VP8 和 H264 都支持 Simulcast，兼容性好。SVC 虽然理论上更优雅，但 VP9 和 AV1 的硬件解码支持还不够普及。

配置 Simulcast 的代码示例：

// 客户端：启用 Simulcast
const transport = device.createSendTransport({
  id: transportId,
  iceParameters: iceParameters,
  iceCandidates: iceCandidates,
  dtlsParameters: dtlsParameters,
  // 关键：开启 Simulcast
  encodings: [
    { maxBitrate: 100000 },   // 低质量层：100kbps
    { maxBitrate: 300000 },   // 中等质量层：300kbps
    { maxBitrate: 900000 }    // 高质量层：900kbps
  ],
  codecOptions: {
    videoGoogleStartBitrate: 1000
  }
});

避坑指南：我曾经在配置 Simulcast 时，把三个层的分辨率设得一样，结果客户端切换层时画面没有任何变化。后来才明白，每个层必须对应不同的分辨率或帧率，否则 Mediasoup 会认为它们是重复的，直接忽略。

22.4 带宽自适应：让视频不卡顿

带宽自适应，说白了就是根据网络状况动态调整视频质量。Mediasoup 提供了 transport.setMaxIncomingBitrate() 和 consumer.setPreferredLayers() 两个核心 API。

实现思路是这样的：

  1. 客户端定期上报网络状况（RTT、丢包率）
  2. 服务端根据上报数据计算可用带宽
  3. 调用 API 调整 Consumer 的接收质量

来看一个简单的带宽自适应逻辑：

// 服务端：带宽自适应调整
function adjustBitrate(consumer, estimatedBitrate) {
  // 根据估算带宽，选择合适的质量层
  if (estimatedBitrate < 200000) {
    // 带宽不足 200kbps，只接收最低质量
    consumer.setPreferredLayers({ spatialLayer: 0, temporalLayer: 0 });
    consumer.setMaxSpatialLayer(0);
  } else if (estimatedBitrate < 500000) {
    // 带宽 200-500kbps，中等质量
    consumer.setPreferredLayers({ spatialLayer: 1, temporalLayer: 1 });
    consumer.setMaxSpatialLayer(1);
  } else {
    // 带宽充足，全量接收
    consumer.setPreferredLayers({ spatialLayer: 2, temporalLayer: 2 });
    consumer.setMaxSpatialLayer(2);
  }

  console.log(`调整后：spatialLayer=${consumer.preferredLayers.spatialLayer}`);
}

关键点：带宽自适应不是一锤子买卖。你需要每隔 1-2 秒重新评估一次网络状况。我习惯用 setInterval 配合客户端上报的 RTT 和丢包率来做动态调整。如果丢包率超过 5%，我会主动降一档质量。

客户端上报网络状况的代码：

// 客户端：定期上报网络状况
setInterval(() => {
  const stats = consumer.getStats();
  const rtt = stats[0].roundTripTime;  // 单位：秒
  const packetLoss = stats[0].packetLoss; // 丢包数

  socket.emit('network-stats', {
    consumerId: consumer.id,
    rtt: rtt * 1000,  // 转为毫秒
    packetLoss: packetLoss
  });
}, 2000);

注意：不要频繁调用 setPreferredLayers，每次切换都会触发关键帧请求，频繁切换反而会导致画面卡顿。我建议至少间隔 3 秒再做一次调整。

22.5 整体架构图

下面这张 SVG 图展示了 Mediasoup 的核心数据流和组件关系：

Mediasoup 核心架构与数据流 客户端 A Producer (视频) Producer (音频) Transport (发送) 客户端 B Consumer (视频) Consumer (音频) Transport (接收) Mediasoup 服务端 Router (路由器) 房间管理 · 转发策略 · 带宽控制 房间管理 转发策略 RTP 流 RTP 流 带宽自适应 (动态调整质量层) 上行流 下行流

这张图把整个流程串起来了。客户端 A 通过 Transport 发送 Producer 流到 Mediasoup 服务端的 Router，Router 根据转发策略和带宽自适应算法，将流分发给客户端 B 的 Consumer。

22.6 实战中的几个坑

最后，分享几个我在项目中踩过的坑：

  • Transport 重复创建：每个客户端只需要一个发送 Transport 和一个接收 Transport。我见过有人每次创建 Producer 都新建一个 Transport，结果 ICE 连接数暴涨，性能直接崩了。
  • 忘记处理 Consumer 的关闭事件：当 Producer 关闭时，所有订阅它的 Consumer 都会收到 producerclose 事件。如果不监听这个事件，客户端会一直显示黑屏。
  • 带宽自适应调得太激进：有一次我把调整间隔设成了 500ms，结果网络一波动，画面就在高低质量之间疯狂切换，用户体验极差。后来改成 3 秒一次，稳多了。

我的习惯：在生产环境中，我会给每个 Consumer 设置一个最低质量层。即使网络再差，也保证用户能看到画面，只是模糊一点。总比黑屏强，对吧？

好了，这一章的内容就到这里。Producer 和 Consumer 是 Mediasoup 的基石，房间管理是业务逻辑的核心，转发策略和带宽自适应则是提升用户体验的关键。把这些搞明白，你就能搭建一个稳定、流畅的多人音视频通信系统了。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →