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

寫在前面 ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

拉流端開播的過程

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

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

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

開播跳幀優(yōu)化

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

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

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

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

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

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

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

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

httpDNS 首屏優(yōu)化

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

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

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

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

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

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

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

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

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

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

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

寫在最后

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

生成海報

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