博客 / 詳情

返回

從0到1建設美團數據庫容量評估系統

美團數據庫團隊推出了數據庫容量評估系統,旨在解決數據庫容量評估與變更風險防控等領域難題。本文介紹了系統架構和主要功能:系統使用線上流量在沙盒環境回放驗證變更安全,結合倍速回放技術探測集羣性能瓶頸,構建容量運營體系實現集羣容量觀測與治理閉環。系統具備數據操作安全、結果真實可靠、靈活高效賦能等特點,有效提升數據庫穩定性與資源利用率。

01 項目背景

數據庫作為業務系統的核心基石,其重要性不言而喻。隨着企業業務規模的持續擴張和社會影響力的不斷提升,企業對數據庫穩定性的要求也達到了前所未有的高度。在日常保障工作中,美團數據庫團隊也面臨着諸多挑戰,常見痛點如下:

痛點一:活動期間數據庫集羣的讀寫容量上限難以準確評估,會出現容量不足導致生產事故。

常見的容量評估方法包括指標計算和全鏈路壓測:

  • 指標計算,通過比較負載指標與閾值的大小,判斷節點是否健康,但流量與相關指標不是嚴格的線性關係,通過指標預測容量上限的準確性不高;
  • 全鏈路壓測,通過錄制上層業務流量並回放,能探測整條服務鏈路的瓶頸,但數據庫流量會受壓測場景複雜性、樣本豐富度等多種因素影響,導致難以完全擬真,同時業務服務接入壓測有一定的改造成本。

痛點二:數據庫變更是引起線上事故的主要原因之一,風險變更難以識別。

常規的解決方法有固定規則攔截和線下測試:

  • 固定規則攔截,將攔截規則集成到變更平台中,通過固定規則判斷變更風險,但諸如增加索引、修改字段類型等常規變更通常不會被攔截,這類變更可能導致 SQL 執行效率變差,進而引起數據庫性能下降甚至系統崩潰;
  • 線下測試,通過線下環境測試識別風險,但可能因為線下與線上數據存在差異,以及測試不夠充分,難以準確識別出所有潛在風險。

02 項目目標

建設數據庫容量評估系統,通過使用線上真實流量回放方法,構建一套完整的容量評估體系,為數據庫容量規劃提供科學的數據支撐和決策依據。容量評估系統在建設時有以下基本要求:

  1. 數據操作安全:數據庫作為業務核心組件,回放和評估流程不能影響線上集羣正常運行。
  2. 評估結果真實:需要使用完全擬真的流量和環境評估集羣讀寫容量,並有可靠機制確保結果的有效性和準確性。
  3. 系統靈活高效:需要有高效的自動化能力支撐,同時需要具備高度靈活性,底層能力能夠以插件化方式快速集成到各類系統中,完成回放驗證功能的賦能。

03 能力全景

圖 1 容量評估系統全景圖

  • 壓測平台:用户與系統交互的門户,提供流量回放,容量上探,容量運營,預算校準等場景的操作頁面。
  • 對外賦能:外部服務可通過調度系統提供的標準化接口(OpenAPI)應用回放能力,達成數據庫流量回放能力賦能。
  • 核心功能:系統核心功能涵蓋三個關鍵場景,即流量回放、容量上探與容量運營,共同構建了從測試到運營的全鏈路容量管理能力。
  • 基礎能力:流量回放基礎能力採用模塊化架構設計,通過清晰的職責劃分實現了功能解耦,大幅提升了流量回放的可操作性。
  • 壓測類型:數據庫流量回放能力在初期建設時並沒有設限,只要是支持 SQL 協議的測試數據庫目標或周邊組件,均可以通過相應改造進而支持。

接下來我們將結合實際生產中常見的數據庫應用場景,深入解析本系統流量回放、容量上探、容量運營三大核心功能及其對應的實現方案。

04 流量回放

評估的準確性是項目至關重要的考核指標之一,我們通過錄制在線流量、構建沙盒環境並執行流量回放,以評估數據庫集羣性能。在數據庫運維領域中,變更是高頻高危操作,如參數調優、慢查詢優化、版本升級等,那如何判斷其變更後的效果和穩定性呢?下面將通過實際案例來介紹-流量回放。

