揭祕抖音 12 億紅包背後的祕密

在 2021 年春節聯歡晚會上，面對高達 703 億的紅包互動總數和累計 12.21 億的春晚直播間觀看人次，抖音技術團隊和火山引擎雲原生團隊通過雲原生化的基礎架構設計和敏捷開發流程設計，保障了紅包互動活動的安全、穩定、順暢開展。本文主要介紹了火山引擎雲原生團隊在本次活動中的一些貢獻！

來源 | 火山引擎雲原生

2021 年 2 月 12 日凌晨，字節跳動各地辦公樓依然燈火通明。線上，各個春晚支持團隊仍在飛書工作羣裏激烈交流着…… 此時距離 12 億紅包發送活動結束已經過了一個多小時，本次春晚的雲計算設施保障團隊——火山引擎雲原生團隊——還在一遍遍校對着，見證一個個數據被寫進抖音《2021 春晚數據報告》。

這是這個團隊第一次正面應對春晚的 “流量大考”。他們見證了春晚互動數據的再一次打破紀錄，也獲得了春晚互動零卡頓、零宕機的佳績。

27 天的 “技術奇蹟”

官宣成爲央視《春節聯歡晚會》獨家互動合作伙伴，對字節跳動內部的各個團隊來說，都意味着業界的信任和新的技術挑戰：

按照往年的經驗，企業承接春節春晚合作項目至少需要籌備 2-3 個月。而抖音在短短 27 天內就完成了從底層雲基礎設施建設，到上層數十種互動類新玩法的上線，這離不開背後的抖音技術團隊和火山引擎雲原生團隊。

事實上，爲了支持除夕當晚數億級 QPS 搶紅包請求，兩大支撐團隊在短時間內跨多個機房完成了服務器的協調，爲整個活動提供了充足的計算資源支撐；憑藉雲原生基礎設施，抖音平穩應對了流量洪峯，用戶的紅包互動體驗也自然流暢。

極致彈性的雲原生底層

2021 年，抖音技術團隊和火山引擎雲原生團隊爲春晚活動準備的服務器數量是 12 萬臺。相比前幾年春晚背後的服務器臺數，這一數字並沒有太多增長，但它之所以能順利保障流量峯值時期所有在線服務的穩定，離不開兩個關鍵：

其中，第一個關鍵保障了兩大支撐團隊在 27 天內極限完成所有服務器的部署；第二個關鍵有效控制了字節跳動在春晚活動支撐上的支出成本。

單純按照波峯準備資源易導致資源浪費

企業在部署業務時，爲了使業務能安然度過高峯，必須按照高峯的流量預估準備資源。但衆所周知，互聯網在線業務的流量具有明顯峯谷潮汐變化，當業務處於流量低谷時，很多資源會被浪費掉且無法通過超售進行回收。以抖音爲例，它在波峯波谷間資源利用率的差距可能達到 40%，而春晚更是一個極端的峯值場景。

爲了避免支撐春晚的計算資源在活動結束後成爲浪費，除了少量採購新服務器，這次火山引擎雲原生團隊將提高集羣整體資源利用率作爲主要技術方案。

方案一：離線資源拆借。字節跳動內部有很多離線任務需要資源進行調度，例如模型訓練等，但這些任務在時間上並沒有特殊約束。火山引擎對這部分業務所佔用的機器進行了拆借，設置離線出讓策略後，這些服務器可以在 5 分鐘內轉換成在線可用狀態，並通過服務彈性擴縮組件，根據資源需求配置完成活動所有服務的統一等比例快速擴縮。

方案二：在線混部出讓方案。春晚當天，字節跳動還有大量服務器在支撐其他在線服務。所謂在線混部出讓，即在保證其他業務穩定不受影響的前提下，在這些機器上插入部分春晚作業，例如抖音平臺大量投稿短視頻的碼率轉換和抽幀任務。火山引擎通過 FaaS+Virtual Kubernetes，配合單機維度的 QoS 管理和隔離手段，將業務申請的冗餘資源和在線業務波谷時段的冗餘資源供給春晚活動使用。同時，爲了緩解任務冷啓動帶來的延時影響，火山引擎也通過 Pod 維度的 Warm Up 池保證了資源的極致彈性。

基於上述兩種技術方案，團隊利用有限硬件設備，爲春晚活動提供了充足的算力支撐。

支撐億級用戶的穩定高性能存儲

解決計算資源問題後，擺在衆人面前的第二個問題是存儲。

除夕當晚，抖音共迎來 703 億次春晚紅包互動，億級高併發搶紅包、拆紅包行爲，給後端數據庫造成了巨大壓力。爲了確保活動的平滑順暢不宕機，火山引擎採用自研架構的 Redis 系統提供緩存服務：通過集中化元數據存儲，實現了節點和集羣性能的海量擴展；通過異步和多線程 IO 優化，將熱點數據打散和智能搬遷，大大降低 Redis 的長尾時延。在紅包雨活動期間，該系統憑藉字節跳動龐大的集羣數量和機器規模，支撐超過 2.5PB 數據。

在大規模分佈式系統中，通過消息隊列進行異步削峯也是有效應對海量流量衝擊的手段。面對紅包雨活動，火山引擎採用存儲和計算分離架構，所有持久化存儲都放在池化存儲中，由池化存儲組件來保證數據的一致性和可靠性，以及相應的災備和 Geo-replication 能力。而計算層節點則可以保持本地無狀態，專心處理消息隊列系統的計算邏輯，並實現極致彈性擴展。

