大數(shù)據(jù)驅(qū)動(dòng)下的快手直播系統(tǒng)優(yōu)化案例

寫在前面 ?

大家下午好，我是羅喆，來自快手，過去的一年多我在快手做直播的體驗(yàn)優(yōu)化相關(guān)的工作。今天給大家分享的主題是快手如何在大數(shù)據(jù)的驅(qū)動(dòng)下來優(yōu)化直播的質(zhì)量。

加入公司這一年多，公司的注冊(cè)用戶和日活每天都刷新峰值，到現(xiàn)在，快手的注冊(cè)用戶已經(jīng)超過 5 億，短視頻數(shù)量已經(jīng)超過了 int32 所能存儲(chǔ)的數(shù)字的上限，也就是 21 個(gè)億，日活躍用戶數(shù)也已經(jīng)達(dá)到 6500 萬，而且還處于高速增長的趨勢(shì)之中。

快手的直播業(yè)務(wù) 2016 年初上線，我們的直播業(yè)務(wù)和別的直播平臺(tái)很不一樣，那就是快手的直播是面向普通人的直播，而不是只有網(wǎng)紅大 V；快手的直播內(nèi)容，也大多是常見的生活場(chǎng)景，非常多樣化，這樣的模式也決定了快手直播需要考慮的業(yè)務(wù)場(chǎng)景更復(fù)雜。

目前，快手的直播業(yè)務(wù)量迅速增長，單個(gè)直播間的觀看人數(shù)峰值，最高時(shí)超過了百萬人。（8 月 7 日，在用戶“MC 天佑”的直播中，快手單個(gè)直播間同時(shí)在線人數(shù)最高超過了 180 萬。）那么，我們是如何在龐大的用戶基數(shù)下保證直播的流暢度呢？我將從四個(gè)方面進(jìn)行解析。

快手直播面臨的挑戰(zhàn)與解決方案 ?

?快手直播的特點(diǎn)和挑戰(zhàn)

快手直播有四個(gè)顯著的特點(diǎn)，這些特點(diǎn)給快手帶來了機(jī)遇，也讓我們面臨著巨大的挑戰(zhàn)：

數(shù)據(jù)驅(qū)動(dòng)的優(yōu)化方法論

針對(duì)線上紛繁復(fù)雜的直播體驗(yàn)問題，快手視頻團(tuán)隊(duì)在實(shí)踐過程中總結(jié)出了一套數(shù)據(jù)驅(qū)動(dòng)的優(yōu)化方法論，歸納一下有三點(diǎn)：

首先是區(qū)分痛點(diǎn)，設(shè)置優(yōu)先級(jí)。把問題分為兩類：可以忍受和不能忍受，不能忍受的諸如播放失敗、綠屏和黑屏等，這種影響功能可用性的問題定位高優(yōu)先級(jí)，快速處理；可以忍受的包括卡頓、清晰度、延時(shí)等能看但用戶體驗(yàn)不好的設(shè)置普通優(yōu)先級(jí)，持續(xù)優(yōu)化。

其次是制定優(yōu)化方案，問題出現(xiàn)后，定制一個(gè)合理的優(yōu)化方案，這里可能涉及到多方，有快手需要解決的問題，也有 CDN 服務(wù)商需要解決的問題，需要合理的排期保證問題有序解決。

第三步是灰度驗(yàn)證或 AB 測(cè)試，解決問題之后通過觀測(cè)全網(wǎng)的數(shù)據(jù)進(jìn)行灰度驗(yàn)證，確保方案是真正有效了之后，才全量上線。

快手直播全鏈路質(zhì)量監(jiān)控

這套方法論的基礎(chǔ)是數(shù)據(jù)，那么，快手直播到底用到哪些數(shù)據(jù)，怎么判斷用戶的播放體驗(yàn)是否 OK 呢？下面先介紹一下快手的直播系統(tǒng)端到端的處理流程：視音頻信號(hào)實(shí)時(shí)采集，經(jīng)過預(yù)處理和音視頻編碼，封裝發(fā)送到 CDN 源站，播放端從 CDN 邊緣拉到數(shù)據(jù)，然后進(jìn)行解碼，經(jīng)過音視頻同步之后，給觀眾展現(xiàn)出來。

