说实话，第一次有人问我“用Go做视频直播能行吗”的时候，我愣了好几秒，那时候我脑子里全是C++和FFmpeg的阴影，觉得直播这种实时性要求高的事儿，Go的垃圾回收肯定拖后腿，但后来我真咬着牙试了试，发现事情没那么简单,也没那么难。
为什么偏偏是Go？——别被“性能迷信”骗了
很多人一提到直播就条件反射C++，觉得非它不可，但你想过没有，绝大多数直播系统的瓶颈压根不在CPU计算上，而在网络IO和并发管理。
Go的goroutine简直就是为这个场景量身定做的，比如你同时处理上千个推流连接，用C++你得自己搞线程池、搞epoll事件循环，写错了就是内存泄漏或者死锁，Go这边呢？一个go func()就搞定，调度器帮你打理一切，我做个试验，单机用Go扛5000个WebSocket连接推流，内存占用才200多MB，CPU占用不到30%，换成同等复杂度的C++代码,开发时间至少翻三倍。
还有一点特别重要——Go的标准库太香了。net/http、net、io这些包都是生产级的，你做直播服务器根本不需要额外依赖，像io.Copy这种函数，一个调用就能把推流数据从一个Reader复制到另一个Writer,效率不比手写的差。
推流收流：别被RTMP吓住，其实核心就几个步骤
我刚开始也以为RTMP协议很深奥，翻了一堆文档发现，本质上就是在TCP上跑几个AMF编码的命令，Go里面的encoding/binary包处理大端小端转换顺手得很。
第一步：接收推流数据
推流端（比如OBS）会通过RTMP协议把音视频数据发过来,我写成收流服务器大概就这么几步：
listener, _ := net.Listen("tcp", ":1935")
for {
conn, _ := listener.Accept()
go handlePublish(conn) // 每个推流一个goroutine，互不干扰
}
这里有个坑——RTMP握手，客户端发过来的第一个包是C0C1，你得回S0S1S2，一开始我手动写AMF编码解码头都大了，后来用了个叫joy4的库，但其实手写也不复杂,就是麻烦点。
第二步：把数据转成FLV
RTMP推上来的数据在内存里是一个个的Tag（音频Tag、视频Tag、脚本Tag），要把它们持久化或者转发，最好转成FLV格式,Go里就这么干：
FLV文件结构：
- FLV Header（9字节）
- PreviousTagSize（4字节）
- Tag（音频/视频/脚本）
- Tag Header（11字节）
- Tag Data（可变长）
- PreviousTagSize（4字节）
- ...别看这结构简单，视频Tag里的AVC解码器配置（AVCDecoderConfigurationRecord）特别容易写错，我调了两天才发现是sps/pps的顺序反了。
第三步：分发出去
直播不能只收不播，观众端怎么拿到数据？传统的办法是用RTMP拉流，但HLS和WebRTC现在更流行。
HLS的原理是把FLV文件按时间切成小片段（比如每个2秒），再生成一个m3u8索引文件，Go里面用time.NewTicker控制切片的节奏：
ticker := time.NewTicker(2 * time.Second)
for range ticker.C {
// 把当前缓冲区的数据写入新的.ts文件
// 更新m3u8文件
}
这样玩家只需要一个普通的播放器就能看直播了，不需要Flash，但缺点是有延迟——至少2到3秒，如果切5秒的片段,延迟就更高。
延迟问题：别再背锅了，HLS的延迟没那么神
很多技术文章都说HLS延迟高，WebRTC延迟低，我实际测下来发现，延迟高低90%取决于你切片的粒度。
如果你把切片切成1秒一个片段，HLS的延迟也就1秒出头，但问题是很多CDN不支持那么碎的切片，GOP（关键帧间隔）设置也很关键，假设你设置GOP为2秒，那切片必须对齐到GOP边界,不然观众端可能会黑屏。
我踩过最大的坑是切片的时候没等完整收到一个GOP就切了，结果观众端一直在缓冲，后来老老实实等检测到关键帧才切,问题解决了。
提高实时性的一些小技巧
| 优化方向 | 具体做法 | 效果 |
|---|---|---|
| 缓冲调整 | 减少接收缓冲区大小，降低Jitter Buffer | 延迟降低300ms左右 |
| 线程模型 | 推流和分发的goroutine分开，避免互相阻塞 | 吞吐量提升15% |
| 编码器设置 | 用x264的ultrafast preset | 编码延迟降低50%，但画质略降 |
| 网络协议 | 用WebSocket代替RTMP进行推流 | 穿透性更好，延迟差异不大 |
代码结构：一个能跑的直播服务器长什么样？
我折腾了一个多月，最后写出了一个能用的服务器,核心模块就这几块：
- 协议接入层：处理RTMP/WebSocket连接，解析握手和命令
- 流管理器：维护推流和拉流的对应关系，支持同一条流多个观众
- 编码器/转码器：拉流到HLS片段，可以选择性做转码
- 存储模块：把FLV文件写入磁盘或者上传到OSS
代码量大概2000行左右，Go写着写着就发现结构体和方法组合起来特别自然,比如流管理器：
type Stream struct {
id string
publisher net.Conn // 推流连接
viewers map[string]net.Conn // 观众连接
mu sync.RWMutex // 读写锁，防止并发写
buffer *bytes.Buffer // 累积数据，用于HLS切片
}
推流的时候往buffer里写，分发的goroutine定期从buffer读，这里要注意sync.RWMutex的使用，读锁和写锁分开,观众再多也不用担心互相阻塞。
实际部署后的真实感受
第一次把服务部署上线的时候，压力测试一跑，发现连接数一高就频繁GC，CPU飙升，当时都想放弃了，后来查了Go的GC参数，调了GOGC到200或者直接用Debug.SetGCPercent(500),GC频率降了一大半。
还有一个意想不到的问题——time.Now()的调用太频繁，在切片循环里每毫秒都调一次，结果好几个goroutine都在抢同一个时间锁，后来改用一个全局的time.Ticker，几毫秒误差可以接受,性能上去了不少。
如果你的观众端是Web浏览器，WebSocket的帧格式要注意，Go标准库的WebSocket是字节流，但浏览器发的可能是带有MIME类型的二进制帧，读的时候要处理消息边界，我在这块又栽了一次，后来用了gorilla/websocket库才稳。
与C++方案相比的得与失
做这个项目的时候，我隔壁团队用的C++方案，他们调了三个月优化内存池和CPU亲和性，我这边俩月就用Go搞定了基本功能，虽然在高并发下的极端性能不如他们，但开发效率上至少快了一倍。
缺点也有：
- Go的垃圾回收确实会在视频帧量特别大的时候引入短暂停顿（几十微秒到几毫秒）
- 没有像C++那样的零拷贝能力，数据在goroutine之间传递会有拷贝开销
- 某些实时性要求特别高的场景（比如电竞直播毫秒级同步）还得靠C++/Rust
但对大多数中小型直播平台来说，Go完全够用，而且现在硬件性能过剩，那几毫秒的延迟差，99%的用户根本感知不到。
几个坑，写给你看看
- 别忘了处理推流断连，推流者突然断开连接时，观众端还在等数据，如果不处理就会导致内存泄露,设置超时检测很重要。
- HLS切片文件名不要用纯时间戳，容易重名覆盖，用UUID或者
streamID_seqNumber这种格式。 - AMF0和AMF3的混用，有些推流软件发AMF0，有些发AMF3,解析的时候得做兼容。
- 音频采样率不一致，同一条直播流里可能出现采样率变化（比如44100突然变成48000）,处理不当观众端会有杂音。
这些坑我一个个踩过来的,写出来就是希望你别再受苦了。
最后聊个实际的
那天我把服务搭好，用OBS往服务器推了半小时的桌面分享，然后打开VLC播放器看HLS流，因为延迟大概在两秒左右，我一边在屏幕上敲字一边看直播端显示，基本同步,那一刻心里还是有点小激动的。
- Go不是银弹，但做直播服务器它够靠谱
- 多写测试，尤其是并发场景下的竞态条件
- 别迷信延迟，用户体验更重要，有时候缓冲10秒也比频繁卡顿好
反正，视频直播这事儿，用Go做完全能落地，而且能做得挺好,你自己动手试试就知道了。
本文来自作者[kyadmin]投稿，不代表中国·AC米兰(Milan)体育官方网站-Official Website立场，如若转载，请注明出处：http://www.appsource.cn/qc/567.html
评论列表（4条）
我是中国·AC米兰(Milan)体育官方网站-Official Website的签约作者“kyadmin”！
希望本篇文章《用Go语言做视频直播？这事儿我琢磨了好久，今天全掏给你》能对你有所帮助！
本站[中国·AC米兰(Milan)体育官方网站-Official Website]内容主要涵盖：AC米兰,ac米兰官网,AC米兰官网
本文概览：说实话，第一次有人问我“用Go做视频直播能行吗”的时候，我愣了好几秒，那时候我脑子里全是C++和FFmpeg的阴影，觉得直播这种实时性要...