本文介紹了 TiDB 數據庫的資源管控技術，并通過業務測試驗證了效果。資源管控技術旨在解決多業務共用一個集群時的資源隔離和負載問題，通過資源組概念，可以限制不同業務的計算和 I/O 資源，實現資源隔離和優先級調度，提高系統利用率和穩定性。
業務背景
隨著業務對 TiDB 的使用不斷擴大和深入，在多業務共用一個集群的情況下，相信不少用戶也遇到過不同負載之間相互影響的問題。在之前的版本里，TiDB 也在嘗試不同的方法來緩解或解決這類問題。比較典型的例子就是通過引入 TiFlash 列存組件，在存儲引擎層面區分 TiKV 上的在線處理事務和在 TiFlash 上的分析型任務，在存儲層物理隔離不同的負載。這種架構優化有很多的好處，但如果業務都是需要訪問 TiKV 才能得到結果的場景，就沒辦法來處理。
我們線上十幾個生產集群，考慮成本、運維等問題都是多業務共用一個集群，在我們盡可能將 TP 業務和 AP 業務分離部署的前提下，通常還是會遇到下面的問題：
● 當一個業務處于高峰期時，會過多占用別的業務使用的資源，進而影響別的業務正常運行。
○ 我們希望能保護不同業務的資源持有情況，保證業務能分配到基本的運行資源而不被擠兌。
● 當集群中的重要業務處于低谷值時，有較多的剩余資源，如果我們能把錯峰的業務引進來就可以充分使用資源，可以降本增效。但這要求錯峰運行的業務需要能得到控制，其他時候不會占用過多資源。
● 當集群遇到臨時的問題 SQL 引發的性能問題時，只能停掉 S QL 。
○ 我們更希望不是干掉它的執行，而是臨時限制它資源消耗，允許它緩慢運行，但又不會影響集群其他業務。
在這樣的業務痛點背景下 TiDB v7.1.0 提出了資源管控技術，我們第一時間跟進該技術，并嘗試探討解決融合系統中多租戶資源使用的隔離方案。
TiDB 資源管控技術
資源管控技術（Resource Control）可以在負載劇烈變化時保證服務質量，同時提供了數據庫的多租戶隔離能力，能夠有效地降低數據庫運行成本。
2.1?原理說明
TiDB 資源管控特性提供了兩層資源管理能力，包括在 TiDB 層的流控能力和 TiKV 層的優先級調度的能力。將用戶綁定到某個資源組后，TiDB 層會根據用戶所綁定資源組設定的配額對用戶的讀寫請求做流控，TiKV 層會根據配額映射的優先級來對請求做調度。通過流控和調度這兩層控制，可以實現應用的資源隔離，滿足服務質量 (QoS) 要求。
● TiDB 流控：TiDB 流控使用 令牌桶算法 (?https://en.wikipedia.org/wiki/Token_bucket?)做流控。如果桶內令牌數不夠，而且資源組沒有指定 BURSTABLE 特性，屬于該資源組的請求會等待令牌桶回填令牌并重試，重試可能會超時失敗。
● TiKV 調度：可以為資源組設置絕對優先級 (PRIORITY)，不同的資源按照 PRIORITY 的設置進行調度， PRIORITY 高的任務會被優先調度。如果沒有設置 PRIORITY，TiKV 會將資源組的 RU_PER_SEC 取值映射成各自資源組讀寫請求的優先級，并基于各自的優先級在存儲層使用優先級隊列調度處理請求。
TiDB 資源管控技術利用資源組 (Resource Group) 將集群劃分為多個邏輯單元，每個資源組都能限制其所需的計算和 I/O 資源。當集群有空閑資源時，通過特定設置可以允許一部分資源組超越其限制，充分利用集群資源。它基本上解決了在多種業務合并后，造成資源爭搶的問題，保證了業務的穩定性。如下是該技術的一個概念圖：
Resource Control 是基于 TiDB 的流控和 TiKV 的調度功能來完成的。同時 BURSTABLE 功能允許其超過資源組的約束配額，使其可以保證服務正常運行。
2.2?管理方式
資源管控引入了資源組(Resource Group)的概念，通過設置“用戶”和“資源組” 的對應關系，把會話與用戶組進行綁定，利用“用量 (RU)”對資源限額進行定義。結構如下 (?https://tidb.net/blog/67d82266?）：
關于資源組、資源限額、調度優先級等特性具體可以參考官網(?https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control?）。
這里特地說明資源組設定是很靈活的，很方便管理員根據業務的使用場景，我覺得這也對 TiDB 的易用性有很好的提升， 分別設置不同的級別：
● 用戶級別。將用戶綁定到特定的資源組。綁定后，對應的用戶新創建的會話會自動綁定對應的資源組。
● 會話級別。通過 SET RESOURCE GROUP 設置當前會話的資源組。
● 語句級別。通過優化器 hint RESOURCE_GROUP() 設置當前語句的資源組。
2.3 技術應用點
總結之，該技術主要解決了下面業務常見問題：
● 當系統中存在多業務負載時，資源隔離，保證交易類業務的響應時間不受數據分析或批量業務的影響。
● 在系統負載較低時，繁忙的應用允許超過設定的讀寫配額，最大化利用資源，提升硬件利用率，降低運行成本。
● 限制突發 SQL 的資源消耗，避免引起集群性能問題。
● 提供用量統計的精確反饋，完成不同業務合理的成本分攤
○ 通過監控面板獲取實際用量的使用情況，協助用戶合理改進配置。同時，配合企業管理目標，TiDB 能夠協助企業精確統計各部門數據庫資源的使用情況，完成合理的成本分攤。
● 提供靈活的資源綁定手段。
○ 支持在用戶級，會話級，和語句級指定資源的綁定方式，滿足不同場景的資源控制需要。
經過梳理它的基本原理和設計目標等內容，看起來可以很好解決我們實際生產環境的業務痛點，所以我們開啟進一步的實際測試和驗證。
業務驗證
TiDB 可以基于硬件部署或實際負載估算集群的總體 RU 容量，我們在測試時是直接參考基于硬件部署的估算量。
3.1?業務資源模擬
為了模擬我們生產環境最常見的不同業務，這里我們創建三個租戶，分別表示三種不同的業務負載，每類業務有不同的管控目標。下表是我們的不同業務運行在同一個 TiDB 集群中，每個業務不同的運行需求：
在資源管控技術的基礎上，我們可以為這三類用戶分別創建資源組：
● 為租戶 app_oltp 分配一個較高的用量，租戶 app_olap 和 租戶 app_other 則相對低
○ 在系統資源緊張的情況下，最優先保證租戶 app_oltp 的服務質量。
● 租戶 app_oltp 和 app_olap 的資源組設置為 burstable
○ 租戶 app_oltp 發生超預期的負載，仍舊可能會保證質量；
○ 而當整個集群負載有空余時， 租戶 app_olap 可以利用空閑資源加速其工作。
● 創建資源組
CREATE RESOURCE GROUP IF NOT EXISTS rg_oltp RU_PER_SEC = 1000 BURSTABLE PRIORITY = HIGH; CREATE RESOURCE GROUP IF NOT EXISTS rg_olap RU_PER_SEC = 400 BURSTABLE; CREATE RESOURCE GROUP IF NOT EXISTS rg_other RU_PER_SEC = 100;● 我們線上的業務是已經存在了的，換言之上線該功能時業務賬號也一定是已經存在的，所以模擬時直接對業務綁定資源組
ALTER USER app_oltp RESOURCE GROUP rg_oltp; ALTER USER app_olap RESOURCE GROUP rg_olap; ALTER USER app_other RESOURCE GROUP rg_other;3.2?業務運行模擬
我們在測試環境啟動短連接業務實時訪問數據，不斷進行讀取和寫入操作，分別用來模擬幾個租戶不同的負載，觀測業務側吞吐量 (QPS) 和 數據庫 TiDB 的資源消耗情況 (RU 用量趨勢）。整個場景大概模擬下面幾個場景：
- 對有設置使用上限且正在運行的業務，在線調整集群資源分配操作：
a. 臨時擴大租戶 app_other 的可用資源，模擬臨時給在線業務增加資源
b. 臨時縮小租戶 app_other 配額，模擬臨時給在線業務縮減資源
c. 允許租戶 app_other 突破資源限額，模擬臨時取消在線業務資源使用限制
d. 不允許租戶 app_other 突破資源限額使其回到最開始的限額狀態，模擬臨時限制在線業務資源使用
- 模擬不同業務在同一個集群融合共存，觀察全部租戶經歷最重要業務的一個波峰、波谷完整周期的運行情況
a. 首先三類負載同時運行，表示業務正常共存情況
b. 業務流量高峰來臨，租戶 app_oltp 達到峰值負載
c. 租戶 app_oltp 峰值過去，回到平時狀態
d. 租戶 app_oltp 的負載到低谷值，其他不變
e. 租戶 app_oltp 低谷過去，回到平時狀態
在線增加/減少業務可用資源
對有設置使用上限且正在運行的業務，臨時調整租戶 app_other 的可用資源，模擬臨時給在線業務增加或減少資源。
● 初始：租戶 app_other 的業務初始資源配額
ALTER RESOURCE GROUP rg_other RU_PER_SEC = 100;● 擴大：臨時擴大租戶 app_other 業務的可用資源
ALTER RESOURCE GROUP rg_other RU_PER_SEC = 400;● 縮小：臨時縮小租戶 app_other 業務的可用資源
ALTER RESOURCE GROUP rg_other RU_PER_SEC = 50;
如上圖所示，可以看到租戶 app_other 的業務初始資源配額為 100，期間業務在穩定運行。
假設有某個原因需要我們臨時調大它的可用資源，此時調大可用資源 RU_PER_SEC = 400，業務能使用到的 RU?會立即響應?分配到需要的資源，曲線會不斷上升。反之我們縮小可用資源 RU_PER_SEC = 50 時，曲線會下降到我們預期的設定值。
● 總結：
○ 說明 TiDB 的資源管控技術可以在線調整業務資源使用狀態，實時對業務進行資源配置，大大提高業務響應速度。
○ 如果這類業務是突發的異常 SQL，我們可以臨時限制它的資源消耗，避免引起集群性能問題。
在線取消業務配額限制
允許租戶 app_other 突破資源限額，模擬臨時取消在線業務資源使用限制場景。
- 初始：租戶 app_other 的業務初始資源配額
ALTER RESOURCE GROUP rg_other RU_PER_SEC = 50;- 取消限制：允許租戶 app_other 業務突破可用資源的限額
ALTER RESOURCE GROUP rg_other RU_PER_SEC = 50 BURSTABLE;
如上圖所示，可以看到租戶 app_other 的業務初始資源配額為 50，期間業務在穩定運行。此時我們臨時取消它的可用資源限制，在集群收到配置后其 RU 曲線不斷上升，直到需要的最大值。
● 總結：
- ○ 說明 TiDB 的資源管控技術可以在線調整業務資源使用狀態，實時取消對業務資源使用限制
在線限制業務最大可用資源
不允許租戶 app_other 突破資源限額，模擬臨時限制在線業務資源使用
- 初始：允許租戶 app_other 業務突破可用資源的限額
ALTER RESOURCE GROUP rg_other RU_PER_SEC = 50 BURSTABLE;- 不允許突破限額：不允許租戶 app_other 突破限額
ALTER RESOURCE GROUP rg_other RU_PER_SEC = 50;
如上圖所示，可以看到租戶 app_other 的業務初始資源配額沒有限制，可以使用到其所需的最大資源，業務在穩定運行。此時我們臨時增加限制，不允許突破限額，在集群收到配置后其 RU 曲線不斷下降，直到回到最初的限制狀態。
● 總結：
- ○ 說明 TiDB 的資源管控技術可以在線調整業務資源使用狀態，實時添加硬上限，不允許業務突破限額
● 小結：
我們整理一下上面的模擬操作，如下面圖示過程，經過測試和驗證，證明 TiDB 的資源管控技術可以在線調整業務資源使用狀態，允許 TiDB 管理員根據業務運行動態，實時擴大、縮小、取消限額、添加硬上限不允許業務突破限額等操作，非常靈活和方便，大大降低運維的難度，也極大提高集群的資源使用效率。
跨業務共存測試
我們通過調整租戶 app_oltp 業務的壓測 QPS，產生出租戶 app_oltp 業務的波峰和波谷。這里我們模擬不同業務在同一個集群融合共存，所有業務經歷最重要業務的一個波峰、波谷完整周期，觀察運行情況。流程如下：
● 首先三類負載同時運行，表示業務正常共存情況
● 業務流量高峰來臨，租戶 app_oltp 達到峰值負載
● 租戶 app_oltp 峰值過去，回到平時狀態
● 租戶 app_oltp 的負載到低谷值，其他不變
● 租戶 app_oltp 低谷過去，回到平時狀態
如上圖可以看到，剛開始時集群的幾個業務正常共存，三類負載同時運行著。
● 租戶 app_oltp 達到峰值負載其業務流量高峰來臨，系統會分配給它更多的資源，于此同時由于集群可用資源不足租戶 app_olap 分配得到的 RU 有所減少，等到租戶 app_oltp 的峰值過去，租戶 app_olap 分配得到的 RU 有所增加回到最初的狀態。
● 經過一段時間后，租戶 app_oltp 達到其運行的業務谷值其所需要的 RU 下降，此時集群空閑 RU 增多，由于租戶 app_olap 設置的是 BURSTABLE， 允許突破限額使用資源，所以租戶 app_olap 的可用 RU 上升，等到租戶 app_oltp 的谷值過去，租戶 app_olap 分配得到的 RU 有所減少回到最初的狀態。
● 由于租戶 app_other 自始至終有配額限制且需要較少的 RU ，所以其穩定維持在一個較低的水平，不影響別的業務運行。
前面的過程我們是從集群資源使用的角度看的問題，現在換個視角從業務 QPS 角度來看，如上圖所示不同的業務的運行 QPS，基本隨著可用資源的增多而升高，隨著可用資源的減少而下降，服務業務預期。由此得出， 利用 TiDB 提供的資源管控和調度能力，多個不同訴求的租戶能夠共存在一套系統中，在保證各自服務目標的基礎上，提升資源使用效率。
總結
我們驗證了針對單個在線業務的資源調整，以及模擬了重要業務在經歷完整波峰、低谷的運行周期內各個業務的運行情況，每個要點的測試數據和結果都符合我們的預期，證明了該資源管控技術的可行性。同時也表明了：
● TiDB 的資源管控技術能動態跟蹤業務負載情況，實時分配所需的資源，證明其操作具有良好的實時性。
● 當系統中存在多業務負載時，能夠實現資源隔離，保證重要的業務不受其他訪問的影響。
● 在系統負載較低時，繁忙的應用允許超過設定的配額，能最大化利用資源，提升硬件利用率，降低運行成本。
跨業務系統多租戶解決方案
基于我們線上 TiDB 的使用方式，就可以制定出一個初步的跨業務系統多租戶解決方案，其他業務系統的部署架構需要具體情況具體分析。
這里使用 TiDB 多租戶技術，能完成多個業務系統使用統一的集群，保證不同業務負載相互隔離，互不干擾，互不影響，然后對于有統計分析類需求也可以再利用 TiFlash 的 實時 HTAP 能力，實現跨業務數據關聯查詢，這部分能力通過 TiFLash 與 TiKV 也進行了物理隔離，不會影響線上運行的 TP 業務。這個方案架構圖大致如下：
方案說明
● 根據不同的業務設置不同資源組和 RU，當集群整體資源繁忙時實現不同業務基于 RU 限流和負載隔離；
● 為重要業務設置資源組 BURSTABLE 屬性，實現跨業務錯峰資源借用；
● 為重要業務設置優先級為 HIGH，確保集群優先保證重要業務資源可用；
● 引入 TiFlash 解決實時數據分析需求；
● 如果業務有必要，還可以針對 tidb-sever 劃分不同的業務節點，真正達到整個集群的資源隔離
方案總結
●?優勢
○ 通過控制應用、會話、SQL 放入到對應的資源組中，高優先級的業務可以優先被滿足，剩余的算力可以去滿足次優的業務，達到資源的充分利用
○ 系統可擴展性強，在系統負載較低的情況下，繁忙應用即使超過設定的 RU，也仍然可以獲得所需的系統資源，從而提高了系統的可擴展性
○ 不同業務可以混合部署在同一個集群上，減少硬件成本
○ 不同業務錯峰使用資源，提升整體資源利用率，降低運行成本
○ 節約硬件成本
○ 高可擴展
○ 資源靈活管控
○ 解決數據孤島問題
●?劣勢
○ 資源劃分策略難以確定，先根據硬件情況估計分配，在運行一段時間后負載校準，再介入調整，這需要運維人員有很高的技術和經驗，容易出錯
○ 集群系統復雜度變高，要手動對集群資源池進行劃分和管理，增加系統的復雜度，維護難度變高
○ 系統復雜度高
○ 資源分配策略不好制定
未來展望
● 筆者在測試驗證中發現，資源如何劃分是一個比較棘手的問題，通過硬件配置校準 RU 的估算容量并不準確，真實容量往往偏差較大，所以需要我們先給較大的資源配額，觀察一段時間后通過負載校準得到真實 RU 消耗再設置正確值，如果這塊后續能夠更加智能、更加自動化，減少人工的介入可能會更完美，期待官方后續優化。
● 目前 RU 包括的資源是 CPU 、磁盤 IO 和網絡 IO，暫時還不支持內存資源的管控，期待后續官方把內存的使用管控也加進來。
● 調整資源組配置后，只對用戶新建的會話生效，我們線上不少業務是長連接，這會導致無法生效，期待官方后面也能優化這方面的內容。
