干货分享：细说双 11 直播背后的压测保障技术

干货分享：细说双 11 直播背后的压测保障技术

直播的架构

我们通常看到的有下面几种直播:

单人直播，例如淘宝直播,通常伴随着秒杀，弹幕，送火箭等业务逻辑； 多人同时直播，例如连麦，会议； 录播，对于部分直播场景如培训、会议等，需要将现场直播视频保存以进行传播、留存等使用，有对直播进行录制的需求。这种往往对实时性要求不高。

视频流推拉逻辑，如蓝色线所示 常规的业务逻辑，如黄色线所示

可以看到有四个主要模块：

推流端：主要的作用在于采集主播的音视频数据推送到流媒体服务端； 流媒体服务端：主要作用在于把推流端传递过来的数据转换成指定格式，同时推送到播放端方便不同播放端用户观看，当然目前云产商也流媒体服务端的一整套解决方案； 业务服务端：主要处理一些常见的业务逻辑，如秒杀，弹幕等等； 播放端：播放端简而言之就是拉取音视频进行播放，把相应的内容呈现给用户。

四个关键的模块的协议其实就是流媒体传输协议。大部分直播的结构都采取上图的格式，较大的区别是是否引入 CDN。一般来说，我们建议客户引入 CDN 来减少直播流量对服务器的冲击。四个模块之间的协议并不着重强调一致性。 接下来，我们沿着这个架构来讨论一下，在这其中比较脆弱的风险有哪些，以及我们如何提早通过压测来排查这些风险点。

直播中的挑战

挑战一：视频流给流媒体服务端的压力

在这个推拉的逻辑中，由于涉及视频的流量较大，经过的路线较长，对流媒体服务器都会造成冲击；通场的做法是引入 CDN，当用户开始收看视频的时候，会先就近去 CDN 拉取流，如果这个时候视频内容还没有缓存在 CDN 的时候，CDN 就回源到流媒体服务端。  但是，风险就存在在瞬间大量用户同时收看 CDN，CDN 大量回源的时候；这种脉冲流量，会给流服务端带来不可预计的效果。 我们通常通过压测来提前验证链路的有效性，甚至可以通过压测，提前把视频在 CDN 预热。然而，传统的 HTTP 请求协议是无法支持这种场景的，因为：

即使开源软件 srs_bench，以及 JMeter 都提供了一些插件来使用。但是这些开源软件需要用户对视频协议有比较深入的理解，使用门槛会略微偏高； 视频压测本身对带宽的要求非常高，这就意味压测机器成本比较高； 视频压测需要考虑到地域对传输质量的影响。

挑战二：低延时的互动协议

和传统的大促不一样，直播往往追求和线下客户的互动。例如弹幕，评论，聊天，秒杀等等。主持人聊的 热火朝天，用户毫无反应，这就是一次失败的直播了。而普通的 HTTP 请求无法满足对时效的需求；因此，通常这些功能用WebSocket来实现的。因为 HTTP 是一种无状态的、无连接的协议，WebSocket 则通过服务端/客户端建立长链，来保证消息的实时性、以及降低性能开销。 每建立一个 WebSocket 连接时，在握手阶段都会发起 HTTP 请求。通过 HTTP 协议协定好 WebSocket 支持的版本号、协议的字版本号、原始地址，主机地址等内容给服务端。报文的关键地方在于 Upgrade 的首部，用于告诉服务端把当前的 HTTP 请求升级到 WebSocket 协议，如果服务端支持，则返回的状态码必须是 101：

HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept:xxxxxxxxxxxxxxxxxxxx

挑战三: 高并发的脉冲流量

不同于普通应用，直播类应用的使用时间段非常的集中，因此在这短短几小时之间，会涌入大量的用户，一次大 V 的直播通常就会造成百万级的用户登录，故直播系统对应脉冲流量的能力要求也变得很高。而且在抢货的时候，和传统的秒杀不同，往往是主播进行到某个时间突然发起秒杀的--这个时间往往无法非常精确--同时脉冲流量对系统的要求极高，很多平时不会出现的问题，例如懒加载，jit 预热，冷热数据切换等传统大流量不会出现的问题，都会出现。 这两点特性，要求压测工具能够瞬间发起大流量。这除了需要较多的机器引擎，还需要对流量的有精准控制--满足流量快速攀升的诉求。 而这两点，正是阿里云 PTS 的强项。阿里云 PTS 站在双 11 巨人的肩膀上，是阿里全链路压测的延伸。PTS 通过伸缩弹性，轻松发起用户百万级别的流量，免去机器、人力成本；PTS 对流量的控制，能够实时脉冲，精准控制； 是应对视频直播快速攀升的流量脉冲的优秀方案。

最后

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。