何以突围短视频红海？秒拍海量播放下的高性能视频调度实践

每日处理二十亿以上播放请求的大型视频网站，如何精准高效地将用户的请求迅速播放，是充满挑战的一件事。秒拍在这方面已经积累了丰富的经验，技术团队采用细化用户每次播放请求，并结合近期内综合调度大数据，实现了在  C 段 IP 级别动态的调度响应及区分。

本文针对短视频播放面临的挑战、应对方法以及调度系统的概念与特色等内容进行分享。

短视频播放面临的挑战及应对方法

短、长视频之间的区别

短视频从 2015 年兴起，爆发也是近两年的事情。与长视频的区别主要有如下四个方面：

• 时长：短视频时长较短，通常为几分钟，长视频通常为 20 分钟以上乃至数小时。

• 来源：短视频来源普遍，以 UGC 为主，比较鲜活，长视频以版权为主。

• 更新：短视频更新量很大，每日数万条;长视频更新量比较少，每日数十条至数百条不等。

• 播放量：短视频平均播放量小，数次至数十次;长视频平均播放量在数千到数万级别。

短视频播放面临的难点

基于短视频的特性，短视频播放面临的挑战有如下几个方面：

• 因播放时长短，因此对首播延时时间很敏感。相比几十分钟的长视频，用户对出现的广告还能够接受。但短视频加广告，用户可能三分之一的时间花在等待上，体验度就不好。

• 因上传来源地区普遍，须要快速分发，这样在推送上会存在很大挑战。

• 更新量大，平均播放量太少，因此内容总体会偏冷，对如何快速推广到全部渠道观看或产生关键行为的节点，要求较高。

从上传和播放两端入手应对难点

上传端经过普遍创建所在地区的节点来优化，须要在原站和各大区都进行建设，如北京、天津覆盖整个华北地区，广东覆盖华南地区，基本保证每一个区有最快上传点。

还有根据实际状况，数据会采用各类传输压缩方法。对于播放端，技术上采用 CDN 分发，而后作多节点预推送的操做。

调度系统的概念、功能及特色

面对节点繁多超过 200 家 CDN 的厂商，如何选择核心的调度?若是用户发出请求，如何知道具体派发到哪一家的哪个节点?这就涉及调度系统的应用。

什么是调度系统?

就是接到用户请求，基于分析请求的上下文，对后端提供服务的全部节点进行打分，凭打分结果把用户请求转发给合适的后端提供服务的系统。

视频调度主要有如下几个输入输出：

• 输入用户的 IP 和请求内容

• 对可分发的 CDN 节点进行逻辑处理，须要掌握后端有多少节点，哪些节点是活的，还要作打分排序

• 肯定节点以后，输出请求到对应的节点

调度系统的功能，要实现：

• 负载均衡

• 对服务异常的节点作故障隔离

• 对后端节点、服务等作健康检查

• 具有日志记录功能

• 针对安全性问题，有权限分配功能

调度系统的特色

做为吞吐量日播放二三十亿的站点，调度系统不多是一个单点，且用户来源很是多且重要，这样在高吞吐、高可用基础上，技术上要尽量压缩用户的等待播放时间，来提高用户体验，因此要求系统高性能。

秒拍调度系统的发展

调度系统主要分为 GSLB v1 和 GSLB v2 两个版本。在秒拍刚成立时，播放量天天大概近百万，这时 GSLB v1  是基于第三方评分的地域调度系统，直接经过原站加 CDN 的方式来支撑。

新浪投资秒拍后，工程师开始使用新浪的 CDN，以后接入一些商用 CDN，当时选择的方式是第三方评分，量化结果，进行排序，最终进入调度系统。

伴随业务的不断发展，第一代系统的准确性和性能不能很好知足需求了，因此设计了一个基于 C 端的 IP 精细调度系统 GSLB v2。

秒拍调度系统的发展之 GSLB v1

GSLB v1 的数据主要来自第三方的监测结果，第三方监测有本身的  API，如播放时间、延时等。来源是请求的地域与运营商，地域就是省、市、区，固然越细越好。

