弹性支撑百万级别直播流 乐视云“月光宝盒”是如何炼成的

原标题:弹性支撑百万级别直播流 乐视云“月光宝盒”是如何炼成的

作者| 刘斌

前言

乐视云计算有限公司(以下简称乐视云)是新乐视上市体系中核心业务版块之一,负责新乐视体系所有基础设施服务和云计算服务。乐视云围绕视频云和物联云两大方向开展业务,以物联云为核心创造智能的家居社区解决方案。乐视云在视频领域中的点播、直播、分发、媒体技术、视频内容理解等方面有较深的知识储备;而物联云围绕家居安全、智能互联、环境健康等方面为用户提供解决方案。

项目背景

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

项目挑战

“月光宝盒”是乐视云直播 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 中的架构图:

总结回顾

前面已将“月光宝盒“历经 3 个阶段详述,最后我们再用一张表做下简单的回顾。

月光宝盒V1.0 月光宝盒V1.1 月光宝盒V1.2
直播流分布 长直播较多、少量短直播 短直播较多、少量长直播 短直播较多、少量长直播
直播流数量 万/年 十万/年 百万/年
解决方案 直播流与设备组关联,主备部署 直播流按需分配、主备部署 直播流按需分配、集群部署
技术瓶劲 1.无法很好支撑海量短直播流的接入2.每个直播都分配单独服务器,服务器需求高 1.需定期迁移直播备流来解决设备偏压2.需在业务层解决主备切换、备份问题

上线效果数据说明

通过将 M3U8 数据统一存储到一套 TiDB 集群,大幅度简化直播源站的结构,从源头解决负载偏压、扩展的问题,同时 TiDB 解决了这类写多读少的业务场景,具体体现如下:

● 单机 HLS 设备生产性能提升 200%。

● 简化直播流分配调度策略,消除集群内偏压问题。

● 简化直播源站结构,消除上下游关联系统耦合。

● TiDB 天然的高可用提升了系统的可用性。

● 依赖 TiDB 的负载均衡,优雅的解决了直播流量弹性扩展的问题。

现状及计划

目前月光宝盒 v1.2 已持续稳定的服务于标准直播、移动直播、直播 CDN 等三大业务线,其中北京一个核心直播集群的 TiDB 峰值 写入 QPS 达到 2.5W 左右,经过 CDN 及 HLS_Consumer 的双重缓存后读请求峰值约在 5k 左右,下一步会将直播内部的一套数据分析系统也迁移到 TiDB 中。

单个直播集群对应的 TiDB 集群总体配置如下:

类型 配置 节点数量
TiDB 24C 128G 2
PD 24C 128G 3
TiKV 24C 128G SSD 3

作者介绍

刘斌,乐视云工程师,主要参与乐视直轮播、商业直播 PaaS 架构设计迭代

现在注册极客时间 App,立享 30 元新人红包,付费内容券后价低至 19 元起!返回搜狐,查看更多

责任编辑:

平台声明:该文观点仅代表作者本人,搜狐号系信息发布平台,搜狐仅提供信息存储空间服务。
阅读 ()
推荐阅读