首次揭秘！​春晚活動下快手實時鍊路保障實踐

摘要：本文由快手開發工程師劉建剛分享，主要介紹春晚活動下快手實時鍊路保障實踐。内容主要包含以下四部分：

1. 快手 Flink 簡介
2. 春晚實時保障方案
3. 春晚實時大屏
4. 未來規劃

Tips：點選「閱讀原文」連結可檢視作者原版 PPT 及分享視訊～

一、快手 Flink 簡介

我們首先來看一下快手的實時計算架構圖。主要分為4個部分，包括資料接入、資料計算、資料應用和資料展示。各層職責分明、銜接順暢，友善使用者開發。

快手的 Flink 叢集規模大概有 3000 多台機器，日處理條目數為20萬億，峰值為38億條。主要應用場景包含以下四類：

• 實時 SQL 平台，這是 Flink 托管的一個産品化的 SQL 平台。
• 短視訊、直播等名額的實時計算，涵蓋了公司的主要業務和産品。
• 機器學習的資料預處理，支撐着快手廣告等各種模型的訓練。
• 快手所有的日志拆分、同步等實時的資料流。

二、春晚實時保障方案

快手中标了2020年的央視春晚，春晚作為全球華人辭舊迎新的晚會，資料量之大前所未有。快手 Flink 作為公司的實時計算平台，支援春晚超大狀态和千萬并發等複雜計算。春晚項目的挑戰主要展現在穩定性、實時性、準确性三個方面，我們為此制定了一系列方案為春晚保駕護航。

下面我會通過這4個方面來介紹一下我們為春晚做的努力。

• 第一個是過載保護，主要介紹極端壓力下的技術應對方案；
• 第二個是全系統的穩定性，確定各個方面都萬無一失；
• 第三個是壓力測試，它是春晚的提前模拟；
• 第四個是資源的保障，涉及到資源的管理和保障。

1.過載保護

Flink 在流量激增或者單點性能不足的情況下，有可能會發生卡死、雪崩或者失敗的情況。這個時候一旦我們的實時作業挂掉，整個作戰計劃就會被打亂，可能給公司帶來很大的損失。

我們針對這種場景設計了一種健康檢查、智能限速、源端控制相結合的柔性可用技術。為什麼要通過源端控制？首先，如果出了問題，我們可以在下遊的 task 上進行控制，但是這樣的話可能帶來一個問題，它會造成反壓等阻塞行為，有可能會把整個作業卡死，是以我們通過控制資料源來從本質上解決問題。下面是我們技術實作：

• TaskManager 作為從節點，将自己的健康資訊定期彙報到 Master 節點。
• Master 節點一旦檢測到極端壓力，立刻要求所有的 source 限速 50%。
• 如果之後作業狀态良好，就會慢慢的提高我們的輸入 QPS，每次 10%。

然後看一下我們的測試效果圖。流量高峰到來時 QPS 為 200K。一旦 Master 節點檢測到極端壓力，直接将 QPS 限速到 100K。之後檢測到作業狀态良好，就逐漸地進行恢複。經過測試（随着逐漸恢複各項名額會有波動），我們的 CPU 使用率從最高的 100% 降到了 80%~90%，ygc 由每分鐘的10秒降到了每分鐘3秒以内，同時也避免了的 oom、心跳逾時、卡死等各種問題。這種技術能夠保障我們 Flink 在極度壓力下的存活，起到了削峰保命的效果。

我們還設計了一種輕量級的熱更新模型，在作業不停止的情況下通過 restful 接口實時的控制作業去應對各種壓力，避免了繁瑣的修改代碼、打包、上線等耗時過程。常見功能包括關閉快照、設定采樣率、source 源鮮素，如下圖所示。

2.全系統穩定性

分布式系統涉及到方方面面，任何一個環節出了問題都可能是緻命的，我們為此在故障應對和項目管理上做了很多工作。故障應對包含故障排除、故障演練、故障預案，項目管理包含作業管理、叢集管理、工程管理。

