當前位置：首頁 > 科技 > 軟件

大型直播活動保障S13的實踐和思考

來源：責編：時間：2023-11-28 17:11:56 274觀看

導讀背景和目標英雄聯盟全球總決賽是英雄聯盟賽事每年度最受矚目的節點，也是B站全年賽事熱度最高的時段。第13屆英雄聯盟全球總決賽（下文簡稱S13）今年繼續在B站進行直播，本文主要分享S13賽事保障的實踐和思考。S13的業務主目

背景和目標

英雄聯盟全球總決賽是英雄聯盟賽事每年度最受矚目的節點，也是B站全年賽事熱度最高的時段。第13屆英雄聯盟全球總決賽（下文簡稱S13）今年繼續在B站進行直播，本文主要分享S13賽事保障的實踐和思考。

S13的業務主目標是觀賽用戶達到1.2億，可拆解到賽前、賽中、賽后三個階段：

賽前重在流量蓄水，擴大目標用戶，通過賽事活動預熱、資源位投放、預約/Push召回，將流量引流到S13賽事主房間（下文簡稱主房間）觀賽。
賽中用戶集中在主房間，重點在提升用戶觀賽以及互動體驗，提高用戶的轉化率和留存率。
賽后引導觀賽用戶會到稿件播放頁觀看回放，在評論區參與選手打分，在動態/話題持續發表自己對賽事的觀后感。

圖1 S13整體介紹

因此，我們的保障目標是保證系統在洪峰流量下為用戶提供穩定的功能和流暢的觀賽體驗，配合業務側達成業務目標。面臨的挑戰概括為兩點：

洪峰流量大：難點在如何估算業務指標、如何正確將業務指標轉換為技術指標、以及如何應對高并發流量。
牽扯的業務范圍廣：難點在如何不缺不漏、以及如何在業務迭代壓力大的背景下盡可能提效的完成保障。

接下來讓我們一起探討本次保障是如何落地的，以及在大型活動保障上帶來了怎樣的思考。

制定保障計劃的思路

通過上文對業務主目標的介紹和拆解，可看到業務目標的達成依托于賽事各階段為用戶提供的功能和體驗，保障業務主目標達成也就是保障S13所有要落地使用的業務功能。因此，制定技術保障計劃的思路是：首先確定S13要使用的業務功能范圍和各功能的業務指標（如曝光量/轉化率等），其次將其轉化為技術鏈路和技術指標（如QPS/TPS），最后運用技術手段對齊進行保障。

下圖為S13的保障計劃和時間線，下文也將逐步介紹我們是實踐和落地的：

圖2 S13整體保障計劃

業務場景地圖和核心業務指標

業務場景地圖指的是S13所有落地要使用的業務功能，圈定了我們要保障的業務范圍；核心業務指標在S13中指的是PCU（Peak Concurrent Users 直播間峰值在線人數)，作為直播場景重要的指標，決定了我們要保障的高并發量級。

項目立項后的第一時間，產運研測各方一起討論敲定了業務場景地圖，共60+的業務功能，為便于下文具體講解如何將業務場景地圖/業務指標轉化為技術鏈路/技術指標、以及使用的技術保障手段，首先將S13核心功能介紹下：

活動頁	流量入口	主房間	稿件播放頁
圖片	圖片	圖片

表1 業務場景示意圖

