正文
随着直播 PaaS 平台的开放，海量直播流的接入，商业直播的需求主要以秀场、发布会等间隔较短的直播为主，此时如果仍按照原有均衡分配直播流策略，每个直播都分配单独服务器，会导致服务器数量成倍增加，资源成本陡增，为解决这个问题，月光宝盒架构也升级至 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 安装部署、监控等细节做得非常到位，决定测试看看效果。
