1、前言
自HQ Trivia取得成功之后，市场上又相继出现了不少类似的游戏直播、答题直播等应用。直播答题已经是风口，毋容置疑。对攻城狮们来说，2018 年春节是个坎，直播答题技术做细致做到位了，才能安心过个好年。
为了应对这个挑战，我们首先分析一下直播答题和传统直播在技术上的不同，然后深度解释一下直播答题解决方案的海量并发派题和收题。
学习交流：
- 即时通讯开发交流群：320837163[推荐]
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
（本文同步发布于：http://www.52im.net/thread-1369-1-1.html）
2、本文作者
冼牛：即构科技资深语音视频专家，北京邮电大学计算机硕士，香港大学工商管理硕士，多年从事语音视频云服务技术研究，专注互动直播技术、语音视频社交和实时游戏语音。
作者的《IM实时音视频聊天时的回声消除技术详解》一文也已整理并发布于即时通讯网，有兴趣的可以看看。
3、直播技术文章参考
《实现延迟低于500毫秒的1080P实时音视频直播的实践分享》
《技术揭秘：支持百万级粉丝互动的Facebook实时视频直播》
《理论联系实际：实现一个简单地基于HTML5的实时视频直播》
《首次披露：快手是如何做到百万观众同场看直播仍能秒开且不卡顿的？》
>> 更多同类文章 ……
4、直播答题和传统直播在技术上的不同
直播答题首先是直播，然后是答题。
直播答题是构建在传统直播基础上的创新玩法，和传统直播的不同包括下面几点：
4.1海量并发派题
就传统视频直播而言，直播间通常在线用户人数是少几万人，通常情况下超过五万的不多。而对直播答题来说，直播间在线用户人数超过百万那是很平常的事情，某一线直播平台旗下的直播答题直播间在线人数更是突破了五百万人。因此，派题的环节要承受百万级别的海量并发压力，而且所有用户都是在活跃答题的，这是传统视频直播不曾面对过的压力。幸运的是，直播答题可以利用视频直播实时媒体通道来派发题目，为派题的实时性和可达性提供了天然的基础。
4.2海量并发收题
派题可以重用视频直播实时媒体通道，可是收题却不能这么做，因为用户端不推流，而且收题要反馈标准答案和进行统计。收题不但不能重用实时媒体通道，而且还带来同样是百万级别的并发压力，那么要在视频直播架构以外构建一个分布式的子系统来处理。
4.3视频和答题同步
派题重用视频直播实时媒体通道，和语音视频数据包是天然同步的。需要在实时媒体通道扩展一个数据通道，题目信息可以附着在相应的语音视频数据包上传输，做到视频和答题同步。同时，为了应对网络损伤，在随后的数据中可以发送一定的冗余拷贝，接收端再进行排重。
4.4主持人背景特效
中国的直播答题应用受美国同类先行产品 HQ Trivia 的启发，主播的背景都是虚拟的特效，比如变幻的色彩，以后也可能演变成 AR 特效。这里有一个技术点就是要把画面上除了主持人以外的部分去除，然后填充上特效的画面。主持人主持直播答题节目的背景幕布是绿色的，因为在拜耳阵列中绿色的成分最多，摄影机捕捉到的绿色信息最多，在后期更容易去除绿色通道的信息。
5、直播答题：海量并发派题和收题
直播答题是叠加在视频直播上的业务创新，题目数据量比语音视频少很多，但派题和收题的并发压力是海量的。下面对关键技术点进行探讨，抛砖引玉，希望对大家有所启发。
首先，我们看一下直播答题的业务流程：
1）主持人发出派题指令；
2）题目信息通过实时通信网络和实时分发网络送达给用户；
3）VIP 用户从实时通信网络拉取题目信息；
4）普通用户从实时分发网络拉取题目信息；
5）如题目信息包含完整内容，则下一步，如果只有题目 ID，则到业务服务器查询题目内容；
6）用户把题目答案提交给答题统计分析服务器，同时得到标准答案反馈；答题统计分析服务器是分布式的集群，统计答题结果，反馈给主持人。
然后，我们看看各个网络服务实体的分工：
1）实时通信网络：
为实时传输而设计的网络，能实时传输海量数据，不只是语音视频。它比实时分发网络（比如 CDN）的延迟更低，具有动态回源和对抗弱网等特点；
2）实时分发网络：
为实时分发海量内容而设计的网络，优点是能支撑海量并发，成本相对也比较低，缺点是延迟相对于实时通信网络要高一些；
3）答题统计服务：
为统计用户提交的题目答案而在视频直播架构外设计的服务，能反馈标准答案，并且统计所有题目答案，最后反馈给主持人。该服务要能承受海量并发压力；
4）业务服务器：
如果派题信息包含完整题目内容，用户不需要再查询题目内容；如果派题信息只有题目 ID, 那么用户要到业务服务器查询题目内容。该服务也要承受海量并发压力。
6、直播答题中的关键环节
最后，我们再分析直播答题中的关键环节。
6.1海量并发派题
派题的指令必须是主持人端发出，然后服务器会担负起启动向海量用户群发题目的任务。题目是优先级最高的消息，不能像处理 IM 消息那样采取低优先级消息抛弃，或者用户分桶等应对海量并发的策略，必须要确保消息内容实时到达每个用户的终端，这是实打实的实时海量并发。
另外，如果由服务器单点在毫秒级别时间内复制群发 N 份消息，那么单点就要承受巨大的压力，这明显是不可能的。
那么海量并发派题要依仗内容分发网络的能力。内容分发可以通过实时低延迟网络或者 CDN 来完成，考虑到 CDN 有成本的优势，因此 VIP 用户的派题由实时网络完成，其它用户的派题要由 CDN 来完成。
6.2海量并发收题
收题的环节由用户触发，每个用户答题的时间窗口不尽相同，因此每个用户提交题目的时间有秒级的差别。
然而，海量用户在数秒之内提交答案，题目答案属于重要消息，不能做抛弃处理，服务器的压力也是巨大的。
为了减少服务器压力，用户的答题将会被就近提交到边缘节点并且获得正确答案反馈，整体的答题统计结果将会由分布式的服务器集群来完成，最后传达到主持人端，使得主持人可以近乎实时地宣布统计的结果。
6.3视频和答题同步
视频直播要低延迟，题目派送同样也要低延迟，而且要和视频画面同步。通过 IM 的能力来派题是很难做到视频和派题同步的，因为语音视频传输通道和 IM 的通道是相互独立的。一般的做法是通过实时语音视频的扩展数据通道来附带传输题目信息，让视频和题目天然就同步。
考虑到网络抖动和丢包等网络损伤的情况，在答题时间窗口内，要适当发送题目的冗余 copy，然后用户端做排重，避免题目信息丢失而导致用户收不到题目。
通过实时语音视频传输通道来派题的技术手段其实并不新鲜。在视频直播的 K 歌场景中，主播 K 歌要尽量还原线下的体验 -- 主播的歌声、画面还有歌词必须要同步在用户端显示。歌词信息在主播端打点，通过实时语音视频传输通道同步传输给用户端。
另外，还可以为主持人的背景增加特效，甚至 AR 效果。主持人要在绿幕背景前进行节目主持。在采集和编码之间的前处理环节，开发者获得原始视频数据，把绿色的画面部分去除，把主持人的画像扣出来，补充上动画或者 AR 等特效处理后，再把视频数据塞给编码环节。使用第三方视频直播 SDK 的话，那么该视频直播 SDK 必须要开放前处理接口，开发者才能获得原始视频数据，否则开发者没办法通过前处理的方式在视频画面增加特效。比如说，支持 WebRTC 的浏览器没有开放前处理接口，那么基于 WebRTC 的视频直播方案在浏览器端就不支持在视频画面上增加特效。
6.4题目内容安全性
直播答题悬赏巨额奖金，各种黑产活跃到其中，题目内容的安全性十分重要。题目内容缓存在用户终端是万万不可的，必须实时地送达用户终端，否则黑产从用户终端可以提前获得题目内容。
针对题目派送的方式，目前市面上有两种第三方直播答题方案：
第一种方案，技术方案通过实时语音视频通道派送题目的全部内容，该方案的优势是完全负责了派题的安全性和并发压力，开发者不需要投入开发成本；
第二种方案，技术方案通过实时语音视频通道只派送题目 ID，用户终端获得题目 ID 后，到开发者的业务服务器查询题目内容。该方案的优势是开发者完全把控题目内容的私密性。
以某第3方直播答题方案为例：
1）如果题目内容小于 1000 字节，也就是 500 个中文字符，可以通过实时语音视频通道传输所有题目内容；
2）如果超过 1000 字节，通过实时语音视频信道传输题目 ID, 然后由用户终端以题目 ID 从就近服务器拉取题目内容。
如果第三方直播答题方案只派送题目 ID，开发者可以把题目内容缓存在就近服务器，通过题目 ID 获取题目内容，增加的延迟很小，不会影响用户体验。然而，开发者要承担查询题目的海量并发压力，还要实现题目内容的安全保护机制，比如说拉取题目要鉴权，题目传输要加密，和题目时效窗口的控制等，开发成本也就水涨船高。
7、写在最后
视频直播的魅力在于，它已经成为类电视的流量入口，类似开心辞典等在电视上被验证过的业务玩法也会逐一在视频直播平台上尝试和落地。如果说直播答题是视频直播的第二春，那么每年春天还会来，请不要意外。
（本文同步发布于：http://www.52im.net/thread-1369-1-1.html）
附录：更多实时音视频文章
[1] 开源实时音视频技术WebRTC的文章：
《访谈WebRTC标准之父：WebRTC的过去、现在和未来》
《良心分享：WebRTC 零基础开发者教程（中文）[附件下载]》
《新手入门：到底什么是WebRTC服务器，以及它是如何联接通话的？》
《[观点] WebRTC应该选择H.264视频编码的四大理由》
《基于开源WebRTC开发实时音视频靠谱吗？第3方SDK有哪些？》
《开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用》
《开源实时音视频技术WebRTC在Windows下的简明编译教程》
《网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？》
>> 更多同类文章 ……
[2] 实时音视频开发的其它精华资料：
《即时通讯音视频开发（五）：认识主流视频编码技术H.264》
《即时通讯音视频开发（九）：实时语音通讯的回音及回音消除概述》
《即时通讯音视频开发（十）：实时语音通讯的回音消除技术详解》
《即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解》
《即时通讯音视频开发（十三）：实时视频编码H.264的特点与优势》
《即时通讯音视频开发（十五）：聊聊P2P与实时音视频的应用情况》
《即时通讯音视频开发（十六）：移动端实时音视频开发的几个建议》
《即时通讯音视频开发（十七）：视频编码H.264、VP8的前世今生》
《学习RFC3550：RTP/RTCP实时传输协议基础知识》
《基于RTMP数据传输协议的实时流媒体技术研究（论文全文）》
《还在靠“喂喂喂”测试实时语音通话质量？本文教你科学的评测方法！》
《实现延迟低于500毫秒的1080P实时音视频直播的实践分享》
《技术揭秘：支持百万级粉丝互动的Facebook实时视频直播》
《理论联系实际：实现一个简单地基于HTML5的实时视频直播》
《首次披露：快手是如何做到百万观众同场看直播仍能秒开且不卡顿的？》
《腾讯音视频实验室：使用AI黑科技实现超低码率的高清实时视频聊天》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-1369-1-1.html）
