導(dǎo)讀
資源隔離是數(shù)據(jù)庫性能優(yōu)化的重要環(huán)節(jié)，TiDB 在當(dāng)前版本已經(jīng)實現(xiàn)了從數(shù)據(jù)級隔離到流控隔離的全面升級，無論是多系統(tǒng)共享集群、復(fù)雜負(fù)載隔離，還是小型系統(tǒng)整合和 SQL 精細(xì)化控制，TiDB 都提供了靈活且高效的解決方案。
本文以實際案例為切入點，詳細(xì)解讀了 Placement Rules in SQL、Resource Control 等關(guān)鍵功能，以及 7.2+ 版本新增的 Runaway Queries 管理機制，幫助各位開發(fā)者和管理員選擇最適合自己的 TiDB 資源隔離方案。
1. 你需要什么樣的隔離？
2. 基于數(shù)據(jù)的隔離方案
2.1 中大型系統(tǒng)之間隔離
2.2 系統(tǒng)內(nèi)不同負(fù)載隔離
3. 基于流控的的隔離方案
3.1 數(shù)據(jù)庫用戶隔離
3.2 SQL 語句級別隔離
3.3 后臺任務(wù)級別隔離
4. 總結(jié)
時至今日，TiDB 提供的隔離能力愈發(fā)完善，上到不同系統(tǒng)、下到 SQL 語句，均能實現(xiàn)良好的隔離效果。本文旨在幫助大家了解：你需要什么層面的資源隔離，以及各種層面隔離如何使用。
2.1 中大型系統(tǒng)之間隔離
在提及資源隔離時，大家往往想到的是：多個系統(tǒng)共用一套集群，如何限制每個系統(tǒng)所用的資源。在之前版本中，TiDB 提供了基于 K8s的 Cloud TiDB 方案，但企業(yè) DBA 很少同時具備 K8s和數(shù)據(jù)庫兩種技能；另外企業(yè)中 K8S 大部分也非原生，不一定滿足 Cloud TiDB 的部署需求。
從 6.5 版本開始，TiDB 提供了 Placement Rules in SQL 功能，一種基于 SQL 規(guī)則的數(shù)據(jù)放置策略，可以輕松實現(xiàn)數(shù)據(jù)級別的物理隔離，使得多個系統(tǒng)共用一套 TiDB 集群時，滿足物理層面隔離的需求。
2.1.1 典型場景：多系統(tǒng)共用集群并完全獨占資源
典型客戶案例：TiDB x 云盛海宏丨加速精細(xì)化運營，云海零售系統(tǒng)的架構(gòu)演進(jìn)
示例：Placement Rules in SQL 規(guī)則（適合中大型系統(tǒng)）
createplacementpolicypolicy_orderconstraints="[+zone=order]";
createplacementpolicypolicy_invconstraints="[+zone=inventory]";
alterdatabaseretail_orderplacementpolicypolicy_order;
alterdatabaseretail_inventoryplacementpolicypolicy_inv;
2.1.2 典型場景：每個系統(tǒng)僅獨占一個實例、單點故障時共享
典型客戶案例：某領(lǐng)先零售企業(yè) TiDB 生產(chǎn)集群架構(gòu)
示例：Placement Rules in SQL 規(guī)則（適合中型系統(tǒng)）
createplacementpolicypolicy_server1leader_constraints="[+host=host1]";
createplacementpolicypolicy_server2leader_constraints="[+host=host2]";
createplacementpolicypolicy_server3leader_constraints="[+host=host3]";
alterdatabaseDB1placementpolicypolicy_server1;
alterdatabaseDB2placementpolicypolicy_server2;
alterdatabaseDB3placementpolicypolicy_server3;
2.2 系統(tǒng)內(nèi)不同負(fù)載隔離
以上是多個系統(tǒng)之間的隔離，在一個業(yè)務(wù)系統(tǒng)內(nèi)，同樣也會有基于負(fù)載的隔離需求（如 OLTP 和 ETL/報表兩種負(fù)載）；也就是過去常提及的讀寫分離，在一套數(shù)據(jù)庫內(nèi)，實現(xiàn)兩種負(fù)載的隔離。
在使用 TiDB 時，由于一套集群已經(jīng)由多臺服務(wù)器組成，如再建設(shè)一套配置相同的備集群來實現(xiàn)，此時成本相對是比較高的。從 6.5 版本開始，也可以輕松使用 Placement Rule/Placement Rules in SQL + Follower 副本讀取策略來實現(xiàn)，同時與傳統(tǒng)主備/主從讀寫分離相比：TiDB 的只讀區(qū)域（含 TiKV/TiFlash）可提供與聯(lián)機完全一致的查詢能力。
2.2.1 典型場景：聯(lián)機事務(wù)處理+ETL|BI 隔離
典型客戶案例：HTAP 還可以這么玩？丨TiDB 在 IoT 智慧園區(qū)的應(yīng)用
示例：
- Placement Rules in SQL 規(guī)則（針對業(yè)務(wù)數(shù)據(jù)，Leader 分布在前兩臺 TiKV）；
createplacementpolicypolicy_eyasleader_constraints="[-zone=zone3]";
alterdatabaseeyasplacementpolicypolicy_eyas;
- Placement Rules in SQL 規(guī)則（針對運營數(shù)據(jù)，Leader 分布在第三臺 TiKV）；
createplacementpolicypolicy_bileader_constraints="[+zone=zone3]"follower_constraints='{"+zone=zone1":1,"+zone=zone2":1}';
alterdatabasebi_eyasplacementpolicypolicy_bi;
alterdatabaseda_pingplacementpolicypolicy_bi;
alterdatabaseeyasbiplacementpolicypolicy_bi;
- 業(yè)務(wù)庫+運營庫均增加列存副本；
- TiDB 設(shè)置就近讀。
setglobaltidb_replica_read='closest-replicas';
2.2.2 典型場景：聯(lián)機事務(wù)處理+復(fù)雜查詢隔離
典型案例：2 機房雙活+1 機房就近只讀
注：zone 是 tikv 中一個 label 的定義，可以代表一個真實的機房，也可以單機房集群中設(shè)計一個 zone
示例：
- Placement Rule 規(guī)則（設(shè)置全局 Leader 和 Follower 分布策略），機房 q03 不分布任何 Leader，同時 q03 機房進(jìn)行本地讀?。?/li>
[
{
"group_id":"pd",
"id":"q01",
"start_key":"",
"end_}
]
- TiDB 設(shè)置就近讀。
為了解決以上不足，TiDB 自 7.1 版本起引入了基于流控的隔離方案 - Resource Control，目的是簡化分布式架構(gòu)中資源管理的復(fù)雜度：
- 將 CPU、IO、網(wǎng)絡(luò)等資源統(tǒng)一抽象為資源單位（RU），大幅簡化對資源的定義
- 提供數(shù)據(jù)庫用戶、SQL 語句、后臺任務(wù)等三個層面的資源隔離
- 在擴容或縮容時，資源調(diào)整可以秒級生效，無需遷移數(shù)據(jù)，提供了極致彈性能力
總的來說，Resource Control 是一種更靈活高效的資源管理方式，不僅能夠?qū)崿F(xiàn)多系統(tǒng)、多負(fù)載的隔離，還可以進(jìn)行 SQL 語句和后臺任務(wù)層面更精細(xì)化的控制。
3.1 數(shù)據(jù)庫用戶隔離
3.1.1 典型場景 - 小型系統(tǒng)整合
在我過去的經(jīng)歷中，我發(fā)現(xiàn)小型數(shù)據(jù)庫系統(tǒng)普遍存在資源利用率較低的情況。實際上，我們在申請數(shù)據(jù)庫資源時，往往基于直覺或者標(biāo)準(zhǔn)化配置來選擇資源，背后可能并沒有一個明確的依據(jù)。另外，多個系統(tǒng)通常負(fù)載峰值時間各不相同，在使用傳統(tǒng)方案時也只能根據(jù)最大峰值+冗余的方式來申請資源，不可避免會出現(xiàn)較多資源閑置。
TiDB 的 Resource Control 方案，使得我們能夠在較小的配置下實現(xiàn)更高效的資源利用率。將多個小型數(shù)據(jù)庫系統(tǒng)整合到 TiDB 后，每個系統(tǒng)的資源分配可以根據(jù)其實際負(fù)載峰值、QPS 等需求進(jìn)行精細(xì)化管理；如果在這些系統(tǒng)中存在一個消耗資源較高的系統(tǒng)，還可考慮分配單獨的 TiDB 計算實例供其使用。
典型客戶案例：TiDB 7.1 多租戶在中泰證券中的應(yīng)用
3.1.2 典型場景 - SaaS 場景
在以上第三種多租戶架構(gòu)中，多個租戶共用一個庫、同時共用一套表，表內(nèi)通過分區(qū)來存儲不同 SaaS 租戶的數(shù)據(jù)，或直接使用單表（通過表內(nèi)的 tenant_id 字段來區(qū)分），此時 TiDB Resource Control 可以輕松通過數(shù)據(jù)庫用戶來為不同租戶進(jìn)行資源控制。
而面對 SaaS 動輒數(shù)千個租戶的需求，TiDB Resource Control 是極其有幫助的，無需劃分 CPU/內(nèi)存/節(jié)點數(shù)量，可創(chuàng)建數(shù)據(jù)庫用戶級別的資源組，輕松管理不同租戶的資源需求和彈性需求：
示例：
- 假設(shè)租戶 1 是體量非常大，可為其單獨創(chuàng)建數(shù)據(jù)庫用戶 user1，并為該用戶創(chuàng)建獨立資源組，優(yōu)先級高，且允許超用；
CREATERESOURCEGROUPrg_tenant1RU_PER_SEC=1000000PRIORITY=HIGHBURSTABLE;
alteruser'user1'RESOURCEGROUPrg_tenant1;
- 其他租戶由于體量較小，共用一個資源池；
CREATERESOURCEGROUPrg_tenant_defaultRU_PER_SEC=500000PRIORITY=MEDIUM;
alteruser'user_default'RESOURCEGROUPrg_tenant_default;
- 擴容。
ALTERRESOURCEGROUPrg_tenant_defaultRU_PER_SEC=900000PRIORITY=MEDIUM;
3.1.3 典型場景 - 系統(tǒng)內(nèi)批量負(fù)載隔離
典型客戶案例：MySQL 到 TiDB 遷移實踐：云盛海宏零售業(yè)海量場景下 ToC 系統(tǒng)的選型思考與經(jīng)驗分享
在一個系統(tǒng)中往往會存在聯(lián)機和批量兩種負(fù)載，如聯(lián)機的峰值在白天，到凌晨基本上是業(yè)務(wù)低峰期，此時可以安全的運行系統(tǒng)內(nèi)的大型批量作業(yè)，進(jìn)行大規(guī)模、高密度的讀寫，以盡快完成批量作業(yè)，進(jìn)而不影響白天的聯(lián)機業(yè)務(wù)。
但有些情況下，批量可能會跑到第二天業(yè)務(wù)高峰期，此時停止這個批量顯然是不太合適的，但放任它繼續(xù)消耗大量資源執(zhí)行，顯然也是不合適的。
在過去其實缺乏一些庫內(nèi)的管控手段的，只能在調(diào)度層、應(yīng)用層進(jìn)行有限控制。而 TiDB Resource Control 也可以輕松管理這種情況。
示例：為批量作業(yè)單獨創(chuàng)建用戶，并綁定資源組：
CREATEUSER'USER_BATCH'IDENTIFIEDBY'******';
CREATERESOURCEGROUPrg_batchRU_PER_SEC=UNLIMITEDPRIORITY=HIGH;
alteruser'USER_BATCH'RESOURCEGROUPrg_batch;
--假設(shè)批量任務(wù)超時運行到第二天白天，只需執(zhí)行如下SQL即可立即將其限速
ALTERRESOURCEGROUPrg_batchRU_PER_SEC=100000PRIORITY=LOW;
3.2 SQL 語句級別隔離
自 7.2 版本以來，TiDB Resource Control 引入了對 Runaway Queries（即執(zhí)行時間或消耗資源超出預(yù)期的查詢）的管理功能：
- QUERY_WATCH（手動處理）：對發(fā)現(xiàn)的 SQL 進(jìn)行限流或熔斷
- QUERY_LIMIT（自動處理）：當(dāng)不符合預(yù)期的 SQL 出現(xiàn)時，數(shù)據(jù)庫可自己識別、并自適應(yīng)處理
3.2.1 典型場景 - SQL 限流與熔斷（QUERY_WATCH）
有一些 SQL 語句可能存在這種情況：編寫不規(guī)范或需要查詢大量數(shù)據(jù)（如抽數(shù)），它們在運行時可能會消耗大量的資源，我們希望它們跑慢一點沒關(guān)系，但不要消耗太多資源影響正常業(yè)務(wù)請求。在 TiDB 中，可以輕松通過 Resource Control 來對它們進(jìn)行限流：
--該SQL執(zhí)行時，單獨使用rg1資源組執(zhí)行（rg1是一個100RU的資源）
SELECT/*+RESOURCE_GROUP(rg1)*/*FROMtwhereis_delete=0andcreate_time>='2023-01-01';
--將default資源組中的這條SQL進(jìn)行降低優(yōu)先級，讓其限速執(zhí)行
QUERYWATCHADDRESOURCEGROUPDEFAULTACTIONCOOLDOWNSQLTEXTEXACTTO'select*FROMtwhereis_delete=0andcreate_time>='2023-01-01';
另外也可能存在一種情況，系統(tǒng)內(nèi)突然出現(xiàn)一條之前從未運行過的大 SQL，它來歷不明，我希望先直接將其熔斷，不讓其執(zhí)行：
--根據(jù)SQLDIGEST維度進(jìn)行攔截，并終止
QUERYWATCHADDRESOURCEGROUPdefaultACTIONKILLSQLDIGEST'd08bc323a934c39dc41948b0a073725be3398479b6fa4f6dd1db2a9b115f7f57';
--另外還可以使用SQLTEXT維度（可單獨攔截某一特定條件值的SQL）
--以及PLANDIGEST維度（可攔截SQL中某一很差的計劃出現(xiàn)）
3.2.2 典型場景 - 超出預(yù)期的查詢自適應(yīng)管理（QUERY_LIMIT）
基于 QUERY_WATCH 的限流和熔斷方案，屬于事中或事后的人工處理手段。從問題的出現(xiàn)、發(fā)現(xiàn)到最終解決，這一過程往往需要一定的時間；即便是經(jīng)驗豐富、對系統(tǒng)非常熟悉的管理員，在解決完問題時，往往已經(jīng)過去了數(shù)分鐘，甚至更長時間。這意味著，業(yè)務(wù)可能受的影響時間也會與之相關(guān)。
而 QUERY_LIMIT 則提供了更加靈活的自適應(yīng)處理手段，讓數(shù)據(jù)庫可以自動發(fā)現(xiàn)異常并處理異常，我們只需要定義異常即可：
示例：
- 創(chuàng)建 rg_auto_cooldown 資源組，限額是 100000 RU，我們可以定義該資源組中執(zhí)行時間超過 60 秒的查詢?yōu)?Runaway Query，并讓系統(tǒng)自動對 Runaway Query 進(jìn)行降低優(yōu)先級限流處理；
CREATERESOURCEGROUPrg_auto_cooldownRU_PER_SEC=100000QUERY_LIMIT=(EXEC_ELAPSED='60s',ACTION=COOLDOWN);
- 創(chuàng)建 rg_over_10000資源組，限額是 100000 RU，我們可以定義該資源組中每秒超過 10000 RU 的查詢?yōu)?Runaway Query，并讓系統(tǒng)自動對他們進(jìn)行降低優(yōu)先級限流處理；
CREATERESOURCEGROUPrg_colldownRU_PER_SEC=100000QUERY_LIMIT=(RU=10000,ACTION=COOLDOWN);
- 還可以在當(dāng)前資源組，將大型查詢隔離到其他資源組執(zhí)行：定義 default資源組中處理數(shù)據(jù)行數(shù)超過 1000000 的查詢?yōu)?Runaway Query，并讓系統(tǒng)自動將他放到 rg_bigquery資源組中執(zhí)行，避免與當(dāng)前資源組中的請求發(fā)生爭用。
CREATERESOURCEGROUPrg_bigqueryRU_PER_SEC=10000PRIORITY=LOW;
--假設(shè)我當(dāng)前資源組為default
ALTERRESOURCEGROUPdefaultQUERY_LIMIT=(PROCESSED_KEYS=1000000,ACTION=SWITCH_GROUP(rg_bigquery));
3.3 后臺任務(wù)級別隔離
在日常運維過程中創(chuàng)建索引是一個常見的工作，雖然在 TiDB 中所有 DDL 均是在線的，但我們也不能忽視創(chuàng)建索引時資源消耗帶來的風(fēng)險。自 7.4 版本開始，TiDB Resource Control 引入了對后臺任務(wù)的管理。
示例：
以創(chuàng)建索引這一 DDL 任務(wù)為例，可以設(shè)置 ddl 為后臺任務(wù)，并且限制其最多可使用 TiKV 節(jié)點總資源的 30%。此時系統(tǒng)便會動態(tài)地限制該任務(wù)的資源使用，以盡量避免此類任務(wù)在執(zhí)行時對其他前臺任務(wù)的性能產(chǎn)生影響：
ALTERRESOURCEGROUP`default`BACKGROUND=(TASK_TYPES='ddl',UTILIZATION_LIMIT=30);
目前 TiDB 支持如下幾種后臺任務(wù)的類型：lightning、br、ddl、stats 等。
通過本文的學(xué)習(xí)，相信大家對 TiDB 的資源隔離能力有了更全面的理解；大家可以根據(jù)不同的場景需求，選擇合適的資源隔離方案。
如果您有新的資源隔離需求或場景，歡迎與我們聯(lián)系。
熱門跟貼