绿色表示正在播放的直播流。
红色表示直播流即将被迁移。
黄色表示直播流被迁移后。
通过流迁移的方式我们缓解了热点问题，但这种方式有一定的滞后性，我们需要新的架构来解决这个问题，在介绍新架构方案前，首先快速介绍下直播业务里面用到一些协议和文件，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个阶段详述，最后我们再用一张表做下简单的回顾。
上线效果数据说明
通过将 M3U8 数据统一存储到一套 TiDB 集群，大幅度简化直播源站的结构，从源头解决负载偏压、扩展的问题，同时 TiDB 很好的解决了这类写多读少的业务场景，具体体现如下：
单机 HLS 设备生产性能提升 200%。 简化直播流分配调度策略，消除集群内偏压问题。 简化直播源站结构，消除上下游关联系统耦合。 TiDB 天然的高可用提升了系统的可用性。 依赖 TiDB 的负载均衡，优雅的解决了直播流量弹性扩展的问题。 现状及计划
目前月光宝盒 v1.2 已持续稳定的服务于标准直播、移动直播、直播CDN等三大业务线，其中北京一个核心直播集群的 TiDB 峰值 写入 QPS 达到 2.5W 左右，经过 CDN 及 HLS_Consumer 的双重缓存后读请求峰值约在 5k 左右，下一步我们会将直播内部的一套数据分析系统也迁移到 TiDB中。