运营商是三大运营商，也有比较大的用户及小运营商。工程师经过API得到第三方数据后，进行综合打分，最后经过用户请求的IP地域，调度到相应节点。

GSLB v1 的结构

以下图，最右边是 Clients，发起客户请求的客户端，如 MiaopaiApp、H五、PC Web、Weibo App 等。

API 部分是对一些友站进行视频的输出，当时主要是新浪，用的是 sina lb、Apache+PHP、同时采用第三方的 monitor 来监测 CDN  节点，记录产生的数据，获取监测结果，并存储到 DB。

以后基于用户发出的请求，读取 IP，分析 IP 对应的城市、运营商等。最后根据对地域和运营商打分的结果，进行调度。

GSLB v1的评分原理

把全国主要城市，包括省会、直辖市以及省市下每一个主流运营商的节点做为监测目标，经过第三方监测机构定时去测试播放。

评分体系主要针对城市+运营商级别作排序，断定原理很简单，就是用户发来 IP，得到城市及运营商数据，根据评分选定节点。

GSLB v1 的优势与不足

优势是总体结构相对简单，维护起来比较容易，水平扩展性强，性能方面也能知足当前需求。

而缺点是测试点数有限，测试时间间隔较长，不能反映及时状况。最重要的是系统在高并发上有瓶颈，如 IP 反查很慢、Apache+PHP  单次请求时间长、受限实体环境，难于及时扩展等。

秒拍调度系统的发展之 GSLB v2

GSLB v2 的核心思想

针对 GSLB v1 的实际应用状况，第二代系统从精准和性能两方面进行考虑。核心思想以下：

• 精细化调度方面，调度粒度细化、积累测试数据和接近实时反馈

• 提高吞吐量方面，作云端迁移，引入 OpenResty 和 IP 快速定位

GSLB v2 的质量评测

想要作好调度系统，首先要有一个好的评价体系，作好质量检测。质量检测工做从最初依靠第三方，到彻底基于客户端，能够及时获取有效信息、节省自身的检测速度和频度，这里建设基于客户端的反馈机制很重要。

质量检测主要是基于 CDN  厂商和节点质量的报告，由于粒度较细，参数方面仍是依赖视频播放。操做员可参考的具体指标，如首播时间、卡顿率、播放成功率，播放完成比例等等。

GSLBv2调度的精细化

• 精准度。GSLB v1 调度是基于 IP，因此精准度取决于 IP 库，常常会出现 IP 判断不许的问题，以及小运营商的出口问题。

• 传统 IP 库现状。传统的 IP 库是经过一些官方数据 IANA(InternetAssigned Numbers  Authority)、渠道收集、网友上报、运营商数据等手段实现。传统运用上，因存在非结构化的数据，会有不少繁杂的信息，给使用者带来不便。

• 纯真 IP 数据库。传统的库是纯真 IP 库，常规结构分为文件头、索引区和记录区三部分。一般查找 IP  时，先在索引区查找记录偏移，而后再到记录区读出信息。

因为记录区的记录长度不定长，因此直接在记录区中搜索是不可能的。另外，由于记录数比较多，遍历索引区会相对较慢。

• 记录自己的复杂性。记录首先是四个字节 IP 地址开始，每条 IP 记录都由国家和地区名组成，国家地区在这里并非太确切。

• 纯真的特色。纯真的核心算法是索引+二分查找，优势是占用内存小，文件体积也小。缺点是数据会愈来愈多，臃肿化会随之严重。

再加上这些庞大的数据仍是非结构化的，致使没法根据一个 IP 直接获取它所在地域和运营商，可能还会出现 1-2 次查找的状况，浪费不少时间。

GSLB v2 对 IP 库进行重建

针对纯真 IP 库的一些缺点，工程师对 IP 库进行了重建，最终能够第一时间找到 IP 对应的运营商和信息。

IP 库重建的解决方向。对数据进行结构化的存储，索引大小固定非增加。这样作是为了减小查找时间，从对数时间转变成常数时间。最好的结果就是 IP  过来，用很简单的方式直接找到对应数据。

IP 库重建的核心算法：

