TiDB 7.1 多租戶在中泰證券中的應用

本文詳細介紹了中泰證券在系統國產化改造專案中採用 TiDB 多租戶技術的實施過程。文章分析了中泰證券資料庫系統現狀以及引入 TiDB 資源管控技術的必要性，探討了 TiDB 多租戶的關鍵特性，並闡述了在實際應用中的具體操作步驟。透過該技術的應用，中泰證券有效降低了運維成本，提升了開發效率。 文章強調了 TiDB 多租戶在證券企業中的應用優勢，特別突出了其在資源觀測、複用、可配置性等方面的價值。

專案背景

中泰證券股份有限公司（原名齊魯證券有限公司）成立於 2001 年 5 月，是國內排名前 20 的全國大型綜合性券商，在全國 28 個省市自治區設有 45 家分公司、280 多家證券營業部，員工 9000 多人，控股中泰期貨、中泰資本、中泰金融國際、中泰資管、中泰創投、齊魯股權交易中心、萬家基金，形成了證券、期貨、基金、投資等各項業務齊頭並進的發展格局。

受國際環境影響，在國家政策的大力支援下，系統國產化開始在全國範圍內加速落地。中泰證券在系統國產化改造專案中，使用 TiDB 和國產化作業系統、晶片，提升自主可控能力。

中泰科技研發部目前使用兩套 TiDB 叢集，將多套業務系統進行集合。TiDB 叢集版本號均為 V7.1。按照業務系統服務物件的不同，分別承載對外和對內客戶業務。基於 TiDB 對大表的支援性更友好，無需分庫分表，複雜 SQL 的效能提升明顯，TiDB 的彈性擴縮容，簡單易運維操作。這些，都毫無疑問地降低了運維成本、提升了開發效率。但是這兩套叢集都是多套業務系統共用，因此，非常需要資源管控技術，確保每一個業務系統都擁有獨立的資源池。

TiDB 多租戶介紹

TiDB 6.6 首 次引入資源管控（Resource Control，簡稱：RC）特性，並在 TiDB 7.0 進行了最佳化和增強。該技術利用資源組 (Resource Group) 限制每個資源組所能使用的計算和 IO 資源，同時創造性的引入 burst （可超用）屬性，當叢集有空閒資源時，允許資源組超越限制，實現資源的充分利用。

這個特性滿足了目前一些企業的需求，也可以順帶解決了部分使用者的痛點：

1. 業務系統間影響和干擾 ：某個業務系統的非預期負載變化會影響其他業務系統的正常執行。
2. 分析業務對交易的影響 ：對資源需求較高的資料分析或批次作業會影響其他業務系統的響應時間。
3. 運維操作對資源的消耗 ：資料備份、統計資訊收集等後臺任務可能會影響服務質量。

具體應用和實施

以下文章內容中的資料均基於生產環境做過修改，不是真實資料，僅供參考。

3.1 資源評估

開啟 Dashboard 頁面，在左側選單列表中找到 Resource Manager，在 Estimate Capacity 中 根據標準測試型別進行資源評估。

3.2 應用繫結 RU

透過梳理資料庫中的業務使用者，確定哪些使用者是屬於哪些業務系統，方便後面將不同的資源組與不同的使用者繫結。

執行以下 SQL 為業務 A、業務 B、以及管理員繫結 Resource Control 和 RU。業務 A 和業務 B 同屬於 TP 系統，業務重要性較高，對 sql 查詢速度和效率都有一定的要求，對慢查詢容忍性較低。所以對業務 A 和業務 B 的資源分配優先順序要高一些，並且允許資源超用（BURSTABLE），應對前端業務流量的突增。而管理員賬戶日常主要用來做資料庫管理相關的工作，很少或者不涉及業務 SQL，所以資源分配優先順序較低，可以先設定成允許資源超用。

初步繫結都設定 BURSTABLE 屬性確保每個業務都有充足 RU 可以使用，避免資源不足情況而無法觀察到某個業務真實 RU 消耗情況。