4.1 業務場景

4.2 架構設計

圖 2 流量回放流程圖

我們通過錄制線上數據庫流量,並將其擬真回放到隔離的沙盒環境集羣中,構建了一套完整的流量回放與分析能力。這一方案為運維變更提供了安全可靠的沙盒測試環境,能夠在模擬真實流量的條件下驗證變更方案,有效降低了生產環境風險。

完成整個流量回放測試需要以下四個核心流程:

流量採集(Traffic Collect)

該流程負責錄製線上流量,為後續回放動作提供原始 SQL,此流程有三個重要模塊。

  1. 數據採集:公司自研的 MTSQL 內核採集了全量 SQL 的文本、事務 ID 和執行耗時等相關數據,並由數據採集器(rds-agent)傳遞到後端 Kafka。
  2. 數據清洗:通過 Flink 建立全量 SQL 清洗鏈路,消費全量 SQL Kafka 隊列並過濾出回放註冊集羣的 SQL 信息。
  3. 數據存儲:將原始 SQL 信息結構化寫入至 ClickHouse 進行存儲,支持高效處理大規模 SQL 數據,同時也為流量文件靈活編排提供拓展能力。

流量處理(Traffic Process)

該流程負責對採集的 SQL 流量進行聚合、處理和固化處理。

  1. 數據聚合: 流量文件處理器(sql-log agent)會從 ClickHouse 中按主、從角色掃描每個註冊集羣的全量 SQL 語句。
  2. 數據處理:流量文件處理器(sql-log agent)按照主庫/從庫角色分別完成回放 SQL 的結構化整理,主庫採用事務維度聚合的方式處理 SQL,將同一事務內的多個 SQL 操作整合為一個執行單元,保證數據操作的一致性與執行效率;從庫採用獨立 SQL 維度處理,保證 SQL 獨立執行更好模擬高併發讀場景。
  3. 數據固化:經過處理的結構化數據會以流量文件形式持久化存儲,並上傳至 S3 供回放消費。

流量回放(Traffic Replay)

該流程負責消費流量文件並在沙盒環境中實現流量回放,具體詳細架構設計參考圖 3。

  1. replay-agent:作為回放動作執行主體,採用流式處理方式消費存儲在 S3 中的流量文件,通過數據通信與控制算法,完成對 SQL 回放的節律控制,將流量擬真回放至沙盒隔離集羣。
  2. 施壓部署:將 replay-agent 封裝部署在 Kubernetes 集羣中,每個回放任務都會動態創建一個獨立的回放 Job 資源,具備資源隔離、輕量化部署、彈性調度三大優勢,可支持大規模壓測場景。
  3. 沙盒環境: 通過數據備份構建流量錄製時間起點時的全量數據快照,保證回放過程中增量數據的匹配。在回放前提供“運維變更窗口”,在此期間用户可根據需求完成變更模擬操作,如 MySQL 版本升級、參數修改、表結構變更等。

圖 3 SQL Replay agent 架構圖

數據分析&報告(Data Analyze & Report)

該流程集成數據採集與分析能力,支持線上及沙盒環境的多維度數據採集,為用户提供全面、精準的可觀測性支持,主要包括:

  1. 運行負載指標,採集 CPU busy、系統負載(Load Average)、慢查詢、主從延遲等指標。
  2. SQL 執行信息,採集每個 SQL 模板對應的執行耗時。
  3. 環境參數,採集 MySQL 核心參數配置、實例機型信息。

4.3 效果展示

圖 4 流量回放報告-SQL 執行情況對比

流量回放分析報告會展示其惡化 SQL Top3、提升 SQL Top3 及 SQL 性能詳細對比結果,從上述分析報告中可得出,開啓表壓縮後,執行最多的 SQL 耗時從 0.90ms 增加到 0.97ms,未出現明顯下降,同時存儲佔用空間是原來的 40%,基於回放測試結論,小美的集羣啓用表壓縮功能,執行表壓縮變更後,系統穩定運行,磁盤空間不足問題得到緩解。

在美團,流量回放還在索引變更性能驗證、數據庫版本升級兼容性測試等場景中廣泛運用。

