TiDB 在國信證券海量資料高并發場景中的實踐

作者介紹

陳培新，參與國信證券基礎平臺研發作業（DevOps、微服務治理、Serverless）

國信證券是一家全國性大型綜合類證券公司，在 118 個城市和地區共設有 57 家分公司、185 家營業部，根據中證協發布的資料，近年來國信證券的總資產、凈資產、凈資本、營業收入、凈利潤等核心指標排名行業前列，

國信證券從 2020 年 6 月開始接觸 TiDB，從技術預研到第一個業務上線大約花了半年時間，第一個上線的業務是金太陽帳單，后面陸續在資料中臺、服務觀測等系統中應用，從只在東莞主機房的 TiDB 部署到 2021 年 9 月實作 TiDB 多機房的部署，并啟動國產海光 x86 服務器的試點作業，國信證券在開源 NewSQL 資料庫的探索和應用層面，積累了豐富的實踐經驗，目前，國信證券共有 7 個 TiDB 集群，節點數量 109 個，最大表 100 億，支撐了托管、經紀和自營等業務，

從 0 到 1，國信金太陽引入 TiDB

國信金太陽提供證券交易、理財和資訊相關的服務，我們使用證券軟體最主要的功能就是交易，在做交易的時候會比較關注收益率以及什么時候買賣股票，當前國信金太陽的用戶數大概有一千萬左右，在國信有一個大資料平臺，存盤了所有用戶歷年的交易資料，賬單存量資料有一百多億，清倉股票資料量大概是十億，整個帳單和清倉股票增量資料大概是二十億每年，

下圖是國信金太陽大概的服務架構，金太陽 App 直接連金太陽后端，后端架構基于國信自研的 gRPC 微服務框架構建，跟大多數券商系統一樣，金太陽后端對接柜臺系統，里面有交易、帳戶、清算等各種后臺應用，所有資料最后會推送到資料中心，資料中心每天或每周都會做跑批，跑批完之后，會將相關的資料推送到前端的資料庫中，App端通過查詢服務來查詢這個資料庫，從而獲取相關的帳單以及清倉股票的資料，

圖：國信金太陽資料服務架構

整個賬單經歷了三個版本，賬單 1.0 我們可以稱它為刀耕火種的時代，在 1.0 版本的時候，只支持一年賬單的查詢，使用的是單庫單表 SQL Server，具體是怎么實作的？首先，資料中心每天會將資料同步到一張臨時表中，然后進行資料轉換，這個臨時表的經過轉換后的資料會追加到正式表里面，正式表里面保存的是一年的資料量，在單庫單表的情況下，通過一個中間程式將所有一年的資料都壓縮到某一列里面去，里面是一個 JSON 字串，存的是一年 365 天的資料，那如果新一天有新資料來了怎么辦？后臺會起一個定時任務，將新的一天推過來的資料壓入到這個 JSON 里面去，再倒推 365 天，把以前最早那天的資料清除，最后再寫到正式表里面去，可以看到，這其實是一個非常原始的實作，為什么要使用 JSON 這種格式？因為我們的資料用戶量大概有一千多萬，如果是每天存一行的話，用單庫單表肯定是 hold 不住的，所以一開始，我們用了一個非常取巧的方式，將 360 多行給它并了一行，這樣的話整個表的資料量將近有一千多萬，查詢效率還可以，

圖：賬單 1.0 單庫單表實作方式

這種方式面臨的問題是：業務上，用戶希望查詢更長時間的資料，比如五年，使用單表的話，這個需求是難以滿足的，技術上，資料查詢以及后續的更新壓力大，難以擴展，有時候會出現資料更新出錯，第二天用戶來查詢的時候，查到的資料就不準確了，為了應對這些業務和技術難點，國信在賬單 2.0 版本使用 sharding-jdbc 來做分庫分表，在引入這個技術的時候，我們也聽說了 TiDB，考慮到證券業務對穩定性要求較高，當時對 TiDB 穩定性還有一定的擔憂，所以選擇了 sharding-jdbc，做了分庫分表之后，可以支持 5 年帳單的查詢，使用了 16 臺 MySQL，總共分了 512 張表，資料中心與分庫分表是如何進行同步的？資料中心還是和以前每天一樣，先把資料寫到臨時表，轉換服務會配置分庫分表的規則，從臨時表里面取資料，最后寫到正式表里面，資料中心有個 ETL 工具，但是它不支持擴展，所以就沒有直接寫入到正式表，

