【51CTO.com原创稿件】每日处理二十亿以上播放请求的大型视频网站，如何精准高效地将用户的请求迅速播放，是充满挑战的一件事。秒拍在这方面已经积累了丰富的经验，技术团队采用细化用户每次播放请求，并结合近期内综合调度大数据，实现了在 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 节点的融入、灾备建设和监控统计等方面进行完善。
以上内容由编辑王雪燕根据邓铮老师在 WOTA2017 “高可用架构”专场的演讲内容整理。
邓铮
一下科技高级研发总监，公司创始团队成员
主要负责后端服务整体研发工作，参与了一下科技从创办肇始到成为短视频领域独角兽的全过程。现负责公司研发中心管理工作，他带领后端团队支撑公司每日数十亿以上的 PV，重点支持公司新品研发/大数据部门与预研部门，主要关注高并发/机器学习/智能系统领域。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