首先進行的是 Flink 的故障排除。Flink 的互動元件包括 Yarn，HDFS，Kafka，Zookeeper，我們逐一的對每個元件進行故障排除。它們各自的風險排除步驟，如下圖中的表格所示。

故障排除完了之後，就需要在真實的場景中進行故障演練。主要的演練方法就是在我們的叢集中，随機的注入各種異常來測試并且完善 Flink 的穩定性，確定 Flink 做到以下保障：

• 相關元件異常不影響 Flink，比如 Yarn 和 HDFS 的主節點挂掉。
• 作業當機，Hawk 監測系統5秒内發現并作相關處理。
• 作業 Failover 在30秒以内。

為了更好地應對各種故障，我們還制定了完善的故障預案，這是一套完整的應急指導方針。針對每一種故障，我們都有快速的問題排查和解決手段。

除了快速應對故障，良好的管理手段也必不可少，它可以有效的減少故障。下面介紹我們管理上的一些手段。

首先是作業管理這一塊，包含作業管理系統的穩定性和相關的運維工作。包括四個方面：

• 作業管理系統支援高可用。一旦出問題可以快速的切換。
• Checklist 規範使用者開發，包括快照設定和資料源對齊等實戰經驗。
• 常見工具，包含全局日志查詢、高負載查詢、快速遷移等。
• 報警機制和 metric 的展示，做到問題提前發現和及時發現。

接下來是叢集管理。叢集作為我們整個系統的實體載體，一旦出現問題就是緻命性的：

• 針對高優作業搭建多套實時叢集，避免離線的幹擾。
• 關鍵隊列實體隔離。針對特定叢集要求的作業，通過實體隔離來保障其穩定性。
• 機器環境的排查。確定機器環境符合我們的預期。
• 重要作業實作多叢集的部署，出現問題秒級切換。（實時大屏會詳細介紹）

最後一個就是工程的管理。工程管理的關鍵是時間線預案，主要是指導我們在什麼時間點該做什麼事情，貫穿整個項目開發。下面簡單描述了下春晚的事前、事中、事後的主要操作：

3.壓力測試

壓力測試相當于春晚的一個模拟，它能夠幫助我們發現很多問題。針對春晚，壓力測試比一般的時候要更複雜一些。面臨的最主要的兩個問題，第一個問題就是資料模型怎麼構造，比如說有哪些 topic、各 topic 的資料分布是怎麼樣的。第二個問題是我們如何根據這些模型生成符合條件的資料。

資料模型的難點在于建構的資料分布必須跟春晚保持一緻。我們的解決方案是以人為參考機關，基于統計規律建立人與資料分布的映射關系。簡單來說，計算出每個人在各個 Topic 的資料量，預估有多少人各個 Topic 的 QPS 就翻多少倍，當然實際情況會複雜許多。最終，我們根據公測和元旦當天使用者産生的資料來進行春晚模型的建立。

模型建構完成之後，需要根據模型生成資料。為此，我們建構了一整套完善的資料生成服務，使用者隻需要進行簡單的配置就可以，而流量控制、多 task 的協作、分布式生成等複雜的實作全部由平台實作。主要有三種形式的資料生成：

• 資料翻倍，基于 bytes 的流量翻倍，性能最佳。
• 時間壓縮，在不改變資料分布的情況下壓縮資料、提高 QPS。
• 樣本生成，根據使用者提供樣本生成符合條件（QPS、UV等）的資料。

4.資源保障

春晚對資料的實時性要求比較高。隻有資源保障到了才可以實作我們的實時性。

資源保障的關鍵政策是分級保障。我們把作業分了三個優先級：P0、P1 和 P2：

• P0 是高優作業，跟春晚相關的一些活動。
• P1 是重要的作業，是指業務方的一些重要作業。
• P2 是普通的任務，一般指非核心的作業。

