分类： 云计算
2022-11-23 10:24:02
自HQ Trivia取得成功之后，市场上又相继出现了不少类似的游戏直播、答题直播等应用。直播答题已经是风口，毋容置疑。
直播答题首先是直播，然后是答题。
海量并发派题
就传统视频直播而言，直播间通常在线用户人数是少几万人，通常情况下超过五万的不多。而对直播答题来说，直播间在线用户人数超过百万那是很平常的事情，某一线直播平台旗下的直播答题直播间在线人数更是突破了五百万人。因此，派题的环节要承受百万级别的海量并发压力，而且所有用户都是在活跃答题的，这是传统视频直播不曾面对过的压力。幸运的是，直播答题可以利用视频直播实时媒体通道来派发题目，为派题的实时性和可达性提供了天然的基础。
海量并发收题
派题可以重用视频直播实时媒体通道，可是收题却不能这么做，因为用户端不推流，而且收题要反馈标准答案和进行统计。收题不但不能重用实时媒体通道，而且还带来同样是百万级别的并发压力，那么要在视频直播架构以外构建一个分布式的子系统来处理。
视频和答题同步
派题重用视频直播实时媒体通道，和语音视频数据包是天然同步的。需要在实时媒体通道扩展一个数据通道，题目信息可以附着在相应的语音视频数据包上传输，做到视频和答题同步。同时，为了应对网络损伤，在随后的数据中可以发送一定的冗余拷贝，接收端再进行排重。
主持人背景特效
中国的直播答题应用受美国同类先行产品 HQ Trivia 的启发，主播的背景都是虚拟的特效，比如变幻的色彩，以后也可能演变成 AR 特效。这里有一个技术点就是要把画面上除了主持人以外的部分去除，然后填充上特效的画面。主持人主持直播答题节目的背景幕布是绿色的，因为在拜耳阵列中绿色的成分{BANNED}最佳多，摄影机捕捉到的绿色信息{BANNED}最佳多，在后期更容易去除绿色通道的信息。
直播答题：海量并发派题和收题
直播答题是叠加在视频直播上的业务创新，题目数据量比语音视频少很多，但派题和收题的并发压力是海量的。下面对关键技术点进行探讨，抛砖引玉，希望对大家有所启发。
首先，我们看一下直播答题的业务流程：
主持人发出派题指令；
题目信息通过实时通信网络和实时分发网络送达给用户；
VIP 用户从实时通信网络拉取题目信息；
普通用户从实时分发网络拉取题目信息；
如题目信息包含完整内容，则下一步，如果只有题目 ID，则到业务服务器查询题目内容；
用户把题目答案提交给答题统计分析服务器，同时得到标准答案反馈；答题统计分析服务器是分布式的集群，统计答题结果，反馈给主持人。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询
然后，我们看看各个网络服务实体的分工：
实时通信网络：
为实时传输而设计的网络，能实时传输海量数据，不只是语音视频。它比实时分发网络（比如 CDN）的延迟更低，具有动态回源和对抗弱网等特点；
实时分发网络：
为实时分发海量内容而设计的网络，优点是能支撑海量并发，成本相对也比较低，缺点是延迟相对于实时通信网络要高一些；
答题统计服务：
为统计用户提交的题目答案而在视频直播架构外设计的服务，能反馈标准答案，并且统计所有题目答案，{BANNED}最佳后反馈给主持人。该服务要能承受海量并发压力；
业务服务器：
如果派题信息包含完整题目内容，用户不需要再查询题目内容；如果派题信息只有题目 ID, 那么用户要到业务服务器查询题目内容。该服务也要承受海量并发压力。
海量并发派题
派题的指令必须是主持人端发出，然后服务器会担负起启动向海量用户群发题目的任务。题目是优先级{BANNED}最佳高的消息，不能像处理 IM 消息那样采取低优先级消息抛弃，或者用户分桶等应对海量并发的策略，必须要确保消息内容实时到达每个用户的终端，这是实打实的实时海量并发。
另外，如果由服务器单点在毫秒级别时间内复制群发 N 份消息，那么单点就要承受巨大的压力，这明显是不可能的。
那么海量并发派题要依仗内容分发网络的能力。内容分发可以通过实时低延迟网络或者 CDN 来完成，考虑到 CDN 有成本的优势，因此 VIP 用户的派题由实时网络完成，其它用户的派题要由 CDN 来完成。
海量并发收题
收题的环节由用户触发，每个用户答题的时间窗口不尽相同，因此每个用户提交题目的时间有秒级的差别。
然而，海量用户在数秒之内提交答案，题目答案属于重要消息，不能做抛弃处理，服务器的压力也是巨大的。
为了减少服务器压力，用户的答题将会被就近提交到边缘节点并且获得正确答案反馈，整体的答题统计结果将会由分布式的服务器集群来完成，{BANNED}最佳后传达到主持人端，使得主持人可以近乎实时地宣布统计的结果。
视频和答题同步
视频直播要低延迟，题目派送同样也要低延迟，而且要和视频画面同步。通过 IM 的能力来派题是很难做到视频和派题同步的，因为语音视频传输通道和 IM 的通道是相互独立的。一般的做法是通过实时语音视频的扩展数据通道来附带传输题目信息，让视频和题目天然就同步。
考虑到网络抖动和丢包等网络损伤的情况，在答题时间窗口内，要适当发送题目的冗余 copy，然后用户端做排重，避免题目信息丢失而导致用户收不到题目。
通过实时语音视频传输通道来派题的技术手段其实并不新鲜。在视频直播的 K 歌场景中，主播 K 歌要尽量还原线下的体验 -- 主播的歌声、画面还有歌词必须要同步在用户端显示。歌词信息在主播端打点，通过实时语音视频传输通道同步传输给用户端。
另外，还可以为主持人的背景增加特效，甚至 AR 效果。主持人要在绿幕背景前进行节目主持。在采集和编码之间的前处理环节，开发者获得原始视频数据，把绿色的画面部分去除，把主持人的画像扣出来，补充上动画或者 AR 等特效处理后，再把视频数据塞给编码环节。使用第三方视频直播 SDK 的话，那么该视频直播 SDK 必须要开放前处理接口，开发者才能获得原始视频数据，否则开发者没办法通过前处理的方式在视频画面增加特效。比如说，支持 WebRTC 的浏览器没有开放前处理接口，那么基于 WebRTC 的视频直播方案在浏览器端就不支持在视频画面上增加特效。
