【.com原创文章】对于一个每天处理超过20亿次播放请求的大型视频网站来说，如何准确高效的快速播放用户请求是一项具有挑战性的工作.事物。秒拍在这方面积累了丰富的经验。技术团队通过细化用户的每一次播放请求，结合近期综合调度大数据，实现了C段IP层面的动态调度响应和差异化。本文重点介绍短视频广播所面临的挑战、解决方案，以及调度系统的概念和特点。短视频玩挑战与对策短视频和长视频的区别短视频始于2015年，近两年爆发。与长视频的区别主要有以下四个方面：时长：短视频较短，一般几分钟，而长视频一般在20分钟以上，甚至几个小时。来源：短视频来源广泛，以UGC为主，比较新鲜，长视频以版权为主。更新：短视频更新量大，每天上万条更新；长视频的更新量比较小，每天更新几十条到几百条不等。播放量：短视频平均播放量小，几倍到几十倍不等；长视频的平均播放量从几千到几万不等。短视频播放面临的困难基于短视频的特点，短视频播放面临的挑战包括以下几个方面：由于播放时长，对首播延迟时间非常敏感。相对于几十分钟的长视频，用户可以接受出现的广告。但是加上广告，用户可能有三分之一的时间在等待，体验很差。由于上传源广泛，需要快速分发，所以在推送上会有很大的挑战。更新量大，平均播放量太小，整体内容会比较冷，对如何快速推广到所有观看频道或产生关键行为的节点有很高的要求。从上传到播放结束，应对难点。上传端通过在区域内建立节点进行优化。需要在原站和主要区域建设。比如北京和天津覆盖了整个华北区域，广东覆盖了华南区域，基本保证了每个区域都有最快的上传点。另外，根据实际情况，数据会采用各种传输压缩方式。播放端在技术上采用了CDN分发，然后进行多节点预推操作。调度系统的概念、功能及特点面对海量节点、200多家CDN厂商，核心调度如何选择？如果用户发送请求，如何知道发送给具体公司的哪个节点？这就涉及到调度系统的应用。什么是调度系统？就是接收用户请求，根据分析请求的上下文，对后端所有提供服务的节点进行打分，根据打分结果将用户请求转发给合适的提供服务的后端系统。视频调度主要有以下输入输出：输入用户IP和请求内容逻辑处理可分发的CDN节点。需要知道后端有多少个节点，哪些节点是活跃的，经过打分排序确定节点后，必须实现向对应节点调度系统输出请求的功能：负载均衡，节点故障隔离具有服务异常、后端节点、服务等的健康检查、安全问题的日志记录功能、权限分配功能调度系统特点作为一个日吞吐量20~30亿的站点，调度系统不可能是一个单点，用户来源多且重要。这样，在高吞吐量和高可用性的基础上，技术上需要尽可能地压缩用户等待播放的时间，以提高用户体验，因此需要系统的高性能。秒拍调度系统开发调度系统主要分为GSLBv1和GSLBv2两个版本。秒拍成立之初，日播放量在百万左右。此时的GSLBv1是一个基于第三方打分的区域调度系统，由原站加CDN直接支撑。新浪投资秒拍后，工程师开始使用新浪的CDN，然后接入了一些商业CDN。当时选择的方式是第三方打分，将结果量化，排序，最后进入调度系统。随着业务的不断发展，第一代系统的精度和性能不能很好地满足需求，因此设计了C端IP精细调度系统GSLBv2。秒拍调度系统的开发：GSLBv1GSLBv1的数据主要来源于第三方的监测结果。第三方监控有自己的API，比如播放时间和延时。来源为请求的地区和运营商，地区为省、市、区。当然，越细越好。运营商就是三大运营商，有比较大的用户和小运营商。工程师通过API获取第三方数据后，进行综合打分，最终通过用户请求的IP区域调度到相应的节点。GSLBv1的结构如下图所示。最右边是Clients，发起客户请求的客户端，比如秒拍App、H5、PCWeb、微博App等，API部分是输出视频到一些友站。当时主要是新浪，使用sinalb，Apache+PHP，使用第三方监控器监控CDN节点，记录产生的数据，获取监控结果，存入DB。然后根据用户发送的请求，读取IP，分析IP对应的城市，运营商等。***根据地区和运营商打分结果，进行调度。GSLBv1的评分原则以全国主要城市，包括省会城市、直辖市和各省市主流运营商的节点为监测对象，第三方监测机构定期测试和广播。评分系统主要是根据城市+运营商级别的排名。判断原理很简单，就是用户发送IP，获取城市和运营商数据，根据分数选择节点。GSLBv1的优缺点优点是整体结构比较简单，维护起来比较容易，水平扩展性强，性能可以满足现在的需求。缺点是测试点数有限，测试时间间隔长，不能反映实时情况。最主要的是系统在高并发上存在瓶颈，比如IP反查速度慢、Apache+PHP单次请求时间长、物理环境受限、难以及时扩展等。秒拍调度系统的开发：GSLBv2GSLBv2的核心思想是基于GSLBv1的实际应用。第二代系统兼顾精度和性能。核心思想如下：在细粒度调度方面，细粒度调度，积累测试数据和近实时反馈提高吞吐量，云迁移，引入OpenResty和IP快速定位质量评估GSLBv2要想做好调度系统，首先要有好的评价体系，做好质检。质检工作从最初依靠第三方，转变为完全依靠客户。可以及时获取有效信息，节省自己的巡检速度和频率。在这里建立一个基于客户的反馈机制是非常重要的。质量检测主要是看CDN厂商的报告和节点质量，因为粒度比较细，参数还是靠视频播放。运营商可以参考的具体指标，比如首播时间、卡顿率、播放成功率、播放完成率等。GSLBv2调度的细粒度精度。GSLBv1的调度是基于IP的，所以精度依赖于IP库，对于小运营商来说经常会出现IP判断不准确和导出问题。传统IP库的现状。传统的IP库是通过一些官方数据IANA（InternetAssignedNumbersAuthority）、渠道采集、网民举报、运营商数据等手段实现的。在传统应用中，由于非结构化数据的存在，会出现大量复杂的信息，给用户带来不便。朴素的IP数据库。传统库是纯IP库，其总体结构分为文件头、索引区和记录区三部分。通常在查找IP时，先查找索引区的记录偏移量，然后再读取记录区的信息。由于记录区的记录长度是不确定的，所以不可能直接在记录区中查找。另外，由于记录较多，遍历索引区会比较慢。记录本身的复杂性。记录以一个四字节的IP地址开头，每条IP记录由国家和地区名称组成，国家和地区这里不是很准确。纯粹的性格。纯核心算法是索引+二分查找，优点是内存占用小，文件体积小。缺点是数据会越来越多，臃肿会很严重。另外，这些庞大的数据还是非结构化的，无法直接根据一个IP获取地区和运营商，可能要查找1-2次，浪费了很多时间。GSLBv2重建IP库针对纯IP库存在的一些不足，工程师们重建了IP库，终于可以在第一时间找到IP对应的运营商和信息。IP库重建的解决方案方向。数据结构化存储，索引大小固定不增。这样做是为了将查找时间从对数时间减少到常数时间。最后的结果就是IP过来了，可以很简单的直接找到对应的数据。IP库重构核心算法：一个C段IP只有256个，A.B.C.0~A.B.C.255一般一个C段IP的地理位置，运营商信息都会与之保持一致。描述C段中的所有IP，只有256*256*256=16777216如果一个IP对应的信息是一个字节，需要16M的存储空间；对应的信息是两个字节，需要32M的存储空间。每段CIP对应一个编码（IPC编码），查询只需要根据偏移量直接定位（A*256*256+B**+C)*2信息前半部分描述地区，后半部分描述运营商的高效信息表示方式：XXXXXXXXXXXXXXXXX国内/国外，国内0，国外1，国外精度到XX地区的全国，4个地区，华北、华中、华南和西部XXX省，区内8个省，粤东、粤西、粤北等XX省，珠三角8个市XXX地区XXX4个县区内的4个县区ISP。区分ISP的检查方法：Ipc&0xF000是否是国外IPIpc&0xFC00获取IP所在省份Ipc&0xFFE0获取IP所在城市Ipc&0x7获取运营商Ipc-Ipc2判断两个IP之间的距离GSLBv2数据在数据积累上一方面，当数据丢失时，需要主动检测。检测原则有两条：优先检测同一地区的同一ISP；CDN供应商节点的分散检测。然后，系统对现有数据进行更新评分操作。GSLBv2的评分原则还是基于一些指标。以首播时间为准，越短越好，得出基本分；回放卡顿或失败罚分，分数加时间因子，随着时间衰减更新最终分数。GSLBv2的节点选择如下图所示，为节点选择流程。节点选择主要通过***确定比较阈值，根据IPC码获取同一区域不同节点的得分。如果区域内的节点数据满足阈值要求，则进行调度。如果需要更新节点分数，则探测新节点。否则向上反馈回溯节点。GSLBv2吞吐量优化在吞吐量方面，数据源使用Memcache和Redis，选择Lua进行纯异步通信。如下图所示，是GSLBv2的第一阶段。第一阶段调度系统：配置包括1台SLB，2台gslb服务器，redis存储的是从主站同步过来的视频状态数据，memcache存储的是CDN播放质量的历史数据。下图是GSLBv2的第二阶段。调度系统第二阶段：面对播放量翻倍的情况，对服务器进行了横向扩展。配置方面，增加了多台SLB和gslb服务器。下图是GSLBv2的第三阶段。第三阶段调度系统：由于每次请求都需要对redis进行get操作，获取通道状态数据，导致redis性能瓶颈。因此，系统更换了redis，将redis的存储改为memcache。配置方面，增加了多台SLB和gslb服务器。memcache存储来自CDN的播放质量历史数据，以及从主站同步过来的视频状态数据。由于openresty不支持mc的sasl认证协议，所以mc没有横向扩展。未来展望目前，秒拍的数据节点仍在北京，未来将调整为包括北京、杭州、广州等全国多个分区域，实现异地多活部署。面对不靠谱的云厂商，大量的数据信息会被隐藏，很难找到问题的根源，秒拍也会考虑混合云的转型。同时，系统会接入一些基于P2P的调度，完善自建CDN节点、容灾建设和监控统计的融合。以上内容由王雪艳小编根据邓正老师在WOTA2017“高可用架构”专场的演讲内容整理而成。邓征是技术高级研发总监，公司创始团队成员主要负责后端服务的整体研发，参与了技术从创立到成为行业独角兽的全过程。短视频场。目前负责公司研发中心的管理工作。带领后端团队支撑公司日PV过亿，重点支持公司新品开发/大数据部和预研部，专注于高并发/机器学习/智能系统领域。【原创稿件，合作网站转载请注明原作者和出处为.com】
