零宕机直播：MediaMTX高可用架构的故障转移与自动恢复实践

直播业务最怕什么？不是并发太高，而是突然黑屏——摄像头离线、服务器崩溃、网络抖动，任何一个环节掉链子，观众看到的就是冰冷的加载图标。MediaMTX作为一款全协议媒体服务器，本身已具备多协议转换、实时转码等核心能力，但在生产环境中，单节点故障仍可能导致服务中断。本文将详解如何基于MediaMTX构建故障自动转移架构，通过热重载配置、动态路径管理和外部监控集成，实现99.99%的服务可用性。

高可用架构设计：从单点到集群

MediaMTX的高可用架构核心在于无状态设计与外部编排的结合。不同于传统媒体服务器的复杂集群方案，MediaMTX通过轻量化的配置策略和API接口，可快速接入外部监控与故障转移系统。

关键技术组件

组件	作用	实现方式
主备服务器	提供冗余计算资源	基于Keepalived的VRRP协议
共享存储	保存录制文件与配置	NFS/SMB或对象存储
监控系统	检测服务健康状态	Prometheus + Alertmanager
自动恢复脚本	执行故障转移逻辑	Python + Control API

官方文档中的性能优化指南建议，单节点MediaMTX可支持1000+并发WebRTC连接，主备架构足以应对中小规模直播场景。

配置热重载：不停机更新的核心

MediaMTX的配置热重载功能允许在不中断现有连接的情况下更新服务参数，这是实现高可用的基础。其原理是通过pathManager模块动态检测配置文件变化，并选择性重启受影响的媒体路径（Path）。

热重载实现机制

// internal/core/path_manager.go:203
func (pm *pathManager) doReloadConf(newPaths map[string]*conf.Path) {
    // 对比新旧配置，标记需要重启的路径
    for confName, pathConf := range pm.pathConfs {
        if newPath, ok := newPaths[confName]; ok {
            if !newPath.Equal(pathConf) {
                if pathConfCanBeUpdated(pathConf, newPath) {
                    confsToReload[confName] = struct{}{}
                } else {
                    confsToRecreate[confName] = struct{}{}
                }
            }
        }
    }
    // ...执行路径更新或重建
}

从源码可见，pathConfCanBeUpdated函数会判断配置变更是否属于安全更新（如录制路径修改、水印参数调整），这类变更可通过path.reloadConf热应用；而协议端口、加密密钥等核心参数变更则需要重建路径。

配置热重载实战

1. 修改主配置文件mediamtx.yml，添加备用RTSP源：

   pathDefaults:
     source: rtsp://primary-camera:554/stream  # 原主摄像头
     fallback: rtsp://backup-camera:554/stream  # 新增备用源
   

2. 通过SIGHUP信号触发热重载：

   pkill -SIGHUP mediamtx  # Linux/macOS
   # 或通过Control API触发
   curl -X POST http://localhost:9997/v3/reload
   

热重载状态可通过Control API查询：curl http://localhost:9997/v3/paths/list

故障检测：三类关键指标监控

实现自动故障转移的前提是准确检测故障。MediaMTX提供三类监控接口，可全面覆盖服务健康状态：

1. 内置Metrics指标

启用Prometheus监控后，可通过metricsAddress暴露关键指标：

# mediamtx.yml
metrics: yes
metricsAddress: :9998

核心监控指标包括：

• mediamtx_connections_active：当前活跃连接数
• mediamtx_paths_ready：就绪状态的媒体路径数
• mediamtx_errors_total：错误累计数（按协议分类）

2. 路径状态API

通过Control API查询特定路径的实时状态：

curl http://localhost:9997/v3/paths/get?name=live/stream1

健康路径的返回应包含：

{
  "name": "live/stream1",
  "source": "rtsp://primary-camera:554/stream",
  "ready": true,
  "readers": 42,
  "publisher": {"type": "rtsp", "id": "abc123"}
}

3. 事件钩子通知

利用Hooks机制，在路径状态变化时触发外部脚本：

pathDefaults:
  runOnNotReady: /scripts/alert.sh $MTX_PATH $MTX_SOURCE_TYPE

当主摄像头离线时，runOnNotReady脚本会被调用，可在脚本中发送告警或执行恢复逻辑。

自动故障转移：从检测到恢复的全流程

结合热重载和监控能力，我们可以构建完整的故障转移流程。以下是基于Python实现的自动恢复脚本示例：

故障转移逻辑

import requests
import time

MTX_API = "http://localhost:9997/v3"
PATH_NAME = "live/stream1"
BACKUP_SOURCE = "rtsp://backup-camera:554/stream"

def switch_to_backup():
    # 1. 查询当前路径状态
    resp = requests.get(f"{MTX_API}/paths/get?name={PATH_NAME}")
    current = resp.json()
    
    if not current["ready"] and current["source"] != BACKUP_SOURCE:
        # 2. 更新配置文件（切换到备用源）
        with open("mediamtx.yml", "r+") as f:
            config = f.read().replace(
                f"source: {current['source']}",
                f"source: {BACKUP_SOURCE}"
            )
            f.seek(0)
            f.write(config)
        
        # 3. 触发热重载
        requests.post(f"{MTX_API}/reload")
        print(f"Switched to backup source: {BACKUP_SOURCE}")

# 每5秒检查一次
while True:
    switch_to_backup()
    time.sleep(5)

恢复后自动切回

当主摄像头恢复在线时，可通过runOnReady钩子自动切回主源：

pathDefaults:
  runOnReady: /scripts/switch_back.sh $MTX_PATH

#!/bin/bash
# switch_back.sh
PATH_NAME=$1
PRIMARY_SOURCE="rtsp://primary-camera:554/stream"

# 检查主源是否恢复
if ffmpeg -timeout 5 -i $PRIMARY_SOURCE -v error -f null -; then
    # 更新配置并热重载
    sed -i "s/source: .*/source: $PRIMARY_SOURCE/" mediamtx.yml
    curl -X POST http://localhost:9997/v3/reload
    echo "Switched back to primary source"
fi

最佳实践与注意事项

存储高可用

录制文件的高可用可通过配置共享存储实现：

pathDefaults:
  record: yes
  recordPath: /mnt/nfs/recordings/%path/%Y-%m-%d_%H-%M-%S
  recordDeleteAfter: 7d  # 自动清理过期文件

网络冗余

• 主备服务器使用双网卡绑定（Bonding）
• 流媒体传输优先采用SRT协议（支持丢包重传）
• 配置udpMaxPayloadSize: 1300避免网络分片

监控告警

关键告警阈值建议：

• 连续3次API查询ready: false触发故障转移
• mediamtx_errors_total{protocol="rtsp"}5分钟内增长超过10次
• CPU使用率持续5分钟高于80%（可能导致延迟增加）

总结与展望

基于MediaMTX构建高可用架构的核心在于：

1. 利用配置热重载实现无感知更新
2. 通过Control API和Hooks构建外部控制逻辑
3. 结合主备服务器与共享存储提供基础设施冗余

未来MediaMTX可能会原生支持集群功能，但目前通过本文所述方案，已能满足大部分生产环境的可用性需求。建议配合官方文档中的高级配置选项，进一步优化系统稳定性。

生产环境部署前，务必参考安全指南配置TLS加密和访问控制，避免因安全漏洞导致的服务中断。