我們?cè)谕屏鞫撕筒シ哦朔謩e做了非常完善的質(zhì)量監(jiān)測(cè)體系。在推流端，數(shù)據(jù)的源頭是攝像頭采集到的畫面和麥克風(fēng)采集到的聲音，不同的機(jī)型和系統(tǒng)，攝像頭和麥克風(fēng)的能力完全不同，所以我們首先對(duì)攝像頭的分辨率、幀率、機(jī)型等關(guān)鍵信息進(jìn)行收集；

接下來是視頻前處理的過程，比如去噪、美顏、特效等，這些都是非常耗 CPU 和內(nèi)存資源的操作，所以這個(gè)環(huán)節(jié)對(duì) CPU 和內(nèi)存的占用做了詳細(xì)的上報(bào)；前處理之后會(huì)進(jìn)行視頻編碼，視頻編碼的質(zhì)量影響整個(gè)視頻的觀看體驗(yàn)，對(duì)視頻編碼器，主要是上報(bào)了視頻編碼的客觀質(zhì)量和編碼器的輸出幀率；音頻數(shù)據(jù)的采集編碼過程和視頻類似；

編碼完成之后的數(shù)據(jù)會(huì)進(jìn)行協(xié)議封裝，然后進(jìn)入碼率自適應(yīng)模塊，碼率自適應(yīng)模塊的功能主要是調(diào)整輸出碼率以適應(yīng)用戶的網(wǎng)絡(luò)帶寬，在用戶網(wǎng)絡(luò)變差的時(shí)候，自適應(yīng)模塊會(huì)主動(dòng)丟棄一些數(shù)據(jù)以降低對(duì)網(wǎng)絡(luò)的壓力，推流端的卡頓也主要是發(fā)生在這里，所以在這里對(duì)自適應(yīng)模塊的輸出碼率，丟幀數(shù)量，卡頓次數(shù)都做了詳盡的統(tǒng)計(jì)；數(shù)據(jù)最后到達(dá)到 CDN 服務(wù)商的源站，CDN 服務(wù)商分配的源站節(jié)點(diǎn)是否合理，是否和用戶在同一地域，同一運(yùn)營商，都直接影響到用戶的連接質(zhì)量，所以源站節(jié)點(diǎn)的地理位置和運(yùn)營商信息，也是對(duì)質(zhì)量評(píng)價(jià)非常重要的信息。

我們?cè)賮砜纯蠢鳎úシ牛┒?，拉流端整體的流程和推流端是一個(gè)反過來的流程，客戶端先經(jīng)過 DNS 解析，連接到 CDN 的邊緣節(jié)點(diǎn)，和推流端類似，需要對(duì) DNS 解析時(shí)間，邊緣節(jié)點(diǎn)的運(yùn)營商、地理位置、RTT 值等關(guān)鍵信息進(jìn)行采集；從 CDN 邊緣節(jié)點(diǎn)拿到的 http-flv 數(shù)據(jù)會(huì)先經(jīng)過解封裝送到接收緩沖區(qū)，在這個(gè)階段可以對(duì) CDN 服務(wù)節(jié)點(diǎn)的首包時(shí)間，發(fā)送至接收的端到端延時(shí)進(jìn)行統(tǒng)計(jì)；接收緩沖區(qū)的長度決定了拉流端的網(wǎng)絡(luò)抗性，這里可以采集到卡頓的次數(shù)和時(shí)長，緩沖區(qū)本身的長度也是需要監(jiān)控的點(diǎn)；數(shù)據(jù)從緩沖區(qū)的輸出，會(huì)分別進(jìn)行音頻和視頻的解碼，經(jīng)過音視頻同步，進(jìn)入播放環(huán)節(jié)。這里從拉流啟動(dòng)到播放出第一幀畫面的時(shí)間就是首幀時(shí)間。

這些復(fù)雜的過程在用戶點(diǎn)擊一個(gè)直播之后，絕大部分情況下在幾百毫秒以內(nèi)就會(huì)完成，我們也進(jìn)一步分解了首幀各個(gè)環(huán)節(jié)的時(shí)間，能夠?qū)λM(jìn)行深入的分析和優(yōu)化。

直播質(zhì)量數(shù)據(jù)處理 Pipeline

