弹性支撑百万级别直播流的乐视云“月光宝盒”是如何炼成的（内附技术干货）

在观看视频直播中，难免会发生因为各种打断而错过一些精彩片刻的情况，这个时候，如果我们能快速穿越回去，会是怎样一种体验？乐视云“月光宝盒”可以完美弥补遗憾，让精彩不再错过。

项目挑战

“月光宝盒”是乐视云直播 PaaS  平台的一个重要服务，可以完美解决直播过程中任意时间段的时移回看，也可以在直播结束后，提供瞬时秒回功能，快速将直播信号转为点播信号进行分发，大幅提升了直播观看体验，也同时给直播运营提供了更多的可能。月光宝盒历经三次产研迭代，见证了直播流由万增至百万的快速增长，一路上我们遇到了哪些挑战？直播流的分配策略是如何进化的？源站的切片、索引存储需要做出哪些升级？以及在持续迭代过程中如何确保平滑升级等等问题， 接下来我们将从“月光宝盒”三次大的版本迭代中做出解答。

月光宝盒 V1.0

直播 PaaS 平台由原支撑乐视集团业务的直播后台技术部蜕变而成，已经持续服务于乐视网、乐视电视、机顶盒、乐视体育、乐视音乐等超过 5 年时间, 早期的直播流量在万级别（注：直播流 ID 个数，可以理解为一个直播流就是一路信号），直播信号通常以 7*24 小时长直播为主，发布会、演唱会等短直播为辅（注：这类短直播无直播内容时，通常会配置一个指定的备片来持续代替直播信号源，以提升断流时用户播放体验），因此在 V1.0 架构中，这阶段的直播生产调度分配算法采用简单的配置策略，将直播流与设备组进行关联绑定，直播流对应的切片与索引采用简单的本地存储。直播、时移回看、打点录制均在该组设备中并行提供服务。

V1.0 架构图

注：

绿色表示直播流长期处于使用状态。

紫色表示直播信号暂时中断，但源站配置了播放备片功能，会播放备片信号，提高直播断流体验。

附：左图为正常直播信号，右图为直播信号中断时播放的备片。

随着直播 PaaS 平台的开放，海量直播流的接入，而商业直播的需求主要以秀场、发布会等间隔较短的直播为主，此时如果仍按照原有均衡分配直播流策略，每个直播都分配单独服务器，会导致服务器数量成倍增加，资源成本陡增，为解决这个问题，月光宝盒架构也升级至 V1.1。

月光宝盒 V1.1

在 V1.1 版本中，直播流均按需生产，为了确保客户所接入的流量安全，调度会同时分配给主备两台设备来生产该流，在主节点故障时自动执行主备切换，确保对用户播放无感知。

随着业务的快速增长，日活直播快速上升，平台对直播源站集群进行了扩容，但由于直播流分配策略会优先与时移数据绑定（注：该策略为确保全程回看数据在同台设备连续），因此在实际运行的过程中可能会出现比较严重的偏压问题，会导致比较明显的热点问题，需要通过集群上报流监控状态判断是否需要对备流进行迁移，以实现集群的再均衡。

v1.1 架构图

注：

虚线箭头表示发生偏压时，部分直播流发生迁移。

绿色表示正在播放的直播流。

红色表示直播流即将被迁移。

黄色表示直播流被迁移后。

通过流迁移的方式我们缓解了热点问题，但这种方式有一定的滞后性，我们需要新的架构来解决这个问题，在介绍新架构方案前，首先快速介绍下直播业务里面用到一些协议和文件，HLS（Http Live Streaming）是由 Apple 公司定义的用于实时流传输的协议，HLS 基于 HTTP 协议实现，传输内容包括两部分，一是 M3U8 描述文件，二是 TS 媒体文件。M3U8 文件是用文本方式对媒体文件进行描述，由一系列标签组成。

随着业务持续增长，整个直播集群的存储压力会变得比较突出，因此需要尽快消除 IO 瓶颈。在此背景下，我们首先将 TS 切片迁移到了 LeS3（乐视云对象存储系统）, 但对于视频索引的存储仍然按照主备方式管理，所以下一步重点就变成了寻找存储 M3U8 的索引集群存储解决方案，由于不同直播流对切片设置大小不一（通常设置在 2~10s），譬如北京其中一个集群最大峰值写入约在 3w 左右，业务属于写多读少，对于传统主从 RDS 来说，单机无法承受，需要做分库分表，而分库分表有很多弊端，比如对业务侵入太多、应用不友好，普遍的采用 Proxy 方案不但对技术有要求，而且还有非常多的局限性，视频直播需要灵活的扩展性，而分库分表对再扩容的成本非常高，会为业务埋下隐患。这期间我们接触到了 TiDB，其支持多活、无单点、支持横向扩容特性且兼容 MySQL 等特性与我们的业务需求非常吻合，加之 TiDB 安装部署、监控等细节做得非常到位，我们决定测试看看效果。

月光宝盒 V1.2

经过一周左右对TiDB的常用场景测试、压测，测试结果比较符合预期，从存储容量、QPS、响应时间来看，均可支持我们“快速穿越执行时移回看”的需求。测试期间也跟官方的同学进行技术交流，确定了后续生产环境中如：部署架构、设备选型、表结构及索引优化。在生产环境的 TiDB 生产集群上线后，我们将线上原有直播流的 HLS 回看的索引在原 V1.1 架构进行本地存储外，同步复制至 TiDB 中，以便于真实生产环境中来验证TiDB的稳定性。观察一月多，运行平稳，期间我们做部分故障演练，如将PD、TiKV、TiDB中某一台重启，并未出现服务不可用或丢数据的情况！接下来对北京一个直播集群月光宝盒服务进行了试点改造，采用灰度切流方式逐步将直播流的时移、回看、秒回请求切至TiDB ，运行稳定。目前全国各地直播集群的月光宝盒服务跑在TiDB服务之上。

v1.2 架构图

附一张 TiDB 在月光宝盒 V1.2 中的架构图

总结回顾

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!