[[195584]]

【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 “高可用架構”專場的演講內容整理。

[[195585]]

鄧錚

一下科技高級研發總監，公司創始團隊成員

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

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】