導讀
本文探討了金融企業區域集中庫的設計構想和測試驗證，包括架構設想、數據庫整合場景測試及優勢和使用設想。作者提出利用 TiDB 數據庫產品集中建設區域集中庫，解決 MySQL 存量節點的整合問題，實現部署的標準化、按需擴展和統一運維管理。文章詳細介紹了測試內容和結果，強調了區域集中庫在建設和運行成本、服務質量等方面的優勢，並提出了相應的管理措施，爲金融企業數據庫架構提供了有價值的參考 。
本文作者 ：
邵 健 ｜杭州銀行股份有限公司數據庫專家
張顯華丨杭州銀行股份有限公司數據庫專家
區域集中庫的架構設想
在銀行等金融企業的網絡設計中，會根據服務主題將內部網絡分割成若干個網絡安全域，如：核心網絡域、網銀網絡域等。在各個網絡域中，根據業務應用對數據庫的需求配置資源。隨着業務的創新和發展，MySQL 存量節點多，管理難度大，資源利用率低，背離了規模部署、高效運維、敏態供給的雲化發展理念，在生產運行的各階段中存在不少的能力短板，比 如：
- 部署建設階段
- 以業務發展目標或者每日批量壓力高峯進行數據庫資源規格評估，可能存在資源浪費和發展不同步的可能性。
- 不同的版本、部署方案、變量參數和管理平臺共存， 配置的碎片化不利於團隊知識管理，阻礙標準化發展。
- 生產運行階段
- 應用數模設計階段缺少主鍵約束造成主從同步延遲，影響從庫數據時效，高可用機制可能存在不穩定。
- 業務應用重複訂閱全行統一的人員、機構和客戶等主數據推送，浪費存儲容量，佔用數據庫和網絡資源。
- 數據庫面對下游業務的數據供給需求，複製鏈路構成較爲複雜的網狀結構，管理和維護成本較高，客戶上限制了數據價值的進一步挖掘。
TiDB 數據庫產品具備良好的水平擴展能力，能滿足高併發大數據量業務的使用需求。通過 resource control 特性可劃分集羣資源，承載不同的業務應用。設想在單個網絡域中集中建設一套 TiDB 集羣，進行當前業務的遷移，整合替代“孤島式”的 MySQL 集羣（見圖一），實現部署的標準化、按需擴展和統一運維管理。
圖一 “孤島式”的 MySQL 集羣和分佈式數據庫區域集中庫演進設想
數據庫整合場景測試
基於網絡區域集中庫的設計構想，進行實際整合場景的需求抽象，使用 TiDB 做爲測試平臺，驗證在分佈式數據庫上快速創建不同規格的數據庫服務以提高設備利用率，並通過標準化高可用等管理體系降低總體成本。
2.1 資源管控
Request Unit (RU) 是對 CPU、IO 等系統資源的統一抽象的計量單位，用於表示對單個請求消耗的資源量。請求消耗的 RU 數量取決於多種因素，例如操作類型或正在檢索或修改的數據量。
- 集羣資源的評估
測試集羣配置爲三臺兩路 ARM 服務器。使用 oltp_read_write 模型估算集羣的 RU 上限爲 163000 RU（見圖二）。
圖二 oltp_read_write 模型容量估算的標籤頁
使用 TPCC 模型估算爲 459000 RU（見圖三）。
圖三 TPCC 模型容量估算的標籤頁
使用 root 用戶進行 oltp_read_write 模型高併發壓測可得集羣最大 RU 365000（圖四）。
圖四 單個 root 用戶測試的 RU 消耗監控面板
三種評估方法結果（見表一）表明，估算和實際的差距較大，估算方法需要改進。
表一 評估方法結果
- 不同規格 RU 對聯機交易的影響
配置三個資源組的每秒 RU 參數 （見圖五），數據庫用戶歸屬於資源組後，每秒使用的 RU 上限受該參數控制。
圖五 三資源組測試的資源組容量
三個用戶對應三個資源組同時壓測，RU 使用平穩（見圖六）。
圖六 三資源組測試 RU 消耗監控面板
壓測結果（見表二）表明，實際使用上限基本符合配置，QPS 與 RU 成正比關係，符合配置規則。
表二 資源組每秒 RU 規劃的業務測試結果
- 資源組 BURSTABLE 屬性對調度的影響
配置資源組 test_rg1 啓用可突發（BURSTABLE）屬性（見圖七），當系統資源閒置時，該資源組可以超出上限。
圖七 burstable 屬性測試的資源組容量標籤頁
先發起 test_rg1 資源組中用戶的壓測，RU 使用達到了 293000 左右，體現 burstable 參數在集羣空閒狀態下的配置效果，再發起另外兩個資源組的壓測，test_rg1 逐步回落到資源組配置上限 160000 左右（見圖八）。
圖八 資源組 burstable 屬性測試的 RU 消耗監控面板
壓測結果（見表三）表明，BURSTABLE 屬性可以充分利用閒置資源。繁忙時，會優先保證上限內的 RU 分配。
表三 資源組 burstable 屬性的業務測試結果
- 在線調整 RU 對聯機交易的影響
發起 test_rg1 組中用戶的壓測，在線調整資源組的每秒 RU 值，即時反應到實際 RU 使用（見圖九）。
圖九 在線調整資源組測試的 RU 消耗監控面板
壓測結果（見表四）表明，資源組配置變更即時反應到業務的 QPS 上。
表四 在線調整資源組測試的業務測試結果
2.2 讀寫分離
在 MySQL 架構中，爲防止對業務主交易造成影響，將從庫用於數據抽取、異步檢查等只讀場景。區域集中庫也需要實現等同於讀寫分離的隔離效果，分佈式數據庫配置 Learner 角色，只參與同步數據而不參與多數派投票。
使用 Placement Rules 將 33 節點的 TiKV 實例標籤配置爲 Learner 數據副本，監控中對應實例的 Leader 數量爲 0（見圖十），只同步數據，不響應交易的讀寫請求。
圖十 各個 TiKV 實例的 Leader 數量分佈監控面板
- 會話的讀寫分離
設置變量 set session tidb_replica_read=‘learner'，執行查詢 SQL 時只使用 33 節點的資源（見圖十一）。
圖十一 TiKV 實例 CPU 監控面板
- 物理備份的讀寫分離
使用 --replica-read-label 參數執行 br 備份命令，只使用 33 節點寫入備份文件（見圖十二）。
圖十二 備份寫數據監控面板
2.3 業務管理
多業務整合的場景中，不僅需要關注資源開銷，還需要關注數據庫的業務管理特性，比如 SQL 黑名單、細粒度監控、連接標識等，提升管理員的運維效率。
2.3.1 SQL 黑名單功能
- 資源組的自動策略
配置 default 資源組屬性 query_limit=(exec_elapsed='100s', action=kill,watch=similar )，實現語句執行超過 100s 後自動 kill。慢 SQL 語句執行超時後被 kill（測試效果如下），說明自動策略可以支持慢 SQL 的自動化管理。
MySQL> select now();select *,(select max(c) from sbtest2 where sbtest1.c=sbtest2.c group by id ) avgc from sbtest1 where sbtest1.id< 5000;select now();
+---------------------+
| now() |
+---------------------+
| 2024-02-05 15:33:15 |
+---------------------+
1 row in set (0.000 sec)
ERROR 1105 (HY000): other error: Coprocessor task terminated due to exceeding the deadline
+---------------------+
| now() |
+---------------------+
| 2024-02-05 15:34:55 |
+---------------------+
1 row in set (0.000 sec)- 手工配置黑名單
配置 query watch 清單 query watch add action kill sql digest 'DIGEST 值'中。SQL 語句執行後提示被中斷（測試效果如下），說明可以支持慢 SQL 的手工管理。
MysQL> select *,(select max(c) from sbtest2 where sbtest1.c=sbtest2.c group by id ) avgc from sbtest1 where sbtest1.id< 100;
ERROR 8254 (HY000): Quarantined and interrupted because of being in runaway watch list查詢驗證限制記錄（測試效果如下），說明可分析黑名單生效記錄。
MySQL> select * from mysq1.tidb_runaway_queries order_by time desc limit 1\G
*************************** 1. row ***************************
resource_group_name: default
time: 2024-02-05 14:57:37
match_type: watch
action: ki11
original_sq1: select *,(select max(c) from sbtest2 where sbtest1.c=sbtest2.c group by id ) avgc from sbtest1 where sbtest1.id< 100
plan_digest: 85484f90b715278bd114095a4bbbe168da158f24e824a04d11c09be7268fe2ab tidb_server: 10.186.136.31:4000
1 row in set (0.002 sec) 2.3.2 業務會話標識功能
- 會話變量
會話變量 tidb_session_alias 可動態定義會話中業務標識，如當前運行的交易碼信息，會話視圖、慢日誌及 General log 的 session_alias 列中會記錄運行值，類似 Oracle 數據庫 v$session 的 module 列可以幫助識別應用程序功能模塊信息。
編輯測試描述文件 oltp_read_write.lua，添加 con:query("set tidb_session_alias='QUERYXXX'")，模擬應用切換交易碼。慢日誌（見圖十三）和 processlist 視圖（見圖十四）中 session_alias 標識 SQL，可分析 SQL 語句的業務行爲。
圖十三 慢日誌中的業務標識
圖十四 processlist 視圖的業務標識
- 會話屬性
系統視圖 session_connect_attrs 可查看連接的固定屬性信息，數據庫側可用於梳理應用的自定義連接信息。配置連接串參數 connectionAttributes=app_name:bank,ver:v1.0&（見圖十五）或者使用 JDBC 內置方法，實現應用版本等標識。
圖十五 Jmeter 的連接串配置
系統視圖 session_connect_attrs 可查看應用的自定義屬性（見圖十六），說明可分析客戶端信息。
圖十六 系統視圖中的客戶端屬性
2.3.3 細粒度監控功能
配置 record-db-label 可以在 db 和 resource_group 粒度上提供 QPS、Duration 等 metrics 指標，在 grafana 添加監控面板（見圖十七）。
圖十七 細粒度的 QPS 和 Average Duration 監控面板
2.4 測試小結
通過以上的測試，基本上驗證了利用分佈式數據庫實現區域集中庫的設想：
- 資源隔離特性具備數據庫規格限制，支持用戶、會話及語句等粒度。在線調整即時生效的特點，可以基於不同業務資源消耗的時間窗口進行資源“調度”，實現資源利用效益最大化。
- Learner 角色副本可用於數據抽取、查詢和備份等場景，保證生產隔離，節省“從集羣”的資源開銷。
- 通過規則和已知的 SQL 指紋對不良 SQL 能實現有效防範。
- 通過業務會話標識和細粒度監控功能，基本滿足應用整合後的觀測需求。
- 集羣 RU 評估方法、Query Limit 策略添加掃描行數或 RU 資源使用監控、資源組添加時間計劃等有待繼續改進。
區域集中庫的優勢和使用設想
區域集中庫是將數據庫整合落地在數據庫層，通過標準化部署和細粒度資源配置，得到更高的服務可用性、規格彈性和資源利用率。兩種整合方式的適用情況對比如表五。
表五 區域集中庫特性對比
表五 區域集中庫特性對比
綜合各個能力項對比結果，評估區域集中庫在建設和運行成本、服務質量上均具有較大的優勢。在使用過程中，需要配套管理措施：
- 開發建設典型業務壓測模型（如轉賬交易）作爲標尺，根據該模型得到集羣交易性能上限，按典型業務性能設計成多個規格，再由需求方根據該模型評估業務交易性能需求規格和業務批量窗口特點進行對接。
- 統一管理區域集中庫的全行主數據，數據團隊只需要接入一次數據，實現資源集約使用。
- 利用單副本的 Learner 節點實現讀寫分離，對接備份、ETL 抽取、數據查詢平臺等非業務的數據需求。
- 與行內的低代碼開發平臺進行對接，通過框架的配置功能使用數據庫的會話屬性和業務會話標識功能，實現更加有效的 SQL 定位和管理。
- 引導應用運維自助查看資源組監控和細粒度日誌。
通過區域集中庫的建設整合，將簡化數據庫能力分層模型（圖十八）。
第一層關鍵業務使用兩地三中心的分佈式數據庫。
第二層高併發大數據量業務使用獨立的分佈式數據庫。
第三層規模較小或者業務發展規模較靈活的業務使用區域集中庫。
圖十八 數據庫能力分層模型
通過區域集中庫的建設，實現數據庫部署架構的收斂。在此基礎上，可進一步對業務數據操作行爲的採集和分析，有利於生產運行向智能化轉型。