在郑州某次直播带货与娱乐互动并发的项目中，我们从一开始就被两个现实问题困扰：延迟和稳定性常常互相制约，场景切换导致链路复杂度暴增。那次实战让我意识到，光有单点优化没用，必须做全链路设计——从采集到上行、转码、分发到互动、再到存储与回放，每一环都有可量化的SLA。

      技术选型上，我倾向“WebRTC+RTMP混合”策略。娱乐互动用WebRTC拿到次秒级体验，带货主播走RTMP进源、在边缘做低成本转封装并通过CDN拉伸并发。转码链路用了ffmpeg与NVENC混合策略：关键流用GPU硬件编码保证延迟和能效，低优先级或回放任务走x264软件编码以节省成本。实践中，设置关键帧间隔为1秒对实时交互有明显好处；而HLS端则用2~4秒的GOP平衡播放器兼容性与切片开销。

      多人连麦我更倾向SFU方案，除非需要服务器端合成画面（MCU）输出单一路流给大屏。SFU保留原始流转发，减少CPU开销，但需要在网络抖动下做优雅降级：实时调整码率、降帧或仅传关键帧。生产环境采用mediasoup处理点对点与多路转发，使用SRS作为RTMP/HTTP拉流的origin；Kubernetes承载各组件，GPU用node-pools隔离，HPA基于自定义指标（入/出包速率、RTCP丢包）触发伸缩。

      链路问题排查有一套固定动作：tcpdump抓包定位丢包与重传、ffprobe检查编码参数、Wireshark分析ICE候选序列与DTLS握手。订单与互动事件走Kafka+Redis组合，低延迟指令通过WebSocket+Protobuf下发，重要事件做幂等与重试。常见坑？TURN配置失误、NAT映射策略、nginx的worker_rlimit_nofile不够，这些都会在高并发下突然暴露。我学到的教训是：先把可复现场景写成脚本，再调底层网络与系统参数。

      最后给出几条实操建议：先把核心流的端到端观测埋好（P50/P95延迟、丢包、首帧时间），分阶段上线，灰度放大并做混沌测试；边缘优先做转码与录制以减轻回源压力。技术未来可能向QUIC/WebTransport与更高效编码演进，但当前更值得投入的是可观测性与自动化回退机制——这些往往比单点性能优化带来的收益更确定。