活動頁：S13投放了多個活動頁提高用戶的參與度，如用戶可以在主活動頁上追蹤賽程信息，觀賽的同時參與預測、觀看、分享、簽到等任務。
流量入口：S13作為一年一度的重要活動，投放在多個資源位，用戶從這些入口進入主房間；賽后，用戶從主房間退出再次返回這些流量入口。該場景需要關注返回時的自動刷新機制帶來的尖刺流量。
主房間：S13最核心還是在直播間內，包含流的觀看和功能互動兩部分。流觀看從穩定性來看，上行流和下行流需要保證穩定可靠容災；從帶寬成本來看，還需要考慮P2P覆蓋率、轉碼技術。此外，每次進房需要獲取房間底層信息、功能數據（如榜單/運營位/底部Tab/歷史彈幕等），在比賽期間，還有天選時刻、熱力特效、Combo彈幕等互動玩法。其次，房間內的發彈幕/送禮特效等功能均依賴長連接，而長連接的壓力是PCU級別的放大效應。最后，終端的性能表現、播放的質量監控也是保證用戶觀賽體驗重要的一環。
稿件播放頁/動態等：S13不僅是觀賽后就結束了，B站作為一個業務形態十分豐富的平臺，用戶還可以去觀看直播回放、知名解說、在動態話題評論等參與討論。

圖3 S13核心業務場景

實際執行中，我們建議利用表格形式將業務場景地圖和業務指標羅列出來：

表2 S13業務場景地圖一覽表表頭參考

賽事階段	PCU預估
入圍賽	Xw - Yw
瑞士輪	Xw - Yw
淘汰賽	Xw - Yw
半決賽	Xw - Yw
決賽	Xw - Yw

表3 S13賽事各階段PCU預估

流量預估模型與優化

流量預估模型

將業務核心指標轉化為技術指標，指的是利用曝光量/轉化率/點擊率等轉換成技術指標QPS/TPS。S13的業務指標PCU可等價于曝光量，一個業務功能對房間在線用戶同時曝光。根據我們的經驗，基本可以按照目標QPS=曝光量*轉化率1*......*轉化率n/分攤時長=PCU*轉化率1*......*轉化率n/分攤時長。

圖4 技術指標QPS/TPS的流量預估模型

下面通過幾個典型場景具體說明該模型的運用，以及主房間這類高在線房間遇到的瓶頸問題，我們是如何通過熱門房間緩存、流量打散、流量隔離和下滑預加載等技術手段解決的：

進房場景

功能概述：用戶從閃屏、首頁推薦、全量Push、小黃條等資源位進入主房間時，終端向服務端請求流地址/房間底層信息/歷史彈幕等數據，使主房間成為高在線房間，帶來單房間熱點問題。

QPS預估：總進房QPS=各資源位進房QPS之和。以全量Push為例，Push進房QPS=全量用戶數*送達率*點擊率/推送時長（全量用戶數*送達率=Push曝光量，推送時長=分攤時長）。

圖5 進房場景QPS趨勢圖

技術優化：單房間熱點問題使得系統內獲取房間維度數據成為瓶頸，優化手段是通過PCU指標高低判定是否為高在線房間，通過將高在線房間加入熱門房間內存緩存來承接高并發請求。

圖6 高在線房間進房場景優化

圖7 進房場景緩存命中率

天選時刻

功能概述：開啟天選時刻，主房間彈出天選參與框，用戶若點擊一鍵參與則參與本次天選，用戶若點擊關閉則放棄本次天選，到達設定時間后，從所有參與本次天選的用戶中選出中獎用戶。

圖8 直播間天選時刻

QPS預估：參與天選接口的QPS=PCU*點擊參與轉化率。

技術優化：當PCU是百萬千萬級別時，該場景存在寫瓶頸。優化手段是通過流量打散，將參與框對用戶的彈出時間錯開，分攤在一定時間內對所有用戶展示完（分攤時間不會影響用戶的參與時間），并且根據PCU來自適應調整分攤時長。經調整，QPS=PCU*點擊參與轉化率/分攤時長，有效化解了尖刺流量超出系統承受能力的問題。

圖9 天選時刻打散

圖10 參與天選接口的尖刺流量

長連接

功能概述：主房間內多項功能依賴長連接，例如用戶在主房間發送一條彈幕，長連接會將此條彈幕廣播到所有與主房間建立連接的終端。

QPS預估：長連接邊緣節點的壓力=N*PCU（N是同時發生的廣播事件）。一方面，N*PCU越大，帶寬成本越高；另一方面，實際并不會將所有事件都廣播出去，否則干擾用戶的觀看體驗。