在提取了詳細(xì)的質(zhì)量數(shù)據(jù)之后，接下來就是后端處理的事情了，我將從直播質(zhì)量數(shù)據(jù)處理 Pipeline、用戶體驗(yàn)質(zhì)量數(shù)據(jù) & 服務(wù)質(zhì)量數(shù)據(jù)、數(shù)據(jù)可視化監(jiān)測(cè)流程三個(gè)角度為大家全面解析快手是如何發(fā)現(xiàn)直播當(dāng)中的問題，以及是如何解決的。

直播質(zhì)量數(shù)據(jù)處理流程

下圖是快手現(xiàn)在所使用的直播數(shù)據(jù)處理 Pipeline，可以很清晰的看到整個(gè)流程為數(shù)據(jù)采集→數(shù)據(jù)緩存→數(shù)據(jù)分類處理→數(shù)據(jù)索引 / 展示。

我們具體看看這個(gè)流程的工作細(xì)節(jié)，數(shù)據(jù)從快手 APP 收集，然后經(jīng)過上報(bào)服務(wù)器的簡(jiǎn)單處理之后，會(huì)存到 Kafka 的 Topic 里面，Kafka 是非?？煽康臄?shù)據(jù)隊(duì)列服務(wù)，只要 Kafka 的機(jī)群夠多，即使部分機(jī)器宕了數(shù)據(jù)都不會(huì)丟的；接下來，Kafka 的數(shù)據(jù)會(huì)分出兩條處理路徑：

快手每天經(jīng)過這個(gè)系統(tǒng)處理的直播相關(guān)的數(shù)據(jù)，在百億條的量級(jí)，直播相關(guān)的所有的數(shù)據(jù)展示和監(jiān)控都依賴于這整個(gè) Pipeline，要在分鐘級(jí)要求下，支持各種業(yè)務(wù)查詢需求，保證系統(tǒng)的平穩(wěn)運(yùn)行，是很不容易的。

用戶體驗(yàn)質(zhì)量 & 服務(wù)質(zhì)量

采集到了數(shù)據(jù)并且對(duì)數(shù)據(jù)進(jìn)行清洗入庫之后，怎么去分析數(shù)據(jù)呢？首先，我們把數(shù)據(jù)可視化的監(jiān)測(cè)分為兩類，一類是用戶體驗(yàn)質(zhì)量（QoE，Quality of Experience），我們把它定義為一種和用戶主觀感受相關(guān)的數(shù)據(jù)，如同時(shí)直播房間數(shù)、直播同時(shí)在線人數(shù)、直播跳出率等，這些數(shù)據(jù)的波動(dòng)有可能是技術(shù)問題導(dǎo)致的，也有可能是因?yàn)橹辈?nèi)容不符合觀眾預(yù)期，可以綜合反映出用戶對(duì)直播體驗(yàn)的主觀感受。并且，這幾項(xiàng)用戶體驗(yàn)指標(biāo)反映的是整體的趨勢(shì)，如果真的出現(xiàn)技術(shù)性的問題，靠這些指標(biāo)是無法追蹤問題的源頭的。

舉例來說，如果我們發(fā)現(xiàn)直播同時(shí)在線觀看的人數(shù)降了，但這只能說明有問題，具體問題在哪里，什么原因?qū)е碌男枰ㄟ^第二類指標(biāo)：服務(wù)質(zhì)量（QoS， Quality of Service）數(shù)據(jù)來進(jìn)一步分析。服務(wù)質(zhì)量數(shù)據(jù)是純客觀的，反映的是技術(shù)性的指標(biāo)，比如這張示意圖，是一個(gè)以時(shí)間維度的各 CDN 服務(wù)商的卡頓率曲線；QoE 指標(biāo)的波動(dòng)未必一定是 QoS 的數(shù)據(jù)波動(dòng)導(dǎo)致的，QoS 的數(shù)據(jù)波動(dòng)也不是一定會(huì)導(dǎo)致 QoE 數(shù)據(jù)的變化，比如卡頓率可能會(huì)上升，但是在可接受的范圍內(nèi)，同時(shí)在線人數(shù)不一定會(huì)有大的變化。

數(shù)據(jù)可視化監(jiān)測(cè)流程

