【稿件】每日處理二十億以上播放請求的大型視頻網(wǎng)站，如何精準(zhǔn)高效地將用戶的請求迅速播放，是充滿挑戰(zhàn)的一件事。秒拍在這方面已經(jīng)積累了豐富的經(jīng)驗(yàn)，技術(shù)團(tuán)隊(duì)采用細(xì)化用戶每次播放請求，并結(jié)合近期內(nèi)綜合調(diào)度大數(shù)據(jù)，實(shí)現(xiàn)了在 C 段 IP 級別動態(tài)的調(diào)度響應(yīng)及區(qū)分。

成都創(chuàng)新互聯(lián)公司專注于鐵西企業(yè)網(wǎng)站建設(shè),自適應(yīng)網(wǎng)站建設(shè),商城網(wǎng)站制作。鐵西網(wǎng)站建設(shè)公司,為鐵西等地區(qū)提供建站服務(wù)。全流程按需搭建網(wǎng)站，專業(yè)設(shè)計，全程項(xiàng)目跟蹤，成都創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務(wù)

本文針對短視頻播放面臨的挑戰(zhàn)、應(yīng)對方法以及調(diào)度系統(tǒng)的概念與特點(diǎn)等內(nèi)容進(jìn)行分享。

短視頻播放面臨的挑戰(zhàn)及應(yīng)對方法

短、長視頻之間的區(qū)別

短視頻從 2015 年興起，爆發(fā)也是近兩年的事情。與長視頻的區(qū)別主要有以下四個方面：

• 時長：短視頻時長較短，一般為幾分鐘，長視頻一般為 20 分鐘以上乃至數(shù)小時。
• 來源：短視頻來源廣泛，以 UGC 為主，比較鮮活，長視頻以版權(quán)為主。
• 更新：短視頻更新量很大，每日數(shù)萬條;長視頻更新量比較少，每日數(shù)十條至數(shù)百條不等。
• 播放量：短視頻平均播放量小，數(shù)次至數(shù)十次;長視頻平均播放量在數(shù)千到數(shù)萬級別。

短視頻播放面臨的難點(diǎn)

基于短視頻的特性，短視頻播放面臨的挑戰(zhàn)有以下幾個方面：

• 因播放時長短，所以對首播延時時間很敏感。相比幾十分鐘的長視頻，用戶對出現(xiàn)的廣告還可以接受。但短視頻加廣告，用戶可能三分之一的時間花在等待上，體驗(yàn)度就很差。
• 因上傳來源地區(qū)廣泛，需要快速分發(fā)，這樣在推送上會存在很大挑戰(zhàn)。
• 更新量大，平均播放量太少，所以內(nèi)容整體會偏冷，對如何快速推廣到所有渠道觀看或產(chǎn)生關(guān)鍵行為的節(jié)點(diǎn)，要求較高。

從上傳和播放兩端入手應(yīng)對難點(diǎn)

上傳端通過廣泛建立所在地區(qū)的節(jié)點(diǎn)來優(yōu)化，需要在原站和各大區(qū)都進(jìn)行建設(shè)，如北京、天津覆蓋整個華北地區(qū)，廣東覆蓋華南地區(qū)，基本保證每個區(qū)有最快上傳點(diǎn)。

還有根據(jù)實(shí)際情況，數(shù)據(jù)會采用各種傳輸壓縮方法。對于播放端，技術(shù)上采用 CDN 分發(fā)，然后做多節(jié)點(diǎn)預(yù)推送的操作。

調(diào)度系統(tǒng)的概念、功能及特點(diǎn)

面對節(jié)點(diǎn)繁多超過 200 家 CDN 的廠商，如何選擇核心的調(diào)度?如果用戶發(fā)出請求，如何知道具體派發(fā)到哪一家的哪一個節(jié)點(diǎn)?這就涉及調(diào)度系統(tǒng)的應(yīng)用。

什么是調(diào)度系統(tǒng)?

就是接到用戶請求，基于分析請求的上下文，對后端提供服務(wù)的所有節(jié)點(diǎn)進(jìn)行打分，憑打分結(jié)果把用戶請求轉(zhuǎn)發(fā)給合適的后端提供服務(wù)的系統(tǒng)。

視頻調(diào)度主要有以下幾個輸入輸出：

• 輸入用戶的 IP 和請求內(nèi)容
• 對可分發(fā)的 CDN 節(jié)點(diǎn)進(jìn)行邏輯處理，需要掌握后端有多少節(jié)點(diǎn)，哪些節(jié)點(diǎn)是活的，還要做打分排序
• 確定節(jié)點(diǎn)之后，輸出請求到對應(yīng)的節(jié)點(diǎn)

調(diào)度系統(tǒng)的功能，要實(shí)現(xiàn)：

