为每日需要处理二十亿以上播放请求的大型视频网站，如何精准高效的将用户的每次请求迅速的真正实现播放，是充满挑战的一件事。秒拍在这方面积累了丰富的经验，我们采用细化用户每次播放请求的上下文，并结合近期内综合调度大数据，动态的实现了在c段IP级别的调度响应及区分，在具体的实践中也取得了比较好的效果。

每日处理二十亿以上播放请求的大型视频网站，如何精准高效地将用户的请求迅速播放，是充满挑战的一件事。秒拍在这方面已经积累了丰富的经验，技术团队采用细化用户每次播放请求，并结合近期内综合调度大数据，实现了在 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、H5、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 节点的融入、灾备建设和监控统计等方面进行完善。