首次揭祕！春晚活動下快手實時鏈路保障實踐

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

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

Tips：點擊「閱讀原文」連接可查看做者原版 PPT 及分享視頻～

1、快手 Flink 簡介

咱們首先來看一下快手的實時計算架構圖。主要分爲4個部分，包括數據接入、數據計算、數據應用和數據展現。各層職責分明、銜接順暢，方便用戶開發。

快手的 Flink 集羣規模大概有 3000 多臺機器，日處理條目數爲20萬億，峯值爲38億條。主要應用場景包含如下四類：

• 實時 SQL 平臺，這是 Flink 託管的一個產品化的 SQL 平臺。
• 短視頻、直播等指標的實時計算，涵蓋了公司的主要業務和產品。
• 機器學習的數據預處理，支撐着快手廣告等各類模型的訓練。
• 快手全部的日誌拆分、同步等實時的數據流。

2、春晚實時保障方案

快手中標了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個重要的部分就能夠衡量一個做業是否健康。若是咱們檢測到做業有性能問題須要擴容，須要按照必定順序選擇資源來補充——集羣內冗餘資源，備用集羣，低優任務資源。

3、春晚實時大屏

下面咱們以實時大屏做爲經典案例來介紹。快手春晚實時大屏爲做戰指揮官提供最核心的活動和公司大盤實時數據，總共承接了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.服務部署

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

• 雙機房熱備。一旦機房掛掉，馬上切到另外一個機房。
• 多鏈路熱備。針對全量鏈路和採樣鏈路，集羣內物理隔離、多鏈路運行。
• 指標故障用戶無感知。最上面視圖層屏蔽底層鏈路，底層出問題能夠秒級切換。

4、將來規劃

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

• 推廣 SQL，探索批流統1、Table&Stream 的普遍用途。
• 自研 SlimBase statebackend，實現存儲計算分離。
• 提高 Flink 故障自愈能力。
• 創建做業診斷模型，實現問題快速定位。
• 探索數據庫、K8s 等相關係統的組合應用。

文章不夠看？點擊「閱讀原文」可直接回顧做者現場分享的講解視頻～