1. 背景

經過“雙11”、“618”這類網際網路促銷活動的驗證，越來越多的網際網路公司採用不定期營銷活動來刺激消費，達到提升營收能力的目標。然而，在每一次業務狂歡的背後，如何科學地為促銷活動準備相應的計算資源就變成了困擾開發人員的常態問題。此外，據Gartner統計，在疫情的影響下越來越多的企業開始加速關鍵業務模組從本地雲往公有云上遷移，以提升企業服務的穩定性和容災能力。如何有效評估並規劃計算能力、計算引擎、頻寬等關鍵資源的容量成為了雲場景下的一項技術挑戰。

針對這個場景，阿里雲資料庫自治服務團隊（DAS）推出了智慧壓測服務，致力於解決大促場景下計算資源評估問題、遷移上雲的離線資源容量規劃、跨引擎遷移等資料庫選型評估問題。DAS（Database Autonomy Service）是一種基於機器學習和專家經驗實現資料庫自感知、自修復、自優化、自運維及自安全的雲服務，幫助使用者消除資料庫管理的複雜性及人工操作引發的服務故障，有效保障資料庫服務的穩定、安全及高效，解決方案架構見圖1。

2. 智慧壓測的組成

壓測，即壓力測試，是確立系統穩定性的一種測試方法，通常在系統正常運作範圍之外進行，以考察其功能極限和隱患。一般針對網路伺服器測試從傳統的意義來講是對網路伺服器不斷施加“壓力”的測試，是通過確定一個系統的瓶頸或者不能接受的效能點，來獲得系統能提供的最大服務級別的測試。在資料庫場景下，壓測通常指的是對資料庫的效能進行測試，通過對資料庫伺服器不斷提高執行SQL的數量和併發度，來測試既定規格下的資料庫是否可以持續穩定地對外提供服務，並基於測試結果做出相應的決策，包括調整資料庫規格、部署形態、業務SQL優化等等。通常情況下，完成一次壓測主要涉及到三個關鍵部分：壓測資料準備、流量回放和結果分析，如圖2所示。

圖2 智慧壓測的關鍵組成

壓測資料：在資料庫場景下，流量資料為SQL語句，但僅有執行時SQL語句是不夠的。SQL語句在資料庫內的執行過程中，真實資料分佈和庫表索引都會影響其執行時間。因此，資料庫場景下，壓測資料包含了資料庫的庫表結構、庫表內資料、索引和SQL執行語句。此外，在一些有嚴格安全要求的特殊場景下，僅表結構允許複用，而具體原始資料不能被用於流量壓測。針對這種情況，我們提出了智慧生成資料的演算法，產出符合原始資料分佈的模擬資料用於回放。

流量回放技術：傳統效能壓測過程中，由於未對SQL執行語句按照原始流量的併發情況和執行次序做限制，出現壓測與原始業務流量效果差異較大的現象，導致單次資料庫資源評估任務中通常會進行多次壓測，然後對效能結果資料求平均後再評估資源。這種方法需要耗費大量的測試時間，並且需要測試人員具有一定的資料庫經驗，通常需要DBA進行操作。針對這一問題，DAS對單次壓測進行技術改進，通過壓測冪等技術確保壓測回放後的效能表現與原始業務流量效能相近，且無須多次回放，大幅節省了資源評估的時間並降低了對資料庫壓測經驗的要求。

壓測結果分析：有效的結果分析可以幫助使用者合理的選擇資源規格，並發現業務流量回放過程中存在的隱患。資料庫的關鍵效能引數、關鍵效能指標的對比、SQL優化建議等資料可幫助使用者理解資源差異和潛在優化點，輔助做出後續決策。

3. 智慧壓測技術內幕

3.1. 智慧資料生成技術

關於資料庫效能壓測，業界存在很多開源的工具，例如Sysbench、mysqlslap、tpcc等。這類工具均可以通過併發大量資料庫連線結合一定的查詢語句來製造出一定的SQL流量，達到模擬業務高強度使用資料庫的效果。但模擬場景下的效能表現通常和業務實際效能表現相差較大，故模擬壓測不能滿足計算資源評估的要求。利用業務資料庫中的真實資料進行壓測成為資源評估的基本條件。針對阿里雲資料庫使用者，可通過SQL審計功能，方便的獲取壓測所需要的資料。而對於雲下或阿里雲ECS自建資料庫的使用者，較難獲取歷史上的庫表資料或流量資料來做壓測，甚至在一些有嚴格安全資料要求的場景下，連原始資料和SQL流量資料都是不被允許使用的。

目前，我們在單表查詢場景下采用智慧資料生成技術來產出符合業務資料分佈的資料，可用於壓測並評估資源。這個演算法的前提是，需要我們已知一些SQL模版，以及這些SQL模版對應的執行指標，如RT，rows_sent，rows_affected等，我們希望例項化這些SQL模版來生成SQL，使得這些SQL在目標庫表上執行時能得到相似的執行指標（這裡我們假設同一模版的SQL都會以相同的執行計劃來執行）。如圖3所示，我們需要搜尋相應的引數a和b來例項化這條SQL模版，使得在給定資料執行時返回行數為1。

圖3 SQL模板

在搜尋SQL引數的時候，對於點查詢/點更新，可以直接利用主鍵和唯一鍵來做引數搜尋。而對於返回行數/更新行數大於1行的情況，我們使用基於取樣的基數估計方法來估計例項化後SQL的返回/更新行數，進而進行SQL模版例項化的引數搜尋。

