集群架构

Monibuca V6 集群方案基于 Origin-Edge 模型设计，节点间通过 QUIC 协议实现低延迟高可靠通信，支持自动节点发现、流智能转发和负载均衡。

架构总览

                     ┌──────────────┐
                     │   DNS/LB     │  ← 用户入口
                     └──────┬───────┘
                            │
            ┌───────────────┼───────────────┐
            │               │               │
     ┌──────▼─────┐  ┌─────▼──────┐  ┌─────▼──────┐
     │  Edge-BJ   │  │  Edge-SH   │  │  Edge-GZ   │
     │ (北京边缘)  │  │ (上海边缘)  │  │ (广州边缘)  │
     └──────┬─────┘  └─────┬──────┘  └─────┬──────┘
            │               │               │
            │          QUIC Relay           │
            │               │               │
     ┌──────▼───────────────▼───────────────▼──────┐
     │                Origin Cluster                │
     │  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
     │  │ Origin-1 │  │ Origin-2 │  │ Origin-3 │  │
     │  └──────────┘  └──────────┘  └──────────┘  │
     └─────────────────────────────────────────────┘

角色定义

角色	职责
Origin	接收推流端的直接推流，是流的源头。提供流数据给 Edge 节点
Edge	接收观众端的拉流请求。本地无流时自动从 Origin 回源

角色非固定

每个 Monibuca 节点既可以是 Origin 又可以是 Edge，角色由流的实际发布位置决定。同一节点对于 A 流是 Origin（本地推流），对于 B 流可能是 Edge（需要回源）。

QUIC 通信

集群节点间使用 QUIC 协议通信，利用其特性优势：

为什么选择 QUIC

特性	TCP	QUIC
连接建立	1-3 RTT（含 TLS）	0-1 RTT
队头阻塞	整个连接阻塞	仅单个流阻塞
多路复用	需要 HTTP/2	原生支持
连接迁移	不支持	支持（IP 变更不断连）
拥塞控制	全连接共享	每流独立

通信层次

┌─────────────────────────────┐
│     Application Layer       │
│  (gRPC: 节点同步/流控制)      │
├─────────────────────────────┤
│     Relay Layer             │
│  (音视频数据传输)              │
├─────────────────────────────┤
│     QUIC Transport          │
│  (quinn: 连接管理)           │
├─────────────────────────────┤
│     TLS 1.3                 │
│  (自签名证书/自动证书管理)     │
└─────────────────────────────┘

• gRPC 层：节点发现、心跳检测、流会话注册、Catalog 同步
• Relay 层：音视频帧数据的高速传输，直接在 QUIC 流上传输
• 传输层：基于 quinn 库实现的 QUIC 连接管理，自动证书生成

节点发现与健康检查

种子节点发现

新节点启动时连接配置中的种子节点（seed_servers），获取集群拓扑信息：

新节点 → 种子节点: "我是 edge-3，请告诉我集群中有谁"
种子节点 → 新节点: [origin-1, edge-1, edge-2, ...]
新节点 → 各节点: 建立 QUIC 连接

心跳机制

┌────────┐  heartbeat (每5秒)  ┌────────┐
│ Node A │ ──────────────────► │ Node B │
│        │ ◄────────────────── │        │
│        │  heartbeat_ack      │        │
└────────┘                     └────────┘

每次心跳携带节点摘要信息：

• CPU 使用率
• 内存使用率
• 带宽使用
• 当前流数量
• 订阅者数量

故障检测

基于心跳超时进行三级故障检测：

状态	条件	行为
Healthy	心跳正常	正常参与集群
Suspect	连续 suspect_threshold 次未响应	标记可疑，降低权重
Offline	连续 offline_threshold 次未响应	标记离线，清理会话

节点被标记为 Offline 后触发：

1. SessionRegistry 清除该节点的所有流注册信息
2. RelayManager 断开该节点的所有 Relay 连接
3. AllocationManager 不再将请求分配到该节点

流转发（Relay）

回源流程

观众 → Edge: 请求 live/camera01
Edge: 本地没有此流，查询 SessionRegistry
SessionRegistry → Edge: 该流在 Origin-1
Edge → Origin-1: 建立 QUIC Relay 连接
Origin-1 → Edge: 通过 QUIC 传输音视频数据
Edge → 观众: 分发到本地订阅者

Relay 生命周期

1. 建立：Edge 检测到本地无流，通过 QUIC 向 Origin 发起 Relay 请求
2. 传输：Origin 的 RingBuffer 数据通过 QUIC 流传输到 Edge
3. 健康检查：定期检测 Relay 连接状态（每 health_check_interval 秒）
4. 释放：当 Edge 上的最后一个订阅者离开后，等待 release_delay 秒后释放 Relay

故障恢复

当 Relay 连接断开时：

1. RelayManager 检测到连接异常
2. 等待 retry_delay 秒后重试
3. 最多重试 max_retry_attempts 次
4. 如果 Origin 节点已离线，查询 SessionRegistry 寻找新的 Origin
5. 所有重试失败后，Edge 上的流被标记为不可用

负载均衡

分配策略

AllocationManager 负责为新的拉流请求选择最优节点，综合考虑：

1. 节点健康状态：只选择 Healthy 状态的节点
2. 负载指标：CPU 使用率、带宽使用、订阅者数量
3. 就近原则：优先选择与请求来源同区域的节点
4. 流可用性：优先选择已持有目标流的节点（避免回源）

重定向机制

当 Edge 节点负载过高时，RedirectManager 自动将新请求重定向到其他节点：

观众 → Edge-BJ: 请求 live/camera01
Edge-BJ: CPU 使用率 90% > 阈值 85%
Edge-BJ → 观众: HTTP 302 → Edge-SH
观众 → Edge-SH: 请求 live/camera01

重定向阈值配置：

cluster:
  routing:
    cpu_threshold: 85.0           # CPU 使用率阈值
    bandwidth_threshold: 8000.0   # 带宽阈值（Mbps）
    subscriber_threshold: 2000    # 订阅者数量阈值

部署模式

单 Origin + 多 Edge

最常见的部署模式，适合中小规模：

# Origin 配置
cluster:
  sync:
    server_id: "origin-1"
    address: "10.0.1.1:8001"
    seed_servers: ["10.0.1.1:8001"]

# Edge 配置
cluster:
  sync:
    server_id: "edge-bj-1"
    address: "10.0.2.1:8001"
    seed_servers: ["10.0.1.1:8001"]  # 指向 Origin

多 Origin + 多 Edge

大规模部署，多个 Origin 分担推流负载：

# Origin-1
cluster:
  sync:
    server_id: "origin-1"
    address: "10.0.1.1:8001"
    seed_servers: ["10.0.1.1:8001", "10.0.1.2:8001"]

# Origin-2
cluster:
  sync:
    server_id: "origin-2"
    address: "10.0.1.2:8001"
    seed_servers: ["10.0.1.1:8001", "10.0.1.2:8001"]

# Edge
cluster:
  sync:
    server_id: "edge-1"
    address: "10.0.2.1:8001"
    seed_servers: ["10.0.1.1:8001", "10.0.1.2:8001"]

级联 Edge

Edge 节点也可以作为其他 Edge 的上游，形成多层级联：

推流 → Origin → Edge-L1（区域中心） → Edge-L2（城市节点）→ 观众

适合全国大规模分发场景。

运维命令

查看集群状态

GET /cluster/status

查看节点列表

GET /cluster/nodes

查看流分布

GET /cluster/sessions

手动触发重新平衡

POST /cluster/rebalance