05 容量上探

上述變更場景的流量是按在線一倍流量回放,而在實際業務訴求中,用户希望評估集羣可承受的最大 QPS 是多少,能承受當前最大幾倍的流量。下面將通過實際案例來介紹-容量上探。

5.1 業務場景

5.2 流程實現

圖 5 流量上探流程

容量上探功能基於業務高峯期採集真實流量樣本,在沙盒的測試環境中自動執行多輪加速回放測試。通過漸進式壓力調節,逐步逼近數據庫性能極限,最終探測到集羣的最大承載讀寫 QPS。

超載標準

集羣容量與告警緊密相關,用户根據業務場景為 RDS 集羣設置相應的告警策略,集羣出現告警表明集羣超載。

沙盒環境

用户可根據實際需求靈活調整壓測沙盒環境配置,如機型、MySQL 版本、核心參數等。在評估線上集羣容量上限的應用場景中,為保證上探結果更真實準確,沙盒環境集羣配置要求與線上集羣保持一致。

上探流程

容量上探採用循環迭代的評估方式,每輪流量回放後,沙盒環境自動進行數據回滾,分析器會檢索本輪告警,並對是否觸達上限進行標記,同時計算下一輪迴放速度。評估過程分為兩個關鍵階段:

  1. 快速上探期:系統會持續提升流量回放倍速,通過指數加壓的方式快速探測系統的告警觸發邊界,初步確定容量上限範圍。
  2. 精確校準期:基於觸發告警的最小回放速度和未觸發告警的最大速度這兩個邊界值,分析器會進行二分計算確定下一次的回放速度。當達到預設精度要求時,評估循環自動終止,並輸出最終的容量上探結果。

5.3 倍速回放

容量上探通過調整回放倍速模擬流量增長,倍速回放通過壓縮 SQL 執行間隔,提升單位時間內的請求密度,從而增加數據庫負載壓力。

圖 6 倍速回放 QPS 示意圖

在回放 agent 內,SQL 處理與回放處理的流程如下圖所示:

圖 7 SQL 回放時間處理與倍速控制流程

回放進程會為流量文件中的每一個待執行的 SQL 分配一個執行協程,在協程內部由 CalcSendTime 函數對 SQL 回放的時序進行精準控制,該機制具體實現如下:

  1. 原始流量時間軸以 sqlBaseTime 為基準起點。通過計算 SQL 在線上環境的實際執行時間 sqlinfo.BeginAt 與 sqlBaseTime 的時間差,得到原始 SQL 執行的時間偏移量 originalDelta。
  2. 為實現倍速回放功能,系統會將原始 SQL 的時間偏移量 originalDelta 按回放速度進行縮放,得到調整後的回放計劃時間偏移量 planDelta(計算公式:planDelta = originalDelta/回放速度)。
  3. 為了避免協程在 planDelta 時間點同步獲取 SQL 並執行導致的流量失真,我們使用了 SQL 異步預獲取邏輯,協程會預先分配要執行的 SQL,此時會記錄當前系統時間 time.now,並計算此時距離回放開始的時間偏移量 realPassDelta。
  4. 系統通過比較 planDelta 與 realPassDelta 的大小關係來決定 SQL 執行時機:

    • 當 planDelta >= realPassDelta 時,協程會等待差值 waitTime 時間後再執行 SQL,理想情況是 SQL 都進入該分支等待執行。
    • 當 planDelta < realPassDelta 時,SQL 會立即執行 ,若大量出現這種情況,表示當前協程處理併發不足可能會導致回放失真。

這種時序控制機制確保了 SQL 回放過程能夠準確匹配預設的回放速度,從而實現了可靠的倍速調節能力,SQL 倍速回放時序控制效果如下圖所示:

圖 8 SQL 倍速回放時序控制示意圖

5.4 效果展示

圖 9 容量上探報告-上探過程展示

容量上探報告會展示容量上探結果、不同倍數壓測結果。從上述報告中可以看出,業務集羣降低機器配置,流量到達 6 倍以上時才觸發集羣告警,完全滿足業務 2 倍容量訴求,最終小美選擇對該集羣進行降配,降配後服務運行穩定。