我們以下圖的“進(jìn)入房間人數(shù)”和“退出房間人數(shù)”分析，說明一下我們是怎么做聯(lián)合 QoE 數(shù)據(jù)和 QoS 數(shù)據(jù)進(jìn)行監(jiān)測(cè)和分析的。首先看看 QoE 數(shù)據(jù)，左上角是快手某次直播房間的同時(shí)在線人數(shù)曲線，在直播過程中在線人數(shù)有一個(gè)“掉坑”的現(xiàn)象，右下角的“退出房間人數(shù)”曲線顯示在九點(diǎn)三十多分有一個(gè)峰值，說明有大量用戶退出房間，我們推測(cè)這里可能發(fā)生了某些問題導(dǎo)致了觀看人數(shù)的大量減少，有可能是非技術(shù)性的，比如主播做了一件事情觀眾們不太喜歡，會(huì)導(dǎo)致觀眾大量流失。奇怪的是，右上角的“進(jìn)入房間人數(shù)”曲線顯示，進(jìn)入房間在同樣時(shí)刻也有一個(gè)峰值，這個(gè)時(shí)候說明雖然有大量用戶退出了房間，但是同時(shí)也大量的進(jìn)入了該房間。這里我們可以通過 QoE 數(shù)據(jù)得出一些結(jié)論，這一次觀眾大量退出，應(yīng)該不是由于直播內(nèi)容導(dǎo)致的，而是快手的直播服務(wù)有問題導(dǎo)致的，因?yàn)橛^眾大量退出同時(shí)也大量進(jìn)入，是因?yàn)橛^眾覺得重新打開直播可能可以解決問題，退出直播并不是因?yàn)樗麄儾辉傧肟催@個(gè)直播了 。

為了證實(shí)這個(gè)判斷，我們觀測(cè) QoS 數(shù)據(jù)曲線。圖上兩條曲線是所有 CDN 節(jié)點(diǎn)進(jìn)入房間人數(shù)曲線和退出房間曲線，可以看到在用戶大量退出的時(shí)候，基本上各個(gè) CDN 節(jié)點(diǎn)都會(huì)有大量的退出和進(jìn)入，而不是只有少數(shù)節(jié)點(diǎn)才有這個(gè)行為，這樣就可以進(jìn)一步判斷應(yīng)該不是個(gè)別拉流節(jié)點(diǎn)的問題的問題，極有可能是主播推流發(fā)生了問題。之后我們聯(lián)合 CDN 把主播的錄像和推流曲線拿到之后，基本上可以斷定主播當(dāng)時(shí)的網(wǎng)絡(luò)發(fā)生了抖動(dòng)，導(dǎo)致短暫的卡頓，之后又立刻恢復(fù)，短暫的卡頓導(dǎo)致觀眾大量退出直播間。

從這個(gè)例子我們可以看出 QoE 的指標(biāo)是一個(gè)綜合衡量指標(biāo)，它很直觀，雖然并不能直接對(duì)應(yīng)到 QoS 服務(wù)質(zhì)量指標(biāo)，但我們可以通過它來全局監(jiān)控，判斷是技術(shù)還是內(nèi)容原因出現(xiàn)了體驗(yàn)問題，如果是技術(shù)原因，我們?cè)偃ピ敿?xì)的查看 QoS 指標(biāo)的時(shí)候就可以查出問題的根源。

直播系統(tǒng)優(yōu)化案例

接下來，我將通過開播跳幀優(yōu)化和 httpDNS 首屏優(yōu)化兩個(gè)例子，以實(shí)例說明如何利用大數(shù)據(jù)做直播系統(tǒng)調(diào)優(yōu)。

拉流端開播的過程

