如今直播盛行，用户体验备受关注，其中声音、主播画面和题目同步是焦点。但技术团队能力不足，整合视频流和业务数据流面临挑战。这是难点也是直播优化的关键。
调研云厂商付费方案
好多技术团队缺乏相关能力。就像之前有团队碰到这样的事，花力气调研云厂商付费方案。腾讯云被选中，不过不是万能的，有自己的局限性。腾讯云能做到音画题同步，可在用户答案汇总、业务功能上要求团队自己构建。
在实际中，很多企业挑来挑去才选定腾讯云。开发的部分像bug似的，要自己一个个去修正，比如HTTP请求汇总答案这块非常麻烦。
业务数据流独立传输
既然腾讯云有局限，就需要业务数据流独立传输。例如要构建一个能支持100W用户同时在线、20W并发答题、弹幕实时推送的网关服务器。Netty、ProtoBuf、WebSocket就被选中。
实际操作里，这些技术组合在一起承担自己的任务，不是简单一搭就行。要经过不断调试。技术人员在这上面也花了不少精力，像音视频流用腾讯云方案，业务数据就自研长连接方案。
消息推送机制
消息推送很复杂，像弹幕、下题、公布答案等。下层业务把消息通过MQ告诉TCP网关，再传给客户端。中间要保证不出错，映射关系的配置也很重要。
比如某平台遇到消息推送时内容出错的情况，反复检查才发现是映射环节出现漏洞。这些细节不容小觑，稍有差池，用户体验立马下降。
答题系统实现
答题系统是核心，用Dubbo实现，面向两端提供接口。高并发是必须应对的。比如答题接口20W QPS的并发量。其判断逻辑多且复杂。
在一些公司实际运营中，这个判断逻辑起到大作用。如果答题接口崩了，那整个直播活动可能瘫痪，尤其是涉及到大量用户同时答题抢红包等情况。
Redis保障高并发高可用
Redis一主多从加哨兵架构，确保高并发与高可用。多套Redis实例分管不同模块，如用户、弹幕等进行分流。
1message Message
2{
3 MessageType messageType = 1; // 消息类型，枚举值
4 string sequence = 2; // 消息序号
5
6 Request request = 3; // 请求类消息
7 Response response = 4; // 响应类消息
8 Notification notification = 5; // 推送类消息
9}
从很多平台经验看，这样做可以有效避免数据拥堵和崩溃的风险。数据拥堵在直播高峰时段司空见惯，Redis这个架构就像一个交通警察，指挥着数据流动。
计算前置的策略
答题结果计算前置到提交答案时同步完成，这能分散计算压力。红包金额提前算好存到redis也是一种前置。
曾经有个活动，没有提前计算红包金额，到发红包时系统卡半天。那场面十分尴尬，用户体验急剧下降。
你在做直播相关业务时有没有碰到类似的技术难题？如果有欢迎评论分享，觉得文章有用欢迎点赞和分享。
