何以突圍短視頻紅海？秒拍海量播放下的高性能視頻調度實踐

每日處理二十億以上播放請求的大型視頻網站，如何精準高效地將用戶的請求迅速播放，是充滿挑戰的一件事。秒拍在這方面已經積累了豐富的經驗，技術團隊採用細化用戶每次播放請求，並結合近期內綜合調度大數據，實現了在  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、H五、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，重點支持公司新品研發/大數據部門與預研部門，主要關注高併發/機器學習/智能系統領域。