技術優化：我們將主房間這類高在線房間的監控和控制與其他房間隔離，針對主房間各廣播事件的QPS和Size單獨監控、單獨限流，通過單獨調控主房間使系統壓力、帶寬成本和用戶體驗達到一個平衡。

圖11 總帶寬和高在線房間帶寬隔離監控

散場場景

功能概述：如前文介紹，主房間的散場路徑分別是退回至進入房間之前的流量入口頁面和下滑至另外一個直播間。

QPS預估：

散場路徑一為流量入口帶來的QPS=PCU*退回點擊率；
散場路徑二為下滑的下一個直播間帶來的QPS=PCU*下滑轉化率。

與電影散場時觀眾同一時間集中走出觀影廳類似，上述兩個散場路徑的QPS是非常明顯的尖刺流量。

圖12 散場場景的尖刺流量

技術優化：

散場路徑一：出于推薦效果的考量，用戶停留在主房間超過一定時間后再回退至流量入口，部分流量入口會觸發自動刷新機制。但并不是所有用戶回退后是繼續消費最新推薦內容。因此，采取的手段是在部分時間段避免觸發自動刷新機制，更自動化的手段是當超出系統承受值時，自動控制終端不觸發自動刷新。
散場路徑二：由于主房間的PCU過高，導致下滑的下一個房間也成為一個高在線房間，依賴高在線房間SDK可使該房間自動進入熱門房間緩存。但根據對推薦結果的分析，我們發現推薦的下一個房間聚集在有限的幾個賽事房間。為更安全的防御這類瞬時尖刺流量，優化手段是基于推薦結果，利用這幾個賽事房間作為主房間下滑的房間候選池，并提前加入熱門房間內存緩存。

圖13 散場路徑二優化后緩存命中率效果

全局維度關注流量

同一個下游，可能被多個業務場景同時調用，該下游的流量是所有被調用之和。因此除了關注某個指定接口的QPS，還需以業務場景維度和整場活動維度來關注，下文我們還會再探討實際操作上如何去做。

另外，從項目成本以及資源考慮，賽事期間的流量遠高于日常，所需要的資源也遠高于日常，需要提前盤點各階段成本、進行資源的采買，因此全局估算流量也是資源容量預估的前提。

保障任務分工

確定業務場景地圖后，參與人和團隊的確認需要結合保障事項和組織架構兩方面考慮。

參考RASIC原則，保障事項拆分為若干項子任務，每一項子任務需設立負責人以及明確責任邊界、目標和DeadLine。另一方面，實際過程中不免存在交叉事項涉及多方資源協調，因此根據保障事項涉及到的部門，分別設立了部門級別的方向負責人，方向負責人被充分授權負責協調保障事宜。最后，建立定時定期同步進展和風險的機制，也是整個項目順利運行的重點。

圖14 保障接口人思路示意圖

實踐和思考

除了前文所述用戶強感知到的業務功能之外，還有基礎建設部分，如業務功能底層使用到的流媒體、長連接、賬號、風控等，我們將其歸納在業務基礎建設中分專項進行保障。以及從B站的整體基礎架構來看，各層基礎組件如動態/靜態CDN、SLB、入侵防御WAF、統一網關APIGW、內部服務發現Discovery、PaaS、存儲Redis/DB、異步消費Databus、網絡、大數據等的資源預備、多活容災能力、應急預案，我們將其歸納在技術基礎建設中整體保障（見圖2）。

接下來我們將重點討論技術鏈路的梳理、故障演練、全鏈路壓測、預案SOP、變更管控和賽中跟蹤的實踐和思考：

圖15 重點保障事項時間線

技術鏈路梳理

技術鏈路梳理需要得到：

該業務場景涉及到的請求接口以及每個接口的鏈路依賴
這些請求接口以及鏈路依賴的QPS/TPS

故障演練、全鏈路壓測以及后續的SOP、監控都依賴技術鏈路的梳理結果。根據代碼梳理技術鏈路是常用的方法：