圖：賬單 2.0 分庫分表實作方式

大概跑了兩年時間，我們發現了新問題，分庫分表雖然可以滿足業務需求，但在擴展性方面有很大的約束，這些約束包括：第一，欄位擴展困難，我們分了 512 張表，如果要有新業務上來，需要新增一個欄位，這個時候 DBA 就會很痛苦，需要到每個分表新增欄位，第二，擴容極其麻煩，資料一開始預估不準確的話，后面分庫分表的規則就一定要變，從一開始 512 張表要變到再乘以 2，變到一千多張表，DBA 遷移的作業非常繁雜，而且很容易出錯，第三，同步還需要中間表，所以資料同步的時間也還是一樣的慢，并且制約系統上線時間，第四，分表的定時創建跟清理也比較繁瑣，每天會將一些日表刪掉，比如五年前的表，然后還要去創建第二天的表，在開發的時候，始終是要使用這個定時器來做清理和創建，第五，運維方面，也要運維多個資料庫，

分庫分表制給開發和運維帶來了額外的負擔，故我們把 TiDB 引入到國信里面來，使用 NewSQL 資料庫來支持 5 年賬單查詢，解決分庫分表帶來的問題，賬單跨入 3.0 時代，在這個架構下，資料中心每天直接將資料推到正式表里面，查詢服務直接查詢 TiDB，在查詢服務之上加了快取，引入 TiDB 后每天同步入庫的效率較以前提升了大概 70% 左右，當前 TiDB 已經在國信三地機房里面做了部署，同時在東莞機房最近也在做國產海光 x86 服務器的試點，

圖：賬單 3.0 TiDB 分布式資料庫實作方式

接下來談談一年多來 TiDB 相關的使用心得，從開發角度來看，首先是大資料量洗掉，一開始沒有經驗，還是按照以前老的套路，比如要洗掉指定某一天的資料，直接就是 DELETE SQL WHERE = “某一天”，當時是周六，運維告警顯示 TiDB 的機器依次逐個地掛掉，經排查發現是 DELETE SQL 涉及的資料量太大了，后續把事務大小調到 10G，TiDB 機器的記憶體擴展到 64G，這部分是系統層面的擴展；另外一方面我們也在應用程式側做對應改造，進行分批的洗掉，在有大資料洗掉的情況下，可考慮使用 Range 磁區表，直接 truncate 或 drop 磁區即可，

第二個經驗是對新上 TiDB 的業務，盡量要使用 AUTO-RANDOM 作為主鍵，對那種持續大量的插入場景，很大情況下可以避免插入的熱點，對于多機房資料同步，TiDB 需要主鍵或者唯一索引，無主鍵或者唯一索引會造成同步程式的 OOM，在表已有大量資料的時候，如果要加這個主鍵，整個程序也會比較麻煩，

三地高可用容災架構的實作

一開始只在國信東莞主機房作為試點去做 TiDB 的部署，后續運維要求 TiDB 要做容災部署相關的作業，應用要實作三地的高可用多活，之前每個機房的應用是訪問自己本地的 TiDB ，每個季度會做災備演練，驗證東莞整個主機房故障之后，異地上海與同城福田災備的可用性，

PingCAP 的老師一開始給了三個方案，第一個方案是最簡單直白的，在三個機房都部署一套單獨的 TiDB 集群，東莞機房做讀寫，用 TiCDC 或者 binlog 將對應的資料同步到其他兩個機房的災備集群，這個方案的優點是比較簡單，做災備演練的時候，如果東莞主機房掛了，其他兩個機房的應用基本上不用做什么操作，還是可以繼續使用，這個方案存在問題是副本數比較大，需要有 9 個副本，同步的時延可能也會大一點，

