直播系统源代码，音视频处理及技术选型依据

技术选型及依据
一. 音视频处理及传输的方案选型

音视频处理及传输，因为技术团队不具备这方面的能力，所以当时调研了各种云厂商的付费解决方案，最终采用了腾讯云的直播解决方案。主持人侧：通过演播室的专业摄像设备，搭载腾讯云提供的obs推流软件，即可进行视频录制和推流。用户侧：APP端集成腾讯云的SDK，动态拿到推流地址后即可观看直播。

二. 业务数据流的方案选型

业务数据是指除音视频以外的，和答题应用场景相关的数据（比如题目、答案、弹幕、红包等）。腾讯云提供了两种可选方案：

1、题目预先设置好，直接由腾讯云的SDK通过音视频通道下发，打入直播流中。

2、让题目先通过腾讯云的IM通道快速送达观众端APP，在观众端先缓存下来，等待播放器通知了预期的 NTP 时间戳之后，再把题目显示出来。

腾讯云的这两种方案都可以提供“音-画-题”的完美同步，但是存在以下局限：用户的答案必须以HTTP请求方式汇总到答题服务器，这一块必须自己开发，另外公布答案、抢红包、弹幕这些业务腾讯云系统都是不支持的，在底层通信通道上仍然需要自行开发。

考虑上述局限以及业务的多变性，我们最终打算自研业务数据流通道。这样视频流和业务数据流会分两个通道下发，因为业务流相对视频流的数据量很小，只要能保证业务逻辑的处理速度和业务数据的下行速度，“音-画-题”的延迟是可以接受的。毕竟当时已经是4G时代，如果用户侧的网速不行，视频流可能都无法正常观看了。

为了做到业务数据流的独立传输，需要实现一个长连接、高性能的网关服务器（支持100W用户同时在线，20W并发答题，弹幕实时推送等要求），我们的技术选型是：Netty、ProtoBuf、WebSocket，选型理由：

1、Netty：Netty是当时最流行的高性能和异步NIO框架，直播答题的业务场景中，涉及到题目下发、弹幕、下红包雨等非常多的推送场景，而且一场答题活动中，客户端和服务端的通信频繁，长连接比短连接在性能上更优。

2、ProtoBuf：作为客户端和服务端的数据交换格式，PB是一种效率和兼容性都很优秀的二进制数据传输格式，在码流和序列化速度上明显优于JSON、XML、hessian等主流格式，同时支持向前向后兼容以及各种主流语言。

3、WebSocket：是 HTML5 一种新的协议，用来实现客户端与服务器端的长连接通讯。

三. 服务端的部署方案选型

前面提过，直播答题仅作为商城的一个运营活动，它依托商城原有的用户体系，运营系统，大数据系统，提现通道等。现有的商城系统部署在我们自建的机房中，为了降低对商城现有交易系统的低干扰，我们采用了『私有云+公有云』的混合部署方案。将高并发的答题系统以及它所依赖的缓存、MQ等公共组件部署在公有云上，方便弹性扩展，同时降低对商城交易系统的流量冲击。

04 架构设计方案
一. 音视频直播架构

上面是腾讯云直播解决方案的架构图，其他云厂商的直播解决方案，技术架构类似。感兴趣的同学可以直接去腾讯云官网上详细了解，这里不做展开。

二. 数据流方案

音视频流采用了腾讯云的直播解决方案，而业务数据流（活动、题目、答案、弹幕、红包等）则采用了自研的长连接方案。架构图中的答题系统和答题运营后台也均为自研。客户端会分开处理两个通道的数据，以控制用户交互上的变化。