Step1：梳理該業務場景下，涉及哪些用戶在什么時機下，在哪些位置上做什么動作，即用戶、終端、服務端三者的交互。

Step2：根據交互流程，確定終端和服務端交互的接口。

Step3：下鉆每個交互接口的鏈路。

但在S13中，存在兩個問題：

時間成本高：根據經驗，完成一個場景的技術鏈路梳理需要0.5d~2d（與場景復雜度/熟悉程度相關），60+場景共需要100d左右。
準確性：人都有百密一疏，純靠人看代碼容易存在紕漏。

因此，聯同業務架構團隊，我們在服務質量保障平臺Advisor（下文簡稱Advisor）上集成了輔助工具：在Advisor上定義S13涉及到的業務場景，通過抓包走一遍該業務場景下用戶的行為路徑，將抓包結果錄入系統，并根據Trace自動輸出鏈路依賴，同時計算鏈路依賴的放大情況。

定義業務場景	抓包結果錄入

表3 Advisor場景管理

圖16 技術鏈路示意圖，其中每一個卡片標記放大倍數

根據前文流量預估模型計算終端接口QPS和技術鏈路后，也可得到鏈路上各層依賴的QPS。也因為平臺上維護了技術鏈路元數據，讓前文提到的從業務場景維度和活動全局維度關注流量成為一件可能實現的事情，否則以文檔形式記載技術鏈路，很難做到這一點。

圖17 Advisor上技術鏈路元數據模型

遺留的問題是，某個業務場景可能由于版本不同、用戶身份不同導致技術鏈路不同，這里提供兩種解決方案：

方式1：構造不同版本、不同用戶身份多次抓包，Advisor支持將多次抓包合并作為最終結果；在此基礎上，通過代碼檢查梳理結果是否全面。

方式2：Advisor根據線上真實請求匯總成完整的請求鏈路，再由技術同學從中擇選S13涉及到的鏈路。

圖18 基于完整鏈路擇選

故障演練

S13中希望通過故障演練平臺Fault（下文簡稱Fault）達到的目的是：正確識別到技術鏈路上的強弱依賴，強依賴應當確保有發現機制和預案手段，弱依賴應當確保可以自動降級，且降級后不影響該業務場景的核心功能。建議故障演練放在前置工作：

通過故障演練可識別S13的強依賴路徑，便于更有針對性的進行壓測、SOP。
故障演練發現的問題涉及代碼改動，壓測應當基于改動后的代碼。

日常演練的做法是以接口維度將其中的故障點依次注入故障（可參考B站故障演練平臺實踐）。但S13的60+業務功能，逐一驗證接口，時間成本太大。因此，將演練優化為兩大步驟：

Step1：優先確定面向終端的接口的強弱。如果某個接口故障并不影響該業務場景的核心功能，則定義為弱依賴。例如進房場景，通過驗證全屏/豎屏觀看、喚起禮物面板送禮、在彈幕區發送彈幕互動等幾個核心功能，從20+個接口最終確定4個強依賴接口（見表3的強弱依賴標注）。

Step2：針對Step1篩選出來的強依賴接口，聯同質量工程效率團隊建設了面向業務場景的故障演練，以業務場景維度整體驗證。將Advisor的技術鏈路導入Fault，Fault自動將標注預期是弱依賴的依賴點組合排列，自動依次注入故障和調用自動化用例驗證表現。

圖19 Step2示意圖

圖20 Fault業務場景演練

全鏈路壓測

S13通過全鏈路壓測平臺Melloi（下文簡稱Melloi）來發現和驗證高性能/高并發帶來的問題，高在線房間存在的問題也非常具有共性：

熱點Key問題：用戶集中在主房間，以房間Id/主播Id為 Key的緩存成為熱點Key。
空緩存問題：賽事期間用戶量相比平時翻了幾十上百倍，且存在不少一段時間內沒有訪問過直播的冷數據用戶，需要空緩存或者使用布隆過濾器防止緩存穿透造成DB的高并發，甚至部分場景需要預熱。
消費積壓問題：賽事活動與用戶行為強相關，例如觀看達到X分鐘可獲獎勵，主房間的觀看量百萬千萬級別，要求高性能消費和削峰。