在美團,容量上探還在服務器性能對比測試、數據庫參數調優驗證等場景中廣泛運用。

06 容量運營

面對業務活動時,業務方希望 DBA 給予所有集羣的容量狀態的評估,當前所負責的集羣處於什麼水位線,是快到瓶頸、還是冗餘很多?這裏我們構建了容量運營服務,即時掌控集羣容量狀態。

6.1 業務場景

6.2 運營設計

圖 10 容量運營設計架構圖

容量運營是集成了三個核心功能模塊:容量評估託管、容量計算和自動化運維,為大規模集羣容量觀測提供了便利入口,同時通過一站式運維管理,實現運營與治理閉環,顯著提升運維效率。

評估託管

  1. 託管集羣准入:對具有穩定流量模型的核心集羣進行託管准入註冊,同時根據准入規則週期性調整託管列表,完成託管集羣准入準出。
  2. 自動託管執行:所有註冊託管的集羣都將被自動納入評估隊列,由系統統一調度執行容量上探任務,每個集羣最後都會獲得一份容量上探報告以及讀寫 QPS 上限的評估結果,並設置有過期時間,逾期後進行自動重新評估。
  3. 評估結果保鮮:系統會定期檢查每個託管集羣的評估配置快照與線上集羣當前配置的差異。若業務流量模型、硬件配置、版本與參數、告警閾值等配置發生變化,系統會將相關評估結果標記為失效狀態並重新發起評估。

容量計算

  1. 容量狀態計算:容量使用水位 = 線上集羣 QPS/上探評估讀寫 QPS 上限,默認健康水位區間 [30%, 50%],小於區間下限表示容量冗餘,超過區間上限則容量不足(無法滿足業務常態化 2 倍流量的承載需求),水位線可按集羣維度自行調整。
  2. 容量建議計算:生成運維優化方案。當檢測到資源冗餘時,系統會計算出滿足容災要求下的具體可縮容節點;當發現資源不足時,則會自動計算出需要擴容的節點數量,並給出最優的機房分佈建議。

自動化運維

  1. 建議採納:一鍵式交互邏輯,觸發後台運維工作流,按容量建議自動完成運維動作。
  2. 風險控制:自動化運維鏈路具備可追溯、可觀測、可回滾能力,確保變更穩定。

6.3 效果展示

圖 11 容量運營-集羣容量使用水位明細

容量運營報告展示集羣主從、讀寫的容量使用水位以及容量建議,小美通過運營頁面直觀查看到所負責集羣的容量狀態,針對存在容量風險的集羣,按照系統給出的容量建議完成了數據庫擴容拆分工作,這一系列舉措簡化了以往復雜的評估流程,大幅提升了工作效率。

07 未來規劃

  1. 支持更多數據庫類型:現支持 MySQL 主從,未來將支持 MGR、Proxy 及美團自研分佈式數據庫 Blade、Elasticsearch 等。
  2. 輔助預算規劃:用户會根據當前資源使用和業務增長制定預算,但常忽略冗餘資源。我們將與預算系統結合,幫用户直觀瞭解當前冗餘情況,減少預算填報。
  3. 容量智能調優:自動完成集羣容量瓶頸分析與優化方案制定,並自動發起複測驗證效果,進一步提升系統效率。
  4. 案例庫構建:針對大促、事故等典型場景,能永久保留其案例庫鏡像,包括數據快照、SQL 流量以及集羣配置信息,能為混沌工程以及 MySQL 的長穩體系,提供真實在線案例流量。

| 關注「美團技術團隊」微信公眾號,在公眾號菜單欄對話框回覆【2024年貨】、【2023年貨】、【2022年貨】、【2021年貨】、【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞,可查看美團技術團隊歷年技術文章合集。

| 本文系美團技術團隊出品,著作權歸屬美團。歡迎出於分享和交流等非商業目的轉載或使用本文內容,敬請註明“內容轉載自美團技術團隊”。本文未經許可,不得進行商業性轉載或者使用。任何商用行為,請發送郵件至 tech@meituan.com 申請授權。

user avatar prepared 頭像 droxy 頭像
2 位用戶收藏了這個故事!

發佈 評論

Some HTML is okay.