本文分享自華為雲社群《【華為雲MySQL技術專欄】GaussDB (for MySQL)流控技術解讀》，作者：GaussDB 資料庫。
本文主要介紹GaussDB (for MySQL) 在不同服務層次上是如何實現過載保護的，具體包括反饋式和主動平滑流控兩種機制。
1.背景介紹
GaussDB (for MySQL)是儲存計算分離架構的雲原生資料庫，如圖1所示：
圖1 GaussDB (for MySQL)架構示意圖
GaussDB (for MySQL)存算分離架構，主要分為3層：
- SQL計算層，包括多個資料庫例項，每個例項有1個主節點和多個只讀節點
- DFV儲存層，由DFV儲存服務的多個節點組成，這些節點協同，為上層應用提供高效的日誌讀寫與頁面讀取能力
- SAL層，即儲存抽象層，位於SQL計算層和儲存層之間。其中位於計算節點的部分，稱為SAL-SQL層
DFV儲存層對資料按照slice進行分片（每個分片10G），SAL層則根據Slice粒度進行資料管理。
在計算層，不同租戶的多個資料庫例項會共享同一個儲存服務。當其中一個或多個使用者例項處於壓力過載時，可能會對共享儲存池產生衝擊，造成儲存服務的CPU、記憶體或者IO資源的瓶頸，進而影響服務穩定性。
GaussDB(for MySQL) 的過載保護機制分佈在SQL層、SAL層以及儲存層多個層級，能夠基於不同維度進行分級流控。
2. 分層級的流控機制
按照流量控制方向，GaussDB(for MySQL) 的過載保護分為兩種機制：第一種是由下層到上層的反饋式流控，即儲存層流控後，驅動計算層流控；另一種則是計算層主動流控，精細化控制上層流量。
2.1儲存層反饋式流控
儲存層的反饋式流控是儲存過載保護的主要機制。由於儲存服務的每個Server會管理不同資料庫例項的多個Slice，因此，需要在儲存節點級過載保護的基礎上，完成例項級、Slice級別的精確流控和分級限流。
整個流程概括為以下幾個步驟：
第一步，對儲存節點的關鍵資源和業務指標進行監控，並生成資源狀態、指標統計等；
第二步，在儲存層流控，基於以上狀態和統計進行策略判斷和決策；
第三步，將過載資訊反饋計算層流控。
2.1.1 儲存層流控策略
在儲存節點的訊息處理流程中，透過增加多處限流檢查點，分別觀測內部訊息處理佇列、任務佇列、記憶體資源。例如，回放日誌所需的Delta Cache、待處理Pending Table等，均可以作為輸入監控指標。
在以上的限流檢查點，可以採用多種策略進行控制：
第一種方式：透過關聯較少的資源，設定單一閾值進行限流，對上下游影響較小。這裡以盤級流控為例，如圖2所示，每個儲存節點管理多塊儲存磁碟，每個磁碟處理讀寫請求相互獨立。透過監控每個磁碟的讀寫頻率和讀請求時延，來判斷其是否超過閾值。如果超過，則為熱點盤。
熱點盤上有多個活躍Slice，如果某個Slice的寫速度超過平均速度，則按照階梯進行限速。圖中Slice4的寫入速度30MB/s超過平均速度20MB/s，因此，需要將Slice4進行限速。
圖2 盤級流控示意圖
第二種方式：對Delta cache，Pending Table等記憶體資源，進行使用率實時統計，識別出活躍Slice，再按照週期彙總計算出下一週期的可用配額，對當前活躍Slice進行公平分配；基於使用情況，可設定多個級別實施不同梯度的控制策略。例如，佔比60%為流控觸發點，進入基礎限流階段，設定80%為過載點，90%為停止服務閾值。其中，基礎階段採用線性流控，過載階段則採用比例限速。
如圖3所示，3個資料庫例項共有6個Slice分配到當前儲存節點，當前週期總的寫入速度是30MB/s, 平均分配給每個Slice 的配額是5MB/s。
圖3 Slice配額分配示意圖
第三種方式，對於節點的IO資源，系統也支援根據租戶設定的QoS（Quality of Service，即服務質量）閾值，來觸發流控機制。例如，對某租戶的Slice進行標記，在IO流控時，可以給予更大的配額。
基於上一週期的流控情況，迭代更新下一週期的流控策略，這樣能夠達到快速調整實時流控，並及時反饋到計算層，進而觸發計算層的流控。
SQL節點的使用者查詢需要及時響應，可視為前臺業務，而儲存節點內部的資料合併等操作，通常不需要及時響應，可作為後臺業務。針對前後臺業務的差異性，GaussDB(for MySQL)支援優先順序策略，並能夠識別故障元件並進行隔離，從而避免少量業務影響整個系統執行。
此外，流控後也能夠及時恢復，快速解除限流狀態。
2.1.2 計算層流控策略
儲存層流控時，通常設定每個Slice一個週期的可寫入流量上限閾值，即WAL閾值（Window Access Limit）。例如，當前時間視窗Slice1的寫入上限為2MB，SAL-SQL層查詢得到該上限閾值，基於此，可以在資料流轉過程中進行有效限速。
圖4 計算層兩個限流點示意圖
如圖4所示，計算層資料庫例項的限速點分佈在SQL層和SAL-SQL層。
第一個限速點在SAL-SQL層。SliceFlush執行緒將每個Slice的日誌傳送給儲存服務，此時，系統需要進行限速判斷，具體這裡包括以下幾點：
首先，Flush機制是積攢日誌量到一定數量（例如64K）或者一定時間後才會Flush，避免頻繁傳送過小的請求；
其次，判斷邏輯按照週期進行（目前週期為1s），根據每個週期的寫入量和寫入配額(即WAL，Write Access Limit)來決策，分為以下幾種情況：
- 如果待傳送的資料量小於當前週期的配額，則直接傳送
- 如果超過當前配額，且當前視窗配額沒有被預消費，則超發當前資料，並且預消費接下來週期的配額
- 如果當前視窗已經被之前的視窗預支，則需要補償，限流不傳送資料
另一個限流點是SQL層。在mtr（mini-transaction）提交時，檢查SAL層的流控狀態、內部資源情況，再結合Slice維度統計的日誌積累情況，進行多級別的流控策略。其中，主關鍵指標是TLB（Transport Log Buffer）的使用情況。TLB是SAL層內部按照Slice把上層寫入日誌整理合併，併傳送給一個Slice的Log buffer。詳細策略包括：
- 當內部資源處於基本限流階段，即mtr涉及到的Slice處於流控時，則系統會根據日誌積累量，換算出相應的等待時間，從而執行睡眠操作，以實現Slice的緩慢提交
- 當內部資源過載階段，則禁止提交mtr，直到過載解除
同時，按照相同順序進行限速和解除限速，避免不公平的限速導致某些執行緒餓死。
2.2 計算層主動平滑流控
單個資料庫例項在讀寫壓力過載，甚至超過資源瓶頸時，也可能出現雪崩現象，導致整體業務響應出現異常。例如，某種子業務突增，引發大量的併發批次讀請求，會導致同一例項的其他業務請求也受到影響，因此，對計算層進行流控也是必要的。
在計算層資料庫節點上，分別針對讀寫請求，進行細粒度平滑流控，可以避免計算節點本身過載。
首先，在SAL-SQL層，資料庫節點會統計每個週期的日誌寫頻率和頁面讀取頻率，作為核心指標。這些統計包括同步請求和非同步請求，將其統稱為頁面更新頻率。統計過程具體是在SAL層日誌寫鏈路和頁面讀取介面實現。
其次，根據資料庫節點的讀寫能力，按照不同規格預設合適的讀寫閾值上限。當統計到的頁面讀寫頻率超過對應的讀寫閾值時，觸發主動平滑流控機制。
圖5 主動限流在SAL層的兩個控制點示意圖
主要的控制邏輯分為兩種：
Strong限流，即需要當前執行緒sleep，直到指標降低到閾值內；
Weak限流，透過演算法計算出等待時間，並sleep一定時間。
目前有3個控制點：
- 第一個是Redo日誌加入SAL-SQL層排程執行緒時，如圖中限流點1所示，如果日誌寫頻率超過寫閾值時，則進行Strong限流，否則按需進行Weak限流
- 第二個是在每個Slice重新整理執行緒中進行Weak限流，如圖中限流點2所示
- 第三個是在頁面讀取鏈路中，根據頁面讀取頻率和閾值進行Weak限速
概括來說，等待時間是基於放大倍數和一個基礎步長來決定的。其中，放大倍數能夠快速放大等待時間，達到快速流控的效果。放大倍數是根據頁面頻率超過閾值的比例來決定的，目前設定4個級別，分別對應1-4倍。基礎步長是權衡效能消耗和流控靈敏度之後的一個預設引數值。
同時，在限速階段，採用序列佇列管理機制來處理並行提交的請求，確保按照先來的請求先得到處理。
3. 流控效果
為了演示反饋式流控，我們對多個資料庫例項同時進行壓力測試，包括：
- 2個8U，2個16U，13個32U規格例項，按照某真實業務讀寫比例1:4的業務模型進行sysbench讀寫壓測，每個例項64張表，單表1000萬行
- 5條資料遷移鏈路，其中5個32U規格例項作為目標端，插入資料。實驗過程中，透過人工降低儲存層流控觸值，模擬觸發流控場景
可以觀察到壓力上漲觸發儲存層流控後，較大寫入壓力的計算節點例項的QPS下降，系統處於限流狀態。恢復閾值後，限流狀態解除，業務QPS恢復，如圖6 QPS所示。同時，較小寫入壓力的計算節點例項，對QPS無影響，如圖7 QPS所示。
圖示資料對比說明，反饋式流控可以精準的控制大壓力資料庫例項。
圖6 反饋式流控大壓力例項QPS圖
圖7 反饋式流控小壓力例項QPS圖
接下來演示計算層主動平滑流控。
首先，對一個4U16G例項進行sysbench讀寫混合模式壓測，觀察其讀寫的頁面頻率指標。其日誌寫頻率為6093次/秒，頁面讀頻率為3195次/秒。
其次，透過運維平臺設定較小的讀寫閾值。
本實驗設定日誌寫閾值為4500次/秒，頁面讀閾值為3000次/秒，隨後可以觀察到很快觸發平滑限流，業務QPS快速下降，且較為平穩的維持在一個限流後的水位，並該狀態一直持續到測試結束，整體效果圖8所示。
圖8 主動平滑流控例項QPS圖
4. 小結
本文詳細分析了GaussDB (for MySQL) 在不同層級的流控機制，包括反饋式流控在儲存層和計算層的策略和流程，以及計算節點的主動平滑流控的方案。作為過載保護的主要手段，流控一方面可以避免流量過大造成服務資源耗盡產生雪崩效應，另一方面也力求高效快速，儘可能地充分利用服務資源，產生更大價值。
點選關注，第一時間瞭解華為雲新鮮技術~