本文重點探討基于Advisor的技術鏈路信息，在壓測環節可做的優化：

提高壓測數據準備的效率：純讀接口可根據Advisor信息從線上錄制流量回放作為壓測流量
提高壓測結果回收的效率：可根據Advisor信息，與壓測流量對比，檢測壓測流量是否已覆蓋需要覆蓋的鏈路，以及技術鏈路上各層的指標是否處于健康水位，并根據具體情況提供標準化解決方案的參考（例如熱Key問題，可以提供統一的熱Key識別和解決方案）。

圖21 全鏈路提效示意圖

預案SOP

針對故障演練識別到的強依賴路徑，需要做好預案SOP?？梢钥s短MTTR為目標，從1分鐘發現、5分鐘定位、10分鐘恢復的原則準備預案：

可能故障點	業務影響范圍	如何1分鐘發現	5分鐘定位方法	10分鐘恢復手段	操作人

表4 預案SOP模版

變更管控

基于安全變更要求，賽事直播保障期間，我們也啟用了變更管控封網，嚴格控制線上變更

數量，同時也需要支持必要的需求迭代變更，我們采取了以下措施：

整個活動保障期間：非強變更管控，根據前期場景梳理涉及到的業務功能，對其業務需求和技術需求上線變更要求進行郵件報備。報備內容需要包括變更內容、變更的風險、如有問題是否支持回滾、預案SOP等；
關鍵賽事直播當天：強變更管控，同樣來自前期場景梳理設計的業務應用，通過“變更管控 ChangePilot”平臺進行創建業務+服務等級的封網策略。同時支持緊急情況下的變更需求提供綠色通道。

圖22 強變更管控策略創建

賽中跟蹤

穩定性可觀測：基于SLO體系的持續建設，我們實現了服務可用率、服務飽和度的觀測/告警覆蓋。賽事過程中通過穩定性大盤我們能夠非常直觀的觀測到全站業務的穩定性情況；當服務出現可用率的下跌（10分鐘平均可用率N2），相關協同群會立即推送預警工單。同時提供相關錯誤詳情和錯誤根因推薦，大幅提高問題排查定位效率；

圖23 SLO全網業務大盤

實時監控大盤：除了全局業務穩定性的觀測，賽事過程也同樣會關注PCU情況、核心場景的QPS、P90耗時、限流情況；以及核心場景涉及服務的容量水位；通過應用APPID進行元信息關聯，獲取直播場景下相關的緩存集群、數據庫實例、消息隊列等組件的信息，關聯實現組件容量水位的實時觀測。以上指標均配置了不同檔位的閾值，能夠快速發現基礎資源容量風險。

圖24 賽事保障實時監控大盤

基礎數據同步：基于業務SLO視角和大盤資源視角，我們會在賽事直播過程中進行告警的應急響應處置、核心資源水位數據定時同步。直播后對告警事件處置情況以時間線方式導出，相關監控數據也會進行持久化存儲，支持后續分析復盤。

展望

英雄聯盟總決賽今年已經走到了第13個年頭，B站在每年的S賽保障上也逐漸積累了越來越多寶貴的經驗。此外，直播每年的大型活動還有跨晚、拜年紀等，大型活動保障的經驗如何以平臺化的方式沉淀下來，為后續的保障提高效率是我們需要進一步考慮的?；诒敬谓涷?，以及前文探討的直播特性問題，對于一場活動的保障可以考慮如下流程：

圖25 大型直播活動保障平臺化

本期作者

趙丹丹嗶哩嗶哩資深開發工程師

吉翔嗶哩嗶哩資深運維工程師

本文鏈接：http://www.tebozhan.com/showinfo-26-34922-0.html大型直播活動保障S13的實踐和思考

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇：談談你對ThreadLocal的理解

