海量用户实时互动直播架构探索

如今比较流行的直播，常常会出现这样的状况： 用户打了一个弹幕上去，主播念出来的时候，弹幕已经飞出去了。两者时间是不匹配的。

这是咱们的一个客户，两个主播连线互动，实时交互。试想，若是直播时延时高达几秒，像这样的双主播组合是没有办法进行交谈的。A说完以后，对方要等几秒才能听到，又过了几秒，A才能听到对方的回答。

这两个例子其实要说明实时互动直播和普通直播相比有本质的区别：延时。实时互动直播延时必须低达几百毫秒。

为何是几百毫秒？为何不是几秒也不是几毫秒？这是由人们平常交流习惯决定的。人的说话声音经过声波传播，若是两人相隔34米，那么延时就是100毫秒。基于这个范围，略长的延时，观众还能。基于互联网的音视频通讯，音频通话延时标准在400毫秒之内，视频通话延时在800毫秒之内，这可让通话双方无延时感知的。延时若是达到秒的数量级，那么通话双方就会有明显的等待。

互联网是基于电磁波或者经过光纤传播的。光绕地球一圈，耗时300毫秒，这是没法逾越的物理定律延时。有人号称能够作到0延时，他们估计用上了量子通讯。在实际互联网应用中，网络条件并不理想，互联网信号绕地球一圈的延时必然大于300毫秒。这就给实时互动直播，带来了巨大的挑战。

实时互动直播的挑战

第一，互联网的骨干网上路由器的部署，不是直线点到点，而是中间要通过不少路由器的跳数，其实是在走“弯路”。因此，互联网传输没有办法绕地球一圈正好300毫秒，最好的状况也须要要近400毫秒。

第二，公共互联网上，路由器其实常常出现故障。好比，在晚高峰的时候，网络会比较慢。这是由于部分路由器可能过载。由于路由器有最大的处理能力上限，一旦超过上限，就不能处理，会形成丢包、拥塞。

第三，无线网络相对有线网络，可靠性较低。无线网络普及度愈来愈高，，愈来愈多的手机、笔记本链接无线网。可是无线网络相对有线网络没有那么可靠，同时也会引入信号污染。信号覆盖不到的地方，效果较差。

第四，高并发挑战。首先须要普及一个概念：并发和在线是有区别的。当今的移动互联网，你们都在讲千万级。当咱们谈及海量用户架构这个话题时，彷佛若是不说到上亿这个量级，是落后了。可是实际上，前面这些说法都混淆概念了，它们都在说“在线”，而不是“并发”。如下图为例：

左边是QQ在线好友列表，图中能够看到不少好友展示，其实没有交互，使用者不会有压力。右边是一个框同时和不少人聊天，使用者会感觉到巨大压力。一样的，对于直播服务而已，若是用户只是在线，不多会跟服务器有交流，最多偶尔发一个心跳包。

用户在线时，若是参与了“看”“说”，这就是并发。直播的并发峰值具备突发性，每每跟主播的活动密切相关。好比，主播会跟粉丝约定直播时间，到了约好的时间，粉丝就会在短期大量涌入一个直播频道。观众慢慢进入频道，服务器没有压力，但若是瞬间涌入，后台的压力很是大。

本文，将重点介绍互动直播的可用性问题。电信业务的可用性标准是四个九，咱们指望作到五个九。双十一时，支付宝的处理能力很是强，百度百科上提供的数据显示，支付宝当天处理了96%订单。可是，咱们对本身的互动直播有更高的要求，指望作到99.999%。

实时互动直播要保证高可用性，有巨大的难度，缘由以下：

1. 实时很难。互联网基础设施不是为实时通讯设计的。

2. 覆盖很难。机房找点，互联互通。对通讯云来讲，覆盖很差会影响到可用性。

3. 高并发很难。不能看着看着就不动了，没声了。

4. 突发性很难。系统容量要高，还要防止雪崩。

这些挑战咱们在作整个服务的时候，都须要全面考虑。

直播架构的演进

一、CDN直播架构