拉流端開播的過程，如前面所述，主要是連接 CDN 節(jié)點(diǎn)拉取數(shù)據(jù)，數(shù)據(jù)的解碼、渲染這幾個(gè)步驟。CDN 的邊緣節(jié)點(diǎn)一般都會(huì)緩存一部分?jǐn)?shù)據(jù)，便于拉流端在任何時(shí)刻開始拉流都能拉到數(shù)據(jù)。為了讓用戶盡可能的播放流暢，CDN 會(huì)盡量的向用戶多發(fā)一些數(shù)據(jù)，有時(shí)候甚至超過播放端拉流的緩沖區(qū)，超過的這部分?jǐn)?shù)據(jù)會(huì)造成的顯著問題是，如果照單全收并且按照正常的速度播，會(huì)導(dǎo)致直播延時(shí)增大，互動(dòng)效果變差。業(yè)界公認(rèn)的互動(dòng)直播延時(shí)標(biāo)準(zhǔn)是小于 5 秒鐘，超過 5 秒評(píng)論禮物互動(dòng)效果就會(huì)變差。因此我們需要在保證延遲的前提下，盡量縮短首屏，提高流暢度。

如上圖，拉流端接收緩沖區(qū)長度一般等同于延時(shí)，我們把它的長度設(shè)置為 5s，如果 CDN 下發(fā)的數(shù)據(jù)大于了接收緩沖區(qū)的長度，假設(shè)超過的部分是 4 秒，那么如果不做任何處理，正常播放的延時(shí)是 5 秒加 4 秒等于 9 秒，9 秒的延時(shí)在直播過程中基本上沒辦法做評(píng)論或者交互，體驗(yàn)很差。于是我們一開始嘗試從客戶端來單獨(dú)解決這超出的部分?jǐn)?shù)據(jù)導(dǎo)致的問題。

我們嘗試了兩種的解決辦法：直接快進(jìn)和跳幀，直接快進(jìn)的方案就是將超過的部分?jǐn)?shù)據(jù)快速的播放過去，視頻和聲音都被加速播放了，這個(gè)方案上線之后很快就收到了用戶的投訴，懷疑快手的直播是假直播，真正的直播怎么會(huì)出現(xiàn)“快進(jìn)”的現(xiàn)象；然后我們修改了方案，將超出的部分?jǐn)?shù)據(jù)直接跳過不進(jìn)行播放，但是這又帶來了新的問題，直接跳幀會(huì)導(dǎo)致用戶的聲音和畫面出現(xiàn)突變，主播可能從畫面的左邊突然出現(xiàn)在畫面的右邊，體驗(yàn)也不是很好?？傊辉诳蛻舳俗鰞?yōu)化無法做到體驗(yàn)的最優(yōu)。

開播跳幀優(yōu)化

由于導(dǎo)致這個(gè)問題的真正原因是 CDN 下發(fā)數(shù)據(jù)過多導(dǎo)致的，為了做到最優(yōu)的體驗(yàn)，必須和 CDN 聯(lián)合優(yōu)化。這時(shí)，快手的多 CDN 策略帶來一個(gè)新的問題：各家 CDN 開播下發(fā)數(shù)據(jù)的策略完全不同， 在開播時(shí)下發(fā)的數(shù)據(jù)長度都不一樣，很難定量的評(píng)價(jià)哪一家 CDN 做的更好一些。

于是制定統(tǒng)一的評(píng)價(jià)標(biāo)準(zhǔn)成為第一個(gè)要解決問題，這里快手使用“開播前 10 秒跳幀時(shí)長”作為衡量 CDN 下發(fā)數(shù)據(jù)長度的標(biāo)準(zhǔn)，具體是指拉流端播放的前 10 秒內(nèi)丟棄數(shù)據(jù)的總時(shí)長。

在制定統(tǒng)一的評(píng)價(jià)標(biāo)準(zhǔn)之后，通過線上數(shù)據(jù)觀察各家 CDN 的跳幀指標(biāo)，嘗試讓各 CDN 優(yōu)化自己的指標(biāo)，盡量接近最優(yōu)的那一家。但是由于各 CDN 的開播策略都大不相同，可配置參數(shù)也完全不一樣，不同的 CDN 之間很難做到數(shù)據(jù)完全一致。而且即使是指標(biāo)最優(yōu)的 CDN 也無法將開播前 10s 調(diào)整時(shí)長調(diào)整到讓快手滿意的程度。于是，統(tǒng)一各家 CDN 開播數(shù)據(jù)下發(fā)策略成為第二個(gè)要解決的重要問題。