為了做到分級保障，我們制定了重點保障高優先級作業的降級政策：

• 春晚之前，我們會批量的把 P2 的任務都停止掉，把資源全部都挪給 P0 和 P1。
• 春晚中，如果有需要，降級 P1 的資源來保障 P0 作業的資源。
• 春晚後，我們會把之前停掉的 P2 作業再重新提起來，并且從 kafka 最新的 offset 開始消費。

通過分級保障，在資源有限的情況下，優先保障了我們的重點作業，確定了高優任務的實時消費。分級保障對今後的服務治理意義重大。比如說以後的資源排程、灰階上線、作業遷移等等，都可以參考分級保障的政策。

資源保障的另一個展現在于快速擴容，分為實時名額監控和資源選擇兩個方面。實時名額監控包括作業吞吐，作業延時，快照資訊，實體資訊，通過這4個重要的部分就可以衡量一個作業是否健康。如果我們檢測到作業有性能問題需要擴容，需要按照一定順序選擇資源來補充——叢集内備援資源，備用叢集，低優任務資源。

三、春晚實時大屏

下面我們以實時大屏作為經典案例來介紹。快手春晚實時大屏為作戰指揮官提供最核心的活動和公司大盤實時資料，總共承接了100多個實時名額的計算，包括線上、紅包、互動等各項名額。主要的挑戰表現在三個方面：

• 資料量大，QPS 在千萬級别；
• 實時性要求比較高，在秒級以内；
• 穩定性要求高，可用性為4個9。

接下來我會從技術選型、壓力測試、服務部署三個方面順序展開。

1.技術選型

架構元件是以 Flink 為主，Redis 為輔。Flink 适合大規模的實時計算，Redis 作為一款高效的 KV 查詢工具來輔助實時計算。

各項名額中，基于 deviceld 的 UV 計算最多、複雜度最高。一般來說，先将字元串類型的 deviceId 轉成數字類型的 id，然後存儲在位圖結構 bitmap（存儲空間小）中進行計算。這裡介紹下快手的技術方案：

• Flink+HBase。HBase 負責将 deviceId 轉成 id，Flink 負責計算。
• Flink+Redis。通過 Redis 判斷 deviceId 是否首次出現，如果是就下發計算。
• Flink 自身。Flink 自建字典為快手内部實作的精準一次方案。

前面兩種方案将字典和計算解耦，适合多個作業共享一個字典。最後一種方式不再依賴外部系統，性能最佳。實時大屏根據自己需求和熟練度選擇了第二種方案。

2.壓力測試

壓力測試分為單作業的壓測和全鍊路的壓測。

• 單作業壓測這一塊，我們通過增量計算、批量通路、本地緩存、objectReuse 等優化技術，使單個作業的 QPS 達到百萬級别。
• 全鍊路壓測這一塊，用來評估整體性能，需要協調所有資料和作業，具體操作如下所示。

3.服務部署

最後一步是多鍊路的服務部署。實時大屏作業的穩定性要求特别高，必須多鍊路熱備：

• 雙機房熱備。一旦機房挂掉，立刻切到另一個機房。
• 多鍊路熱備。針對全量鍊路和采樣鍊路，叢集内實體隔離、多鍊路運作。
• 名額故障使用者無感覺。最上面視圖層屏蔽底層鍊路，底層出問題可以秒級切換。

四、未來規劃

上面是春晚實時大屏案例的介紹，下面也跟大家分享一下我們将來的一些規劃：

• 推廣 SQL，探索批流統一、Table&Stream 的廣泛用途。
• 自研 SlimBase statebackend，實作存儲計算分離。
• 提升 Flink 故障自愈能力。
• 建立作業診斷模型，實作問題快速定位。
• 探索資料庫、K8s 等相關系統的組合應用。

文章不夠看？點選「

閱讀原文

」可直接回顧作者現場分享的講解視訊～