这是当前流行的直播架构，左下角是一个主播，主播经过手机或电脑等设备，把本身的视频流上传到服务器，接入目前流行的CDN服务，经过CDN服务进行网络分发，分发到各地的用户。全部用户均可以看到主播的表演。

二、单服务器实时互动直播架构

实时互动直播，不能使用CDN方案，由于CDN方案性质决定了延时达不到实时的要求。下图是咱们认为能够实现实时互动的架构。主播把本身的视频流上传到服务器，经过这台服务器分发给其余用户，再采用合适的传输协议，延时能够作到很小。从主播到服务器再到观众的延时，加上编解码和抖动的延时，能够作控制在几百毫秒之内。

这个架构很简单，但有一个缺点，没有考虑覆盖不一样地用户的问题。而且一台服务器支撑不了大规模用户。这台服务器若是宕机，或者服务器机房出故障，整个传输都会受到影响。这必然达不到高可用架构的标准。

三、分布式实时互动直播架构

主播的视频流上传到一个接入服务器，这个服务器会把这个视频流分发到咱们部署在世界各地的服务器。而后这些服务器接入本地的用户，把视频传下去。

在这个架构里面，首先能够解决的是覆盖问题，部署在世界各地的服务器，可让用户能够快速就近接入。整个视频流经过咱们在互联网上作的分布式传输算法，把它实时的传输到世界各地的机房。其次，能够避免机房甚至骨干网故障，对传输形成的影响。

如何实现高可用性

可用性能够分为两个部分：接入可用性和使用可用性。你在使用服务的时候，可以接得进去，可以听获得，这是接入可用性。举个例子，打电话的时候，有时会出现你所呼叫的用户没法接通，由于用户的手机没有接入电信服务，这就是接入可用性问题。在通话的时候，听不到对方说话了，使用中掉线了，这就是使用可用性。

为了实时监测可用性，咱们作了两方面的监测：

一、主动监测

服务可用性不能依靠用户数据反馈或者用户主动上报，这样你永远是最后一个知道的。何况初期用户量小怎么办？所以，咱们须要本身给出咱们的服务有多可靠。为此，咱们研发主动监测系统来监测整个服务。端到端监测，接入有没有问题，在使用的过程当中会不会出问题。

二、被动监测

用户在使用咱们的服务的时候，咱们会收集用户接入服务的整个过程，多长时间能够接入，接入时通过了几回请求，使用中有没有掉线，中间有没有声音终端或卡顿。咱们会收集这些数据，据此了解服务的可用性。

有了监测数据，那么就能够据此来不断改进咱们的服务，解决前面所说的挑战。

一、覆盖问题

在中国作互联网的人应该都有一个感觉，联通跨电信，用户之间是难以交互的。早期的QQ传文件没有作中转，若是联通和电信的用户要互相传文件，速度很是慢，甚至会中断。玩网游的用户，也会遇到有电信专区、网通专区。下图是一个简单的测试，当跨运营商的时候，发一个包，能够看到里面有不少丢包。这个数字是RTT，这个测试结果能够看出，最小是62毫秒，最大是840毫秒。

不但中国有网络互通的问题，国外也有。不少人觉得发达国家，好比美国、日本，互联网的基础设施较好，因此不会有互联互通的问题。可是，在咱们作实际测试时，美国的互联网也存在互联互通的问题，只是情况比中国好一些。

上图，展现了一个一个阿尔及利亚用户的网络情况。他接入的是国家电信的服务商，从骨干网接入阿尔及利亚电信有不少线路，最下面的线路意大利电信是最直接的。若是不走意大利电信，那么中间就必须通过不少运营商跳转。在这种状况下，要保证用户有作最快的传输，就要保证传输走意大利电信。这必须依靠覆盖来解决。

如何解决覆盖问题？

首先，部署大量边缘服务器。边缘服务器的地理位置越接近用户越好，两者的线路越接近约好，同一个SP最好。好比中国国内，咱们会有大量电信、联通、移动服务器。当咱们发现一个接入的用户是电信时，咱们会找电信线路，若是是联通的会找联通线路。再看回上一个图，若是遇到阿尔及利亚的用户要怎么办？在如今的服务里面咱们就要找一个意大利电信接入，而不是随便找欧洲的机房。必须部署不少边缘服务器才能作到这一点。