我們?cè)O(shè)計(jì)了一套統(tǒng)一的開播數(shù)據(jù)下發(fā)策略，讓各家 CDN 都按照這個(gè)方案來實(shí)現(xiàn)。該方案總的來說遵循三個(gè)原則：1. 下發(fā)數(shù)據(jù)長度不能超過快手拉流端接受緩沖區(qū)長度 2. 必須從一個(gè) GOP（Group of Pictures）的開始下發(fā) 3. 在不違背前面兩點(diǎn)的情況下，下發(fā)盡可能多的數(shù)據(jù)。上圖是兩個(gè)根據(jù)服務(wù)端緩存的不同 GOP 結(jié)構(gòu)，決定下發(fā)數(shù)據(jù)策略的實(shí)際 case，假設(shè)快手拉流端接收緩沖區(qū)長度是 5 秒：

制定了統(tǒng)一的開播數(shù)據(jù)下發(fā)策略之后，在多家 CDN 分別上線灰度，對(duì)比觀察各家 CDN 覆蓋節(jié)點(diǎn)和未覆蓋節(jié)點(diǎn)的數(shù)據(jù)，然后逐步擴(kuò)大灰度范圍直至全量上線。對(duì)比優(yōu)化前的日均值，開播前 10s 跳幀時(shí)長從 1500ms 降低至 200ms。

經(jīng)過上一輪的 CDN 端優(yōu)化之后，觀察全網(wǎng)的開播跳幀數(shù)據(jù)，各家 CDN 的指標(biāo)保持在相同的水平（開播 10 秒平均跳幀 200ms 左右），基本可以判斷 CDN 端的優(yōu)化已經(jīng)到了瓶頸，客戶端能否進(jìn)一步優(yōu)化解決掉最后的 200ms 呢？這里快手使用了緩慢快進(jìn)的方案：將多余的 200ms 在用戶無感知的情況下，進(jìn)行加速播放，控制緩沖區(qū)的大小。只要將加速程度控制在一定范圍內(nèi)，用戶基本是沒有察覺的，而正常播放時(shí)長為 200ms 的數(shù)據(jù)，經(jīng)過加速，能很快的播放完，之后就恢復(fù)成正常速度播放，這樣就保證了不會(huì)再有跳幀的現(xiàn)象，最后的 AB TEST 數(shù)據(jù)顯示開播跳幀時(shí)長完全為 0，而卡頓情況也有比較明顯的降低。

在解決了開播跳幀的問題之后，我們來回顧一下開播跳幀優(yōu)化的整個(gè)過程：

在這整個(gè)過程中可以明顯看到對(duì)快手整個(gè)數(shù)據(jù)平臺(tái)的測(cè)試監(jiān)控和統(tǒng)計(jì)的依賴，無論是評(píng)價(jià) CDN 的質(zhì)量，還是 CDN 優(yōu)化后的對(duì)比測(cè)試，客戶端的 AB TEST 效果驗(yàn)證，都需要觀察對(duì)比全網(wǎng)的數(shù)據(jù)，才能確認(rèn)優(yōu)化效果，證明確實(shí)完美解決了跳幀問題。

httpDNS 首屏優(yōu)化

我們要分享的第二個(gè)優(yōu)化點(diǎn)是首屏的優(yōu)化，首屏的整個(gè)過程，大致可以分為下圖的這六個(gè)步驟，快手對(duì)各步驟的耗時(shí)做了詳盡的分析，分析結(jié)果顯示，DNS 解析其中是最耗時(shí)的環(huán)節(jié)，因此要降低首屏?xí)r間，必須先降低 DNS 解析時(shí)間。

傳統(tǒng)的 DNS 解析（業(yè)界統(tǒng)稱 localDNS 方案）的過程很簡(jiǎn)單。整個(gè)過程如下圖，APP 向所在網(wǎng)絡(luò)運(yùn)營商的 DNS Server 發(fā)起域名解析的請(qǐng)求，而運(yùn)營商 DNS Server 會(huì)向 CDN 的 GSLB 系統(tǒng)發(fā)起遞歸查詢，GSLB 通過運(yùn)營 DNS Server 所屬 IP 地址判斷查詢來自于哪個(gè)運(yùn)營商和地理位置，然后返回若干合適的 CDN 邊緣節(jié)點(diǎn) IP 給它。這個(gè)過程中，APP 和 CDN 之間隔了運(yùn)營商 DNS Server 這一層，CDN 在分配節(jié)點(diǎn)的時(shí)候其實(shí)沒有辦法獲取任何 APP 的信息。為了解決傳統(tǒng) localDNS 調(diào)度不精確，容易被劫持等缺點(diǎn)，近年業(yè)界起興起了另一種方案 httpDNS。其原理是 APP 通過 HTTP 協(xié)議直接調(diào)用 CDN 提供的 httpsDNS API，獲取一組合適的邊緣節(jié)點(diǎn) IP。這兩種方案互有優(yōu)劣：