下一篇：讓人壓抑的 C++：記一個函數指針的問題

標簽：

熱門焦點

5月iOS設備性能榜：M1 M2依舊是榜單前五

和上個月一樣，沒有新品發布的iOS設備性能榜的上榜設備并沒有什么更替，僅僅只有跑分變化而產生的排名變動，剛剛開始的蘋果WWDC2023，推出的產品也依舊是新款Mac Pro、新款Mac Stu
Flowable工作流引擎的科普與實踐

一.引言當我們在日常工作和業務中需要進行各種審批流程時，可能會面臨一系列技術和業務上的挑戰。手動處理這些審批流程可能會導致開發成本的增加以及業務復雜度的上升。在這
十個簡單但很有用的Python裝飾器

裝飾器（Decorators）是Python中一種強大而靈活的功能，用于修改或增強函數或類的行為。裝飾器本質上是一個函數，它接受另一個函數或類作為參數，并返回一個新的函數或類。它們通常用
本地生活這塊肥肉，拼多多也想吃一口

出品/壹覽商業作者/李彥編輯/木魚拼多多也看上本地生活這塊蛋糕了。近期，拼多多在App首頁“充值中心”入口上線了本機生活界面。壹覽商業發現，該界面目前主要
阿里大調整

來源：產品劉有媒體報道稱，近期淘寶天貓集團啟動了近年來最大的人力制度改革，涉及員工績效、層級體系等多個核心事項，目前已形成一個初步的“征求意見版”：1、取消P序列
網紅炒股不為了賺錢，那就是耍流氓！

來源：首席商業評論6月26日高調宣布入市，網絡名嘴大v胡錫進居然進軍了股市。在一次財經媒體峰會上，幾個財經圈媒體大佬就“胡錫進炒股是否知道認真報道”展開討論。有
OPPO、vivo、小米等國內廠商Q2在印度智能手機市場份額依舊高達55%

7月20日消息，據外媒報道，研究機構的報告顯示，在全球智能手機出貨量同比仍在下滑的大背景下，印度這一有潛力的市場也未能幸免，出貨量同比也有下滑，多家廠
華為Mate 60保護殼曝光：碩大后置相機模組凸起程度有驚喜

這段時間以來，關于華為新旗艦的爆料日漸密集。據此前多方爆料，今年華為將開始恢復一年雙旗艦戰略，除上半年推出的P60系列外，往年下半年的Mate系列也將
英特爾Xe-HP項目終止，將專注Xe-HPC/HPG系列顯卡

據10 月 31 日消息報道，英特爾高級副總裁兼加速計算系統和圖形事業部總經理表示，Xe-HP“ Arctic Sound” 系列服務器 GPU 已經應用于 oneAPI devcloud 云服

AVt天堂网手机版,亚洲va久久久噜噜噜久久4399,天天综合亚洲色在线精品,亚洲一级Av无码毛片久久精品

大型直播活動保障S13的實踐和思考

背景和目標

制定保障計劃的思路

業務場景地圖和核心業務指標

流量預估模型與優化

流量預估模型

進房場景

天選時刻

長連接

散場場景

全局維度關注流量

保障任務分工

實踐和思考

技術鏈路梳理

故障演練

全鏈路壓測

變更管控

賽中跟蹤

展望

5月iOS設備性能榜：M1 M2依舊是榜單前五

Flowable工作流引擎的科普與實踐

十個簡單但很有用的Python裝飾器

本地生活這塊肥肉，拼多多也想吃一口

阿里大調整

網紅炒股不為了賺錢，那就是耍流氓！

OPPO、vivo、小米等國內廠商Q2在印度智能手機市場份額依舊高達55%

華為Mate 60保護殼曝光：碩大后置相機模組凸起程度有驚喜

英特爾Xe-HP項目終止，將專注Xe-HPC/HPG系列顯卡

最新推薦

猜你喜歡

熱門推薦

相關資訊