其次，要有分配服务。有边缘服务器以后，用户仍是没法接入边缘服务器，由于他不知道接哪一个。所以，必须有配套算法，根据用户的SP，找到和他最匹配的边缘服务器，来进行接入分配。

二、跨地域问题

咱们在全中国有好几十个机房，其中有不少电信的机房，不一样的电信用户来使用咱们的服务，应该给他哪一个电信机房呢？若是把北京电信用户接到广州的电信机房，虽然大多数状况下丢包不会很高，但延时会比较大。为此，咱们设计了就近接入算法，使用咱们服务的每一个用户，都会接入到最靠近他，且线路最匹配的服务器。

当咱们就近按SP接入时，遇到了一个新问题：假如一个香港用户，接入的是香港机房，想看北京联通用户的表演，那么这个香港用户怎么看到北京用户的表演呢？咱们就须要有一个分布式传输的架构和算法，来把北京的流量传到香港。

三、DNS解析问题

今天无线互联网很是普及，使用无线网时，有一个问题比有线网更严重：DNS解析。用户接入时，第一步是经过域名解析，解析到最近的服务器。可是，作DNS解析时，无线网络的信号会存在污染，致使DNS解析失败。为此，咱们优先使用解析，解析不到再用静态IP配置。

四、骨干网故障问题

咱们发如今骨干网上，不少默认的骨干网路由常常出问题，同时有一些骨干网部分是不会拥堵的。基于这样的发现，咱们作了本身的路由网络。

在默认路由以外，咱们会额外部署路由机房。好比，从上海到洛杉矶，假设默认线路到晚上高峰期会比较拥堵，同时咱们发现从上海通过广州再通过香港再到洛杉矶，这条线路不会拥堵。那么，咱们就会部署这样一条路由线路，而后作自动的适配。

若是骨干网上出故障了，咱们经过路由的方式构建Overlay应对。首先，咱们的应用会先链接到分配服务，分配服务会给出一批可接入的机房，当接入的机房坏了，就当即切换到下一个可用机房，若是发现仍是坏了，则再次接入到分配服务，继续寻找当前可用服务器。

五、蜂拥

蜂拥是实时互动直播里面特别突出的现象，短期内大量用户进入频道或者使用服务。蜂拥对整个后台的冲击力很是强。大多数的互联网的后台服务器每秒接入大概千的量级，可是对于蜂拥而来的用户，处理量远远不够。这时候就会遇到一个问题，后台处理响应速度愈来愈慢，不少用户的请求会超时。超时以后就会进入更多的请求，请求就会像滚雪球同样愈来愈大，致使整个后台系统不能响应，整个系统就会产生雪崩，这叫雪崩效应。

如何防止雪崩效应

1）要把性能上限提升。一般来讲咱们的性能上限会达到峰值处理能力10倍以上。性能上限提升要作分配服务性能扩展，咱们的作法通常是水平扩展，由于垂直扩展比较困难。

2）应用里面作自动的重复请求，它会不断累计请求量，咱们要作退避的策略。

3）保证整个接入服务自己的可用性问题，处理方法很简单，多点备份，而后作并发的请求。咱们有不少分配的服务器，们的应用接入的时候会同时从几个点请求分配，分配到一批边缘服务器以后，会同时链接几个边缘服务器，哪一个先响应就处理哪一个。

本文整理自声网Agora.io 1号架构师李伟，在ArchSummit深圳2016 全球架构师峰会 的演讲。

【李伟】

2006年-2008年，在PP live工做的时候研发了PP live（已改名PPTV），当时最高有接近150万人在线。2008年到2010年，在新浪负责新浪视频的研发，2008年的欧冠直播，40万人在线。2010年到2013年在YY工做，主要负责YY的架构，最高在线是超过一千万，最大的单人频道达150万左右。2013年，加入声网，负责声网音视频的系统架构。