作者介紹

陳培新，參與國信證券基礎平臺研發工作（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 多行給它並了一行，這樣的話整個表的資料量將近有一千多萬，查詢效率還可以。

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

圖：賬單 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 伺服器的試點。

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

圖：賬單 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 的話，一定要選擇好的磁碟，這樣才能確保處理效率。

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

相關文章