localDNS 和 httpDNS 各有優(yōu)劣，而且都有一定的失敗率，為了提升 DNS 解析的成功率，快手的 DNS 解析方案是 localDNS 和 httpDNS 結(jié)合使用。

為了結(jié)合 localDNS 和 httpDNS 的優(yōu)點(diǎn)，并且考慮到解析返回的多個(gè) CDN 邊緣節(jié)點(diǎn)的優(yōu)選，快手設(shè)計(jì)了獨(dú)特的 DNS 解析方案：

于是我們對(duì) IP 優(yōu)選方案進(jìn)行了進(jìn)一步優(yōu)化，測(cè)速后并不是直接選用結(jié)果最優(yōu)的那一個(gè)，而是在測(cè)試結(jié)果可以接受的一定范圍內(nèi)進(jìn)行隨機(jī)挑選，這樣就避免了大量用戶都聚集到少數(shù)節(jié)點(diǎn)，導(dǎo)致節(jié)點(diǎn)負(fù)載不均衡：

對(duì)這個(gè)優(yōu)化方案進(jìn)行 AB TEST，質(zhì)量數(shù)據(jù)完全符合預(yù)期：

首屏?xí)r間下降了 30%，卡頓也有明顯改善，節(jié)點(diǎn)優(yōu)選的策略使得連接失敗率也下降了 2 個(gè)百分點(diǎn)！一個(gè)為了優(yōu)化首屏而提出的策略，對(duì)多個(gè)指標(biāo)都有如此明顯的正向影響，是我們一開始沒有預(yù)料到的。

挑戰(zhàn)與規(guī)劃

快手的直播業(yè)務(wù)現(xiàn)在還處于高速發(fā)展之中，對(duì)流媒體大數(shù)據(jù)分析平臺(tái)也提出了新的挑戰(zhàn)：

為了應(yīng)對(duì)這些挑戰(zhàn)，我們會(huì)持續(xù)加強(qiáng)投入，完善數(shù)據(jù)方面的核心能力。

在大數(shù)據(jù)平臺(tái)之上，從整個(gè)直播體驗(yàn)優(yōu)化層面來看，為了真正做到用戶體驗(yàn)的端到端可控，我們需要有能力深入所有環(huán)節(jié)監(jiān)測(cè)和調(diào)優(yōu)，因此快手將建設(shè)核心技術(shù)能力作為下一步優(yōu)化的基礎(chǔ)：

寫在最后

快手的直播業(yè)務(wù)仍在高速增長，用戶數(shù)量快速的上漲對(duì)服務(wù)質(zhì)量有更高的要求，流媒體大數(shù)據(jù)平臺(tái)是各項(xiàng)視頻業(yè)務(wù)的一個(gè)基礎(chǔ)平臺(tái)，需要提供完善且穩(wěn)定的數(shù)據(jù)收集，數(shù)據(jù)處理，數(shù)據(jù)監(jiān)控，數(shù)據(jù)分析等服務(wù)。為了應(yīng)對(duì)業(yè)務(wù)挑戰(zhàn)，我們會(huì)持續(xù)擴(kuò)充完善數(shù)據(jù)基礎(chǔ)架構(gòu)，擴(kuò)張相關(guān)技術(shù)團(tuán)隊(duì)，歡迎更多有大數(shù)據(jù)平臺(tái)實(shí)戰(zhàn)經(jīng)驗(yàn)，對(duì)流媒體大數(shù)據(jù)分析和優(yōu)化感興趣的牛人加入快手的視頻技術(shù)團(tuán)隊(duì)。相信在未來，快手的流媒體大數(shù)據(jù)平臺(tái)能更好的服務(wù)用戶，達(dá)成快手記錄世界的愿景。

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。