上周和一位做了八年直播系统的前辈吃饭，我问他：直播推流的架构，到底该怎么做才能稳？

他拿过一张餐巾纸，画了一张图。

图很简单：三层结构。

第一层：采集层。负责音视频采集，包括摄像头、麦克风、屏幕采集。

第二层：编码层。负责音视频编码，H.264/H.265视频编码，AAC音频编码。

第三层：推流层。负责将编码后的数据通过RTMP/SRT协议推送到目标平台。

"很多人把这三层放在一个进程里跑，"他说，"短播没问题，长播一定会出事。"

我问为什么。

他说："一个进程跑三层，任何一层出问题，整个推流就断了。采集卡了，编码也卡，编码卡了，推流也断。耦合度太高。"

他画的第二张图是理想架构：

采集层独立进程，负责音视频输入。编码层独立进程，从采集层拿数据。推流层独立进程，从编码层拿数据，推到目标平台。三层之间通过共享内存或管道通信，但各自独立运行。

"这样有什么好处？"我问。

"好处是，采集层崩了，编码层和推流层还能用最后一帧数据继续推，不会直接断流。推流层断了，采集层和编码层还在跑，重连后无缝衔接。"

我又问："那多平台推流呢？同时推到五六个平台怎么搞？"

他在图上画了一个分发器：编码后的数据进入一个分发器，分发器复制多份，分别推到不同平台。每个平台一个独立的推流线程。

"关键点是，"他指着分发器说，"每个推流线程要独立管理连接状态。一个平台断了，不能影响其他平台。"

我问他有没有见过做得好的实现。

他说市面上有一些工具做得不错，比如秒播支持多平台同时推流，底层就是类似的分发器架构。一个平台断了，其他平台不受影响。

最后他强调了一点：推流架构的核心不是"推得快"，而是"断了能恢复"。直播推流的稳定性，不是靠永不中断来保证的，是靠快速恢复来保证的。

"平均无故障时间（MTBF）重要，但平均恢复时间（MTTR）更重要。"

那张餐巾纸我带走了。三层独立、分发器隔离、快速恢复——这三条原则，够我用了。

# 伪代码：三层独立推流架构示意
class CaptureProcess:
    """采集层：独立进程，负责音视频采集"""
    def run(self):
        while True:
            frame = self.capture_device.read()
            self.shared_buffer.write(frame)

class EncodeProcess:
    """编码层：独立进程，从共享缓冲区读取并编码"""
    def run(self):
        while True:
            frame = self.shared_buffer.read()
            encoded = self.encoder.encode(frame)
            self.encoded_queue.put(encoded)

class StreamDispatcher:
    """推流分发器：复制编码数据，分发给多个平台推流线程"""
    def __init__(self, platforms):
        self.platforms = platforms  # ["rtmp://platform_a", "rtmp://platform_b"]
    
    def dispatch(self, encoded_data):
        for platform_url in self.platforms:
            # 每个平台独立线程，互不影响
            threading.Thread(
                target=self.push_to_platform,
                args=(platform_url, encoded_data)
            ).start()
    
    def push_to_platform(self, url, data):
        try:
            self.conn = self.connect(url)
            self.conn.send(data)
        except ConnectionError:
            # 单平台断连不影响其他平台
            self.reconnect(url)