在關係型數據庫性能保障層面，火山引擎自研的雲數據庫系統採用雲原生架構設計，通過高可用容災架構、智能自適應限流、日誌數據分離、日誌即數據庫、Multi-master、新型硬件（RDMA +AEP）等技術，讀寫 QPS 達到數千萬級別，保障了紅包雨活動期間抖音的穩定運行。

自研分佈式圖數據庫系統 ByteGraph

而面對抖音在整個春晚紅包活動中提供的紅包雨、集燈籠、答題分紅包等多種互動玩法，抖音技術團隊和火山引擎雲原生團隊將字節跳動自研分佈式圖數據庫系統 ByteGraph 用在了生產環境。在紅包活動中，相比常見的 KV 存儲系統和 MySQL 存儲系統，圖數據庫在應對春晚千萬級併發查詢方面有更大的性能優勢和更簡潔高效的接口。而 ByteGraph 歷經字節跳動豐富在線存儲場景，在功能上已演進得愈加完善。

在春晚 “拍視頻過年” 活動中，火山引擎自研的對象存儲在幕後爲數億用戶提交的短視頻內容提供可靠穩定存儲。同樣的，抖音用戶在春節期間觀看的包括超過 506 億播放次數拜年視頻在內的所有短視頻內容，也均存儲在 10EB 級超大規模對象存儲服務中。

匯聚機房 + 邊緣計算：扛住流量洪峯

春節期間，字節跳動各業務平臺紛紛上線節日活動，流量井噴爲 CDN 帶來了一次集中壓力測試。抖音作爲一個 DAU 高達 6 億的全民 APP，其日常波峯流量已經非常驚人，在春晚活動場景下，由於存在 APP 常規流量增長、口播場景需要集中冷啓動流量以及紅包活動流量，多重增長需求疊加後，除夕當晚，抖音的流量峯值高達日常的 3 倍以上。如何在短時間內爲這些流量提供網絡接入加速線路服務，也是技術支撐團隊要解決的一大難題。

基於在抖音、抖音火山版、西瓜視頻等內部業務場景中的多年實踐， 火山引擎在本次春晚活動中採用了自研的端雲配合融合加速線路方案。該方案提供全面覆蓋邊緣節點和終端設備的撥測能力，支持靈活的 L1/L2 回源控制、專線 / 公網回源無縫切換，可自動進行流量控制、運行時探測線路優選、容災等，在底層分佈式架構上實現了低時延、高彈性、易維護，提升了用戶體驗。

春晚直播和紅包活動有高可靠、高併發的場景需求，解決流量接入後，當流量洪峯經過各線路最終匯聚到 IDC，支撐團隊根據紅包活動流量需求特點，將大量新增業務邏輯就近接入邊緣匯聚機房，既保證了網絡的低時延，也減少了對核心 IDC 機房的壓力。同時，邊緣匯聚機房採用 IaaS 虛擬化技術，可實現非活動業務快速切換，在短時間內爲 PaaS 服務以及紅包雨計算服務提供了數倍於常態的資源需求。

全局流量智能調度，保障各機房均衡

對於春晚流量高峯場景，支撐團隊也在調度層面做了大量工作。

首先是流量的分級治理和合理降級。基於 BAM 接口分級管理平臺的業務流量分級信息，團隊採用 AppSettings + TNC + TTNet + HttpDNS 在移動端請求發起、域名解析等階段開展多層降級手段。針對冷啓場景，火山引擎也安排了專項降級治理和分時間段降級配置。最終，在用戶體驗無明顯損失的情況下，春晚紅包活動以平穩的流量波動度過 6 次口播冷啓及紅包活動的峯值疊加時刻。

其次是特性多元、性能強大的調度系統。得益於在字節系 APP 中積累的流量調度經驗，火山引擎的調度方案在傳統域名調度能力基礎上，可以基於統一移動端網絡庫，根據用戶 IP 等信息判斷其所在位置，並將其流量調度到最近的機房中去，進而實現流量合併、隔離等調度需求。針對移動端，團隊的調度系統具備十萬分之一級別的流量切換精度、數億級別在線客戶端配置管理、千萬級併發請求更新調度配置能力，可以在 24 小時內實現 99.5% 配置覆蓋。因此在春晚高併發大流量場景下，該系統爲抖音應對局部容災、整機房大規模容災等場景提供了充分能力支撐。

第三是高度自動化的容災能力。春晚場景下，當端上發現當前接入點請求異常時，完全依賴人工判斷進行切換操作會導致較高的時間成本和失誤風險。爲了確保故障出現時能快速切換到對等接入點的 IP / 域名，支撐團隊爲移動端重點流量的調度提供了自動容災能力，將故障對用戶的影響時長降至 1 分鐘內，保障了用戶在活動中的整體體驗。

結語

回顧本次活動的支撐工作，時間短、資源缺、性能要求高、容災壓力大，這些考驗對臨危受命的抖音技術團隊和火山引擎雲原生團隊而言是前所未有的。但兩個團隊承受住了壓力，通過雲原生基礎設施應對流量洪峯，通過多機房協同爲紅包雨活動提供算力，最終通過了 “流量大考”。

結合春晚的實踐成果，火山引擎已計劃向外開放這套基於雲原生技術打造的統一、健壯的基礎底層服務，幫助更多企業應對由全面互聯網化帶來的在線業務服務壓力和指數級增長數據處理壓力。除了高併發流量應對能力，在業務敏捷交付和迭代層面，火山引擎這次也展示了大量以應用爲中心的雲原生核心設計。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Nq1iTxe9XNI6UCp1G-EihA

猜你喜歡