• 負(fù)載均衡
• 對服務(wù)異常的節(jié)點(diǎn)做故障隔離
• 對后端節(jié)點(diǎn)、服務(wù)等做健康檢查
• 具備日志記錄功能
• 針對安全性問題，有權(quán)限分配功能

調(diào)度系統(tǒng)的特點(diǎn)

作為吞吐量日播放二三十億的站點(diǎn)，調(diào)度系統(tǒng)不可能是一個單點(diǎn)，且用戶來源非常多且重要，這樣在高吞吐、高可用基礎(chǔ)上，技術(shù)上要盡可能壓縮用戶的等待播放時間，來提升用戶體驗(yàn)，所以要求系統(tǒng)高性能。

秒拍調(diào)度系統(tǒng)的發(fā)展

調(diào)度系統(tǒng)主要分為 GSLB v1 和 GSLB v2 兩個版本。在秒拍剛成立時，播放量每天大概近百萬，這時 GSLB v1 是基于第三方評分的地域調(diào)度系統(tǒng)，直接通過原站加 CDN 的方式來支撐。

新浪投資秒拍后，工程師開始使用新浪的 CDN，之后接入一些商用 CDN，當(dāng)時選擇的方式是第三方評分，量化結(jié)果，進(jìn)行排序，最終進(jìn)入調(diào)度系統(tǒng)。

伴隨業(yè)務(wù)的不斷發(fā)展，***代系統(tǒng)的準(zhǔn)確性和性能不能很好滿足需求了，所以設(shè)計了一個基于 C 端的 IP 精細(xì)調(diào)度系統(tǒng) GSLB v2。

秒拍調(diào)度系統(tǒng)的發(fā)展之 GSLB v1

GSLB v1 的數(shù)據(jù)主要來自第三方的監(jiān)測結(jié)果，第三方監(jiān)測有自己的 API，如播放時間、延時等。來源是請求的地域與運(yùn)營商，地域就是省、市、區(qū)，當(dāng)然越細(xì)越好。

運(yùn)營商是三大運(yùn)營商，也有比較大的用戶及小運(yùn)營商。工程師通過API獲得第三方數(shù)據(jù)后，進(jìn)行綜合打分，***通過用戶請求的IP地域，調(diào)度到相應(yīng)節(jié)點(diǎn)。

GSLB v1 的結(jié)構(gòu)

如下圖，最右邊是 Clients，發(fā)起客戶請求的客戶端，如 MiaopaiApp、H5、PC Web、Weibo App 等。

API 部分是對一些友站進(jìn)行視頻的輸出，當(dāng)時主要是新浪，用的是 sina lb、Apache+PHP、同時采用第三方的 monitor 來監(jiān)測 CDN 節(jié)點(diǎn)，記錄產(chǎn)生的數(shù)據(jù)，獲取監(jiān)測結(jié)果，并存儲到 DB。

之后基于用戶發(fā)出的請求，讀取 IP，分析 IP 對應(yīng)的城市、運(yùn)營商等。***根據(jù)對地域和運(yùn)營商打分的結(jié)果，進(jìn)行調(diào)度。

GSLB v1的評分原理

把全國主要城市，包括省會、直轄市以及省市下每個主流運(yùn)營商的節(jié)點(diǎn)作為監(jiān)測目標(biāo)，通過第三方監(jiān)測機(jī)構(gòu)定時去測試播放。

評分體系主要針對城市+運(yùn)營商級別做排序，判定原理很簡單，就是用戶發(fā)來 IP，獲得城市及運(yùn)營商數(shù)據(jù)，根據(jù)評分選定節(jié)點(diǎn)。

GSLB v1 的優(yōu)點(diǎn)與不足

優(yōu)點(diǎn)是整體結(jié)構(gòu)相對簡單，維護(hù)起來比較容易，水平擴(kuò)展性強(qiáng)，性能方面也能滿足當(dāng)前需求。

而缺點(diǎn)是測試點(diǎn)數(shù)有限，測試時間間隔較長，不能反映及時情況。最重要的是系統(tǒng)在高并發(fā)上有瓶頸，如 IP 反查很慢、Apache+PHP 單次請求時間長、受限實(shí)體環(huán)境，難于及時擴(kuò)展等。

秒拍調(diào)度系統(tǒng)的發(fā)展之 GSLB v2

GSLB v2 的核心思想

針對 GSLB v1 的實(shí)際應(yīng)用情況，第二代系統(tǒng)從精準(zhǔn)和性能兩方面進(jìn)行考慮。核心思想如下：

• 精細(xì)化調(diào)度方面，調(diào)度粒度細(xì)化、積累測試數(shù)據(jù)和接近實(shí)時反饋
• 提升吞吐量方面，做云端遷移，引入 OpenResty 和 IP 快速定位

GSLB v2 的質(zhì)量評測