• 一个 C 段只有 256 个 IP，A.B.C.0~A.B.C.255

• 通常一个 C 段 IP 的地理位置，运营商信息都会与之保持一致

• 描述 C 段的全部 IP，只有 256*256*256 = 16777216 个

• 若是一个 IP 对应信息是一个字节，须要储存空间 16M;对应信息是两个字节，须要储存空间 32 M，每一个 C 段 IP 对应一个编码(IPC  码)

• 查询只须要根据偏移直接定位(A*256*256+B*+C)*2

• 信息的前半段描述地区，后半段描述运营商

高效的信息表示方法：

• XXXX XXXXXXXXXXXX

• X 国内/国外，国内 0，国外 1，国外精度到国家

• XX 大区，4 个大区，华北，华中，华南和西部

• X XX 省，区内 8 省

• XX 省内区域，如粤东，粤西，粤北，珠三角

• XXX 区内 8 市

• X X 市内 4 县区

• XXX ISP 区分

校验方式：

• Ipc& 0xF000 是否国外 IP

• Ipc& 0xFC00 得出 IP 省份

• Ipc& 0xFFE0 得出 IP 城市

• Ipc& 0x7 得出运营商

• Ipc - Ipc2 判断两 IP 的距离

GSLB v2 的数据积累

在数据积累方面，当数据缺失时，要主动去探测。探测原则有二：

• 要同区域同 ISP 优先;

• CDN 厂商节点分散化探测。而后，系统对已有的数据进行更新得分操做。

GSLB v2 的评分原则

评分的原则仍是依照一些指标进行，基于首播时间，越短越好，得出基础分;播放卡顿或失败罚分，得分加入时间因子，随时间衰减更新而最终得分。

GSLB v2 的节点选择

以下图，是节点的选择流程。节点选择主要经过首选肯定比较阈值，基于 IPC 码获取同区域不一样节点得分。

若是区域内节点数据知足阈值要求，进行调度。若是节点得分须要更新，则探测新节点。不然向上反馈回溯节点。

GSLB v2 的吞吐量优化

吞吐量方面，数据源使用了 Memcache 和 Redis、纯异步通讯选择 Lua。

以下图，是 GSLB v2 的第一阶段。

调度系统的第一阶段：配置方面包含 1 个 SLB，2 个 gslb server，redis 存储是从主站同步过来的视频状态数据，memcache  存储的是 CDN 播放质量的历史数据。

以下图，是 GSLB v2 的第二阶段。

调度系统的第二阶段：面对播放量成倍增加的状况，对 server 进行了横向扩展。配置方面，增长了多个 SLB 和 gslb server。

以下图，是 GSLB v2 的第三阶段。

调度系统的第三阶段：因为每一个请求都须要对 redis 进行 get 操做获取 channel 的状态数据，致使 redis  性能出现瓶颈。因而，系统替换掉了 redis，把 redis 的存储变为 memcache。

配置方面，增长了多个 SLB 和 gslb server。memcache 存储来自 CDN 播放质量的历史数据，以及从主站同步过来的视频状态数据。因为  openresty 不支持 mc 的 sasl 验证协议，因此没有对 mc 进行横向扩展。

将来展望

目前，秒拍的数据节点还都在北京，后续会调整到包括北京、杭州、广州等全国分区域进行异地多活的部署。

面对云厂商不可依赖，会隐藏不少数据信息，出现问题很差查找源头等状况，秒拍还会考虑混合云的改造。

同时，系统会接入一些基于 P2P 的调度及对自建 CDN 节点的融入、灾备建设和监控统计等方面进行完善。

以上内容根据邓铮老师在 WOTA2017 “高可用架构”专场的演讲内容整理。

邓铮

一下科技高级研发总监，公司创始团队成员

主要负责后端服务总体研发工做，参与了一下科技从创办肇始到成为短视频领域独角兽的全过程。现负责公司研发中心管理工做，他带领后端团队支撑公司每日数十亿以上的  PV，重点支持公司新品研发/大数据部门与预研部门，主要关注高并发/机器学习/智能系统领域。