几年前在郑州承接一款本地化直播App时，最先碰到的问题不是界面，而是“流畅度”。用户投诉卡顿与延迟，测试机房却常常表现良好——这让我意识到，高并发与低延迟是两个需要并行设计的维度。基于实际场景，我先把推流入口和拉流出口分离：RTMP用于主播端上行兼容旧设备，WebRTC/SRT用于观众端以保障低延迟，再在边缘做转封装与ABR处理。

      技术选型上，我倾向于采用SFU架构（mediasoup/Janus）做实时分发，配合SRS或自研转码集群处理RTMP到WebRTC的桥接。理由很直接：SFU只转发RTP包，减少CPU开销；转码任务交给GPU节点（NVENC/VAAPI），按需启停以节约成本。实践中我把转码做成独立的Kubernetes Job，通过HorizontalPodAutoscaler基于GPU利用率与推流数自动扩容。

      网络层面，延迟控制靠几项细节累积：启用TCP BBR、调优net.core.rmem_max与wmem_max、将udp buffer扩大，客户端启用TCP_NODELAY与SO_REUSEPORT以提高短连接并发；关键链路上用QUIC/UDP优先，遇到高丢包环境降级到SRT。排查时我常用tcpdump抓包比对RTT与丢包率，配合ffprobe查看关键帧间隔与GOP大小——这些数字直接决定缓冲策略。

      并发控制不是简单堆机器，而是切片与路由策略。房间分片、主播分级、流副本按观众地域下发，这些在服务发现层通过Consul+Envoy实现路由决策。为了避免“冷启动延迟”，我在峰值前通过预热脚本模拟推流并触发容器拉起，实践证明预热比临时扩容更稳。

      监控与故障定位是我反复强调的环节。Prometheus抓取SFU与转码器的P99延迟、丢包率、编码时长，Grafana组合成一目了然的仪表盘。遇到突发卡顿，先看网络丢包再看CPU/GPU饱和，最后回到应用层日志与webrtc-internals。经验告诉我：链路上每一处小偏差都会被观众放大。

      最后给出几条实操建议：优先用WebRTC直连热点观众，复杂场景用SFU+转码混合；压力测试要覆盖推流端与拉流端同时增长；把关键参数（GOP、码率窗口、缓冲长度）参数化，便于灰度调优。未来可以把边缘计算推得更近一点，但不必盲目追求零延迟——稳定性往往更能提升体验。