想要做好調(diào)度系統(tǒng)，首先要有一個好的評價體系，做好質(zhì)量檢測。質(zhì)量檢測工作從最初依靠第三方，到完全基于客戶端，可以及時獲取有效信息、節(jié)省自身的檢測速度和頻度，這里建設(shè)基于客戶端的反饋機(jī)制很重要。

質(zhì)量檢測主要是基于 CDN 廠商和節(jié)點(diǎn)質(zhì)量的報告，因?yàn)榱６容^細(xì)，參數(shù)方面還是依賴視頻播放。操作員可參考的具體指標(biāo)，如首播時間、卡頓率、播放成功率，播放完成比例等等。

GSLBv2調(diào)度的精細(xì)化

• 精準(zhǔn)度。GSLB v1 調(diào)度是基于 IP，所以精準(zhǔn)度取決于 IP 庫，經(jīng)常會出現(xiàn) IP 判斷不準(zhǔn)的問題，以及小運(yùn)營商的出口問題。

 

• 傳統(tǒng) IP 庫現(xiàn)狀。傳統(tǒng)的 IP 庫是通過一些官方數(shù)據(jù) IANA(InternetAssigned Numbers Authority)、渠道收集、網(wǎng)友上報、運(yùn)營商數(shù)據(jù)等手段實(shí)現(xiàn)。傳統(tǒng)運(yùn)用上，因存在非結(jié)構(gòu)化的數(shù)據(jù)，會有很多繁雜的信息，給使用者帶來不便。
• 純真 IP 數(shù)據(jù)庫。傳統(tǒng)的庫是純真 IP 庫，常規(guī)結(jié)構(gòu)分為文件頭、索引區(qū)和記錄區(qū)三部分。通常查找 IP 時，先在索引區(qū)查找記錄偏移，然后再到記錄區(qū)讀出信息。

由于記錄區(qū)的記錄長度不定長，所以直接在記錄區(qū)中搜索是不可能的。另外，因?yàn)橛涗洈?shù)比較多，遍歷索引區(qū)會相對較慢。

• 記錄本身的復(fù)雜性。記錄首先是四個字節(jié) IP 地址開始，每條 IP 記錄都由國家和地區(qū)名組成，國家地區(qū)在這里并不是太確切。
• 純真的特點(diǎn)。純真的核心算法是索引+二分查找，優(yōu)點(diǎn)是占用內(nèi)存小，文件體積也小。缺點(diǎn)是數(shù)據(jù)會越來越多，臃腫化會隨之嚴(yán)重。

再加上這些龐大的數(shù)據(jù)還是非結(jié)構(gòu)化的，導(dǎo)致無法根據(jù)一個 IP 直接獲取它所在地域和運(yùn)營商，可能還會出現(xiàn) 1-2 次查找的情況，浪費(fèi)很多時間。

GSLB v2 對 IP 庫進(jìn)行重建

針對純真 IP 庫的一些缺點(diǎn)，工程師對 IP 庫進(jìn)行了重建，最終可以***時間找到 IP 對應(yīng)的運(yùn)營商和信息。

IP 庫重建的解決方向。對數(shù)據(jù)進(jìn)行結(jié)構(gòu)化的存儲，索引大小固定非增長。這樣做是為了減少查找時間，從對數(shù)時間轉(zhuǎn)變成常數(shù)時間。***的結(jié)果就是 IP 過來，用很簡單的方式直接找到對應(yīng)數(shù)據(jù)。

IP 庫重建的核心算法：

• 一個 C 段只有 256 個 IP，A.B.C.0~A.B.C.255
• 一般一個 C 段 IP 的地理位置，運(yùn)營商信息都會與之保持一致
• 描述 C 段的所有 IP，只有 256*256*256 = 16777216 個
• 如果一個 IP 對應(yīng)信息是一個字節(jié)，需要儲存空間 16M;對應(yīng)信息是兩個字節(jié)，需要儲存空間 32 M，每個 C 段 IP 對應(yīng)一個編碼(IPC 碼)
• 查詢只需要根據(jù)偏移直接定位(A*256*256+B*+C)*2
• 信息的前半段描述地區(qū)，后半段描述運(yùn)營商

高效的信息表示方法：

• XXXX XXXXXXXXXXXX
• X 國內(nèi)/國外，國內(nèi) 0，國外 1，國外精度到國家
• XX 大區(qū)，4 個大區(qū)，華北，華中，華南和西部
• X XX 省，區(qū)內(nèi) 8 省
• XX 省內(nèi)區(qū)域，如粵東，粵西，粵北，珠三角
• XXX 區(qū)內(nèi) 8 市
• X X 市內(nèi) 4 縣區(qū)
• XXX ISP 區(qū)分

校驗(yàn)方式：