圖4是我們對於釘釘一個讀寫業務在早高峰期的流量生成壓測，可以看到流量生成壓測和真實業務在多個指標上都有相似的表現，證明生成的資料可以有效的模擬線上真實資料。

圖4 基於生成資料的壓測效果

3.2. 壓測冪等技術

在資料準備完成之後，如何有效且可重複的進行流量回放是智慧壓測中的另一項核心技術。儘管業內已有的開源工具均可以通過併發大量資料庫連線結合一定的查詢語句來製造出一定的SQL流量，達到模擬業務高強度使用資料庫的效果。但是，在使用了真實的且有一定資料傾斜的業務模型之後，會發現一個比較嚴重的問題：假如多次測試同一個模型同一份資料在RDS MySQL下的效能效果，在資料有傾斜的情況下，兩邊的效能曲線很可能對不上。例如，第一輪壓測在A時間點查到了某一個數據，而第二次壓測很可能在B時間點才查到，這樣對分析問題就有了很大幹擾，如圖5所示，兩條曲線雖然壓力差不多，但是抖動頻率完全不一致，不利於分析。

圖5 同一個資料庫例項上跑兩次相同的測試模型的效果

針對這種情況，我們提出了壓測冪等的概念，即相同的測試，無論執行多少次，產生的SQL是完全一致的。在冪等情況下，每個時間點產生的SQL文字是完全相同的（假設資料庫處理能力完全一致），並且整個壓測任務中，所有SQL的執行順序是一致的。目前做到了執行緒級別完全一致，不同執行緒之間從效能和需求的角度考慮沒有實現強一致。

在冪等技術的加持下，DAS智慧壓測可以針對前文描述的場景可以做到一致性的壓測，效果如圖6。

圖6 同一個資料庫例項上跑兩次相同的智慧壓測的效果

壓測冪等的技術主要從壓測執行緒生成邏輯、總請求數、寫入最終一致性這三方面進行處理，讓壓測過程中可以確保每個執行緒內部出現的隨機數的順序都是一樣的，並且不同執行緒之間不一樣；通過保持執行緒中請求量總數一致，達到確保總請求量固定的效果；再結合自定義主鍵和約定update區間的方式，規避了自增主鍵和update衝突問題，確保了壓測結束後的資料最終一致性。

4. 產品落地

4.1. 產品流程

介紹完智慧壓測的組成部分和對應的核心技術之後，下面來看DAS是如何將智慧壓測落地成產品。從壓測的流程來看，整個智慧壓測的過程可以分為準備階段、SQL處理階段、回放階段和效果評估階段，如圖7所示。

圖7 智慧壓測產品流程

準備階段主要是解決壓測的機器環境問題，涉及從購買ECS機器、準備壓測目標例項、配置ECS機器上的執行環境等。目前DAS的智慧壓測可根據壓測流量的QPS和回放時長，自主選擇合適的ECS機器並自動配置執行環境，也允許使用者採用利用自有機器進行壓測。在準備壓測目標例項環節，現在DAS可通過RDS備份恢復、DTS同步的方式來自助幫助使用者準備好目標例項，也允許使用者自由指定壓測例項。

SQL處理階段則主要是對壓測使用的全量SQL明細資料做壓測前的資料準備，基於SQL洞察明細或者智慧演算法生成的SQL資料做預處理，包括prepared statement語句去重、日誌剔除、事務語句合併等等操作。

在回放階段主要是利用壓測冪等技術將流量進行回放，提供了實時的資料庫效能資料和壓測機器負載情況，便於使用者瞭解壓測進度。在此環節中，DAS將智慧調參演算法與壓測進行了結合，使用者可通過該功能實現引數調優的功能，具體演算法實現將在後續文章單獨介紹。

效果評估階段主要是解讀壓測過程中的指標資料，DAS對業務調優中常用的效能引數和關鍵效能指標做了對比，協助使用者做出資源評估決策。對於壓測過程中發現的慢SQL、鎖等問題，DAS也提供了相應的改進建議和處理方法，對使用者優化業務也提供了資訊輔助。

4.2 產品使用

使用者可以在DAS控制檯的左側選單“智慧壓測”進行使用，如圖8。目前DAS支援RDS MySQL和PolarDB MySQL壓測，其他關係型資料庫引擎的支援正在開發中。

圖8 智慧壓測介面

在壓測結束之後，使用者可以通過任務詳情檢視到目標例項與源例項的效能資料對比以及關鍵引數的對比，如圖9所示。

圖9 壓測後的效果對比

4.3. 產品計費

目前DAS智慧壓測功能未單獨收費，壓測流程中新建立的ECS、RDS均按照對應產品官網中以按量計費的標準進行計費，無額外服務費用。如前文所述，壓測依賴源端全量SQL明細資料或相應庫表基礎結構資料，故該服務僅需要壓測源端例項開啟DAS專業版功能即可。

4.4. 客戶案例

DAS智慧壓測服務自2020年上線以來，主要客戶為雲上頭部客戶，已累計為近百個客戶提供服務，主要包括上雲資源評估、業務大促評估、引擎切換評估、資料庫操作驗證等場景。

5. 未來規劃

接下來，智慧壓測將增加支援的資料庫引擎，覆蓋雲上的所有關係型資料庫引擎；同時，智慧壓測將會貼近客戶的真實業務問題，與使用者上雲、資源評估、引擎推薦等場景密切結合，並提供相應的壓測評估建議和報告，與企業客戶一起構建大規模場景下的資料庫容量規劃能力。

原文連結
本文為阿里雲原創內容，未經允許不得轉載。