-- 建立A資源組
CREATE RESOURCE GROUP IF NOT EXISTS a_rg RU_PER_SEC=180000 PRIORITY=HIGH BURSTABLE;
-- 建立B資源組
CREATE RESOURCE GROUP IF NOT EXISTS b_rg RU_PER_SEC=90000 PRIORITY=HIGH BURSTABLE;
.....
-- 建立管理員查詢資源組
CREATE RESOURCE GROUP IF NOT EXISTS admin_rg RU_PER_SEC=20000 BURSTABLE;
-- 為不同業務系統使用者繫結資源組
-- 將A資源組繫結到A業務系統使用者上
ALTER USER a_user RESOURCE GROUP a_rg;
-- 將B資源組繫結到B業務系統使用者上
ALTER USER b_user RESOURCE GROUP b_rg;
.....
-- 將管理資源組繫結到系統管理使用者上
ALTER USER admin_user RESOURCE GROUP admin_rg;

3.3 觀察應用 RU 使用情況

完成繫結後 ，TiDB 可以實時統計到各個業務消耗的資源情況。生產執行一段時間後，需要觀察業務實際消耗 RU， 完成後續調整。

依然是去 Dashboard 頁面，在左側選單列表中找到 Resource Manager。這個頁面較之前業務系統使用者沒有繫結 RU 之前，多了一個 Configuration 模組。可以在這裡模組清晰的觀察到每個資源組的詳細資訊。

繼續在 Resource Manager 頁面中找到 Metrics 模組，觀察 RU 的使用情況（建議觀察時間區域儘可能長，以得到更全面的 RU 消耗情況），如下圖所示。

將這個曲線和上面 Configuration 模組的 RU 資訊對照，檢視是否需要進行 RU 調整。調整語句如下：

-- A業務系統最高消耗 17000 RU ，建議繫結 25000 RU ，預留一定 Buffer ，由於總體資源充足設定 BURSTABLE 屬性確保業務有足夠資源
alter resource group a_rg RU_PER_SEC=25000 PRIORITY=HIGH BURSTABLE;
-- B業務系統最高消耗 14000 RU ，建議繫結 20000 RU ，預留一定 Buffer ，由於總體資源充足設定 BURSTABLE 屬性確保業務有足夠資源
ALTER RESOURCE GROUP b_rg RU_PER_SEC = 20000  BURSTABLE;
-- 設定管理員查詢資源組，不設定 BURSTABLE 屬性，降低管理員執行 Slow Query 時對叢集影響
alter resource group admin_rg RU_PER_SEC=10000;

RU 使用收益

由於目前 TiDB 伺服器資源充足，並且各個業務系統的峰值谷值都具有同一性，每個業務系統的重要程度也差不多。所以 TiDB 這個多租戶特性帶來的價值主要體現在資源的可觀測性和可配置性上。

在資源可觀測性上 ：有了 RU，結合 Dashboard，可以清楚的觀察到每個業務系統使用了多少資源，TiDB 整個叢集資源是否充足，是否需要新增資源。

在資源可配置性上 ：TiDB 多租戶最重要的能力是在資源繁忙時實現資源控制，後續繼續遷移新業務導致資源不足且臨時沒有伺服器新增到叢集的場景下可以線上解除 BURSTABLE 屬性，給業務設定合適的 RU 大小來實現資源控制。此能力可以線上調整，對業務幾乎無感知。在資源不足的極端場景下，能夠控制不同使用者的資源消耗，保證各業務系統的資源隔離性，使用者可以安心使用 TiDB 多租戶能力。

結語

大部分企業會給 TiDB 叢集預留充足資源，此時利用 BURSTABLE 屬性實現資源觀測和資源複用；小部分企業無法給 TiDB 叢集預留充足資源，此時可以線上修改多租戶配置並實現資源控制。

目前，在證券企業中，許多業務系統跑在不同的 MySQL 叢集上面。隨著 MySQL 5.7 生命週期結束以及 IT 基礎設施國產化改造的推進，把存量的多套 MySQL 叢集歸集到一套 TiDB 叢集成為一個理想的解決方案。透過 TiDB 的資源管控特性，多個業務能夠共享一套叢集，實現資源的有效利用。對比傳統多租戶方案，TiDB 多租戶除了基礎資源控制能力以外還提供了更強大的資源複用能力、資源可觀測性、線上可配置性、線上限流等能力。可以更好降低整體硬體成本、減少多叢集運維成本、觀測資源池使用率。