• Ipc& 0xF000 是否國外 IP
• Ipc& 0xFC00 得出 IP 省份
• Ipc& 0xFFE0 得出 IP 城市
• Ipc& 0x7 得出運(yùn)營商
• Ipc - Ipc2 判斷兩 IP 的距離

GSLB v2 的數(shù)據(jù)積累

在數(shù)據(jù)積累方面，當(dāng)數(shù)據(jù)缺失時，要主動去探測。探測原則有二：

• 要同區(qū)域同 ISP 優(yōu)先;
• CDN 廠商節(jié)點(diǎn)分散化探測。然后，系統(tǒng)對已有的數(shù)據(jù)進(jìn)行更新得分操作。

GSLB v2 的評分原則

評分的原則還是依照一些指標(biāo)進(jìn)行，基于首播時間，越短越好，得出基礎(chǔ)分;播放卡頓或失敗罰分，得分加入時間因子，隨時間衰減更新而最終得分。

GSLB v2 的節(jié)點(diǎn)選擇

如下圖，是節(jié)點(diǎn)的選擇流程。節(jié)點(diǎn)選擇主要通過***確定比較閾值，基于 IPC 碼獲取同區(qū)域不同節(jié)點(diǎn)得分。

如果區(qū)域內(nèi)節(jié)點(diǎn)數(shù)據(jù)滿足閾值要求，進(jìn)行調(diào)度。如果節(jié)點(diǎn)得分需要更新，則探測新節(jié)點(diǎn)。否則向上反饋回溯節(jié)點(diǎn)。

GSLB v2 的吞吐量優(yōu)化

吞吐量方面，數(shù)據(jù)源使用了 Memcache 和 Redis、純異步通信選擇 Lua。

如下圖，是 GSLB v2 的***階段。

調(diào)度系統(tǒng)的***階段：配置方面包含 1 個 SLB，2 個 gslb server，redis 存儲是從主站同步過來的視頻狀態(tài)數(shù)據(jù)，memcache 存儲的是 CDN 播放質(zhì)量的歷史數(shù)據(jù)。

如下圖，是 GSLB v2 的第二階段。

調(diào)度系統(tǒng)的第二階段：面對播放量成倍增長的情況，對 server 進(jìn)行了橫向擴(kuò)展。配置方面，增加了多個 SLB 和 gslb server。

如下圖，是 GSLB v2 的第三階段。

調(diào)度系統(tǒng)的第三階段：由于每個請求都需要對 redis 進(jìn)行 get 操作獲取 channel 的狀態(tài)數(shù)據(jù)，導(dǎo)致 redis 性能出現(xiàn)瓶頸。于是，系統(tǒng)替換掉了 redis，把 redis 的存儲變?yōu)?memcache。

配置方面，增加了多個 SLB 和 gslb server。memcache 存儲來自 CDN 播放質(zhì)量的歷史數(shù)據(jù)，以及從主站同步過來的視頻狀態(tài)數(shù)據(jù)。由于 openresty 不支持 mc 的 sasl 驗(yàn)證協(xié)議，所以沒有對 mc 進(jìn)行橫向擴(kuò)展。

未來展望

目前，秒拍的數(shù)據(jù)節(jié)點(diǎn)還都在北京，后續(xù)會調(diào)整到包括北京、杭州、廣州等全國分區(qū)域進(jìn)行異地多活的部署。

面對云廠商不可依賴，會隱藏很多數(shù)據(jù)信息，出現(xiàn)問題不好查找源頭等情況，秒拍還會考慮混合云的改造。

同時，系統(tǒng)會接入一些基于 P2P 的調(diào)度及對自建 CDN 節(jié)點(diǎn)的融入、災(zāi)備建設(shè)和監(jiān)控統(tǒng)計等方面進(jìn)行完善。

以上內(nèi)容由編輯王雪燕根據(jù)鄧錚老師在 WOTA2017 “高可用架構(gòu)”專場的演講內(nèi)容整理。

鄧錚

一下科技高級研發(fā)總監(jiān)，公司創(chuàng)始團(tuán)隊(duì)成員

主要負(fù)責(zé)后端服務(wù)整體研發(fā)工作，參與了一下科技從創(chuàng)辦肇始到成為短視頻領(lǐng)域獨(dú)角獸的全過程?，F(xiàn)負(fù)責(zé)公司研發(fā)中心管理工作，他帶領(lǐng)后端團(tuán)隊(duì)支撐公司每日數(shù)十億以上的 PV，重點(diǎn)支持公司新品研發(fā)/大數(shù)據(jù)部門與預(yù)研部門，主要關(guān)注高并發(fā)/機(jī)器學(xué)習(xí)/智能系統(tǒng)領(lǐng)域。

標(biāo)題名稱：何以突圍短視頻紅海？秒拍海量播放下的高性能視頻調(diào)度實(shí)踐
瀏覽路徑：http://uogjgqi.cn/article/dpeisjc.html