第二個方案是比較經典的兩地三中心，這個方案對于網路的要求比較高，而且如果東莞機房掛了，福田機房要做一下手動恢復，第三個是同城雙中心，把東莞跟福田當成一個集群，將資料同步到上海災備集群，也就是兩個集群，但這個方案在做災備演練的時候做恢復也會比較復雜，

圖：多機房方案對比

經過三個方案的對比，最后國信還是采用了最簡單的 binlog 同步方案，每個機房部署一個 TiDB 集群，當然這也是根據業務特點來實作的，國信的業務基本上使用查詢，不會存在多個機房同時寫入，所以最后采用了這個最簡單的方法，在多機房部署實作的程序中做了一些遷移匯入的作業：一開始 TiDB 只在東莞機房部署，因為對于 TiDB 的使用不熟悉，有一些業務表是沒有加主鍵或者沒有唯一索引，福田機房搭建新的 TiDB 集群之后，我們發現在做兩地集群同步的時候，同步器就直接 OOM 了，這是因為沒有加主鍵或唯一索引導致的，當時有一張最大的表已經到 60 多億了，如果直接在表上加主鍵或者唯一索引的話其實是不可能的，

那我們是怎么做到的呢？首先使用 Dumpling 將這個表匯出到 CSV 檔案，這個 CSV 檔案的命名是帶有表的名稱的，在匯出完成之后在原來的資料庫上面去創建新表，里面加上主鍵或者唯一索引，再把匯出的這兩個 CSV 檔案重命名跟新表一樣，然后通過 Lightning 把資料匯入到這個新的表里面，最后把舊表和新表給重命名，把這張新的表命名為正式表，正式表重命名為備份表，這樣做的話可以盡量的減少對業務的影響，在匯入匯出的程序中，用戶基本上是無感的，圖：無主鍵表處理

服務可觀察的探索

最后談談在金太陽服務可觀察方面的探索，應用在使用了微服務架構之后，部署的節點會非常多，而且呼叫鏈整個程序也非常復雜，這個時候想定位一個問題就會很復雜，根據業界當前比較流行的 “服務可觀察” 概念我們做了一個應用來輔助開發的問題定位，這個 “服務可觀察應用” 主要是包含三個部分，一個是日志，第二個是指標，最后一個是跟蹤鏈，我們針對日志部分做了增強，把系統的請求和回應日志通過 ETL 工具轉換到 TiDB 里面，然后做了可視化相關的作業，

圖：金太陽服務的可觀察性

可視化部分是開發一直提的需求，采集了日志一般都是在 ELK 的 Kibana 里面看，都是一些文本，這是非常不直觀的，我們做的優化是對于每個微服務的請求跟回應日志我們都匯入到 TiDB 里面，用 “服務可觀察” 應用去做展示，如果客戶有什么問題，輸入客戶的手機號就可以很直觀地看出這個客戶在某個時間段做了什么操作，從而可以很快定位問題，同時我們也將內容和回應進行可視化，看起來更加方便，當時在做 TiDB 入庫也遇到一些問題，因為這個業務特點跟賬單不一樣，賬單基本上都是每天晚上做插入，白天用戶做查詢操作，但是該日志可視化則是在開市期間（上午九點到下午三點多）會做持續大量的插入，查詢操作較少，有問題的時候才上去做查詢，這是一個運維相關系統，所以沒有用很好的磁盤，系統上線后就發現整個 TiDB 變得非常卡，一開始以為是插入的程式或者查詢程式有問題，我們做了很多優化，發現還是不行，最后升級完磁盤之后發現整個性能獲得了直接的提升，我們得到的經驗就是上 TiDB 的話，一定要選擇好的磁盤，這樣才能確保處理效率，