直播平台的高并发架构设计2-需求

先说一下这个核心需求为什么会出现。大家在看移动直播的时候，如果有人关注的话，会发现那些主播经常问的一句话就是“卡不卡，是不是又卡了，我要疯了，又卡住了”。你们看点播的时候，看短视频的时候，不会有人这么问吧？不会说你们看短视频，它又卡了，这种问题是最近才出现的。真正的客户都已经返回这种问题了，说明流媒体的门槛又变高了，所以他们对流媒体的需求是在增长的。那我们就看一下这些需求都有哪些。

1、首先内容产生方就是推流端，现在主流的IOS、安卓，IOS比较简单，就是那个几个机型，基本大家适配都很好。但是安卓的碎片化是非常严重的，大量的精力都需要做对安卓的适配，而且软编耗电量普遍非常高，手机用了一会就会发烫，都担心会不会爆炸。用户体验就是在不同的网络情况下，上传的视频有可能会卡，有可能不连贯，报各种各样的错误，这个是作为一个开发者他自己不可能去适配的。说白了从用户那边提的需求就是推流端不能卡，画质要好，不能太烫，这是我们接触到的客户真正提的问题，是我们从有点偏技术的角度抽取出来的，它背后对应的是哪些事情。

2、然后是分发网络。分发网络其实躲在一个很后面的地方，用户其实看不见的。真正对分发网络提需求用户也提不出来，所以基本这部分需求都会提给播放端，提的需求也是不能卡，不能花屏，首屏一定要快，一点就要看到，还不能把延时弄的太大。其实这些很多都是和源站分发网络有关系的，只是用户看不到这个需求会跟后面的播放器接在一起。

对这个需求我们做一些抽象来说就是用户的可触达性要好，我们的CDN节点要在全区域、全运营商有覆盖，包括教育网。有很多人，像那些小运营商都会忽视教育网，我们也遇到过这样的例子，教育网确实不好接，因为节点不够多，这其实不是什么难点，只是一个坑，注意到了就能做到。低延时的操作大部分来自端的配合，服务端只要是做好缓存，保证这个数据是连贯的。如果要丢数据的话，把关键帧保留好，丢GOP中间那些PB帧，主要是在端上会收到。

首屏时间，就是用户点开就要看，以前那些开源架构就是rtmp server，它是做不到一点开就能看的，现在一些开源的国内资源写得也比较好了，可以看到。我们是自己开发的，所以也花了一些工作，能保存之前的关键帧的信息，用户一点开就能看，这个就是很细节的东西了。如果这个做不好的话，会黑屏、绿屏，或者是半天看不着图像。

3、在播放器这边也是我们在接业务的时候，遇到用户投诉最多的，因为所有的问题都是在观看的时候体现的，所有的雷都得是播放器的同学去扛。这个需求也是不能卡，不能延迟太高。如果延迟高了，要追回来，追的时候声音不能变，最好是追的策略也能自己控制，这是用户真正提出来的需求。

对于我们来说，要满足这些需求，我们需要做好多分辨率的适配，保证好流畅性，保证好我们追赶的策略不会出现任何异常。所以这三个端很多是相互耦合的，像推流和分发在一起，要保障好用户的流畅性和画质，分发和播放器在一起要保证好低延时和播放的流畅。所有的这些需求里共同的一点就是不能卡，后面我们在设计方案的时候，也是重点考虑怎么能做到不卡。