[[195584]]

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

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

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

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

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

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

短視頻播放面臨的難點

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GSLB v1的評分原理

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

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

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

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

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

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

GSLB v2 的核心思想

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

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

GSLB v2 的質(zhì)量評測

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

質(zhì)量檢測主要是基于 CDN 廠商和節(jié)點質(zhì)量的報告，因為粒度較細，參數(shù)方面還是依賴視頻播放。操作員可參考的具體指標，如首播時間、卡頓率、播放成功率，播放完成比例等等。

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

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

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

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

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

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

GSLB v2 對 IP 庫進行重建

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

IP 庫重建的解決方向。對數(shù)據(jù)進行結(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 的地理位置，運營商信息都會與之保持一致
• 描述 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ū)，后半段描述運營商

高效的信息表示方法：

• 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ū)分

校驗方式：

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

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

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

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

GSLB v2 的評分原則

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

GSLB v2 的節(jié)點選擇

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

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

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 進行了橫向擴展。配置方面，增加了多個 SLB 和 gslb server。

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

調(diào)度系統(tǒng)的第三階段：由于每個請求都需要對 redis 進行 get 操作獲取 channel 的狀態(tài)數(shù)據(jù)，導致 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 驗證協(xié)議，所以沒有對 mc 進行橫向擴展。

未來展望

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

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

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

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

[[195585]]

鄧錚

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

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

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】