本文根據安信證券資深數據庫架構師李軻在 DevCon 2022 上的分享整理，主要講述了 TiDB 在安信證券的資產中心與極速交易場景的實踐經驗。主要包括三部分內容：第一是國產化信創改造總體情況，第二是 TiDB 在安信證券的一些實踐情況，第三是實踐過程中我們遇到一些問題的反饋和建議。

安信證券股份有限公司（以下簡稱“安信證券”）成立于 2006 年 8 月，并先后于 2006 年 9 月、12 月以市場化方式收購了原廣東證券、中國科技證券和中關村證券的證券類資產。安信證券總部設于深圳，全國設立 50 家分公司，320 家營業部和 370 個營業網點。安信證券現為全牌照綜合類券商，多項業務排名進入全國前列，連續 10 年獲得 A 類 A 級以上行業分類評級，其中 2011 年至 2013 年達到行業最高的 A 類 AA 級。2020、2021 年安信證券連續獲評 A 類 AA 級。

今天分享的議題主要是 TiDB，所以就給大家介紹一下 TiDB 這個產品，TiDB 是原生分布式數據庫架構設計，是由 PD 以及 TiDB 和 TiKV 組件組成。PD 層主要是作為數據調度、事務調度以及 TiKV 的元數據的存儲。TiDB 層是無狀態的 SQL 計算引擎，因為它是無狀態的，所以對于后期的擴展需求有良好的支持。第三層的 TiKV 負責具體的數據落地存儲，TiKV 節點之間通過 Raft 協議進行數據同步，所以 TiDB 整體架構是以 TiDB 作為 SQL 計算引擎，TiKV 作為落地存儲的存算分離架構。

安信證券的國產化改造的架構選型，服務器采用了 Taishan 服務器，底座我們是選用了鯤鵬 920 CPU 搭載運行的是麒麟 V10 操作系統，在上面運行分布式數據庫 TiDB，整體架構是基于 ARM 體系。在硬盤的選擇上，因為 TiDB 對讀寫性能要求比較高，所以在 TiKV 和 PD 節點選擇了額外的 NVMe 盤作為存儲，TiDB 節點使用了傳統的 SSD。

下面來介紹 TiDB 實踐具體的應用案例。第一個是安信客戶資產中心系統，這個系統是一個能夠覆蓋全賬戶類型、全產品、全交易行為（1500 多種不同交易行為）、所有交易狀態（20 多種交易狀態）的數據共享中心，業務范圍主要是滿足客戶的查詢賬戶資產以及了解投資收益的各種場景需求，用數據幫助客戶完成自我驅動的財富管理，覆蓋了公司 700萬+ 的全用戶數據，服務查詢性能平均響應時間在 50 毫秒以內。這個系統的改造訴求主要是高可用、穩定、落地持久存儲這些方面的需求。

整個項目的改造歷程分為四個階段，第一階段是在 2021 年一季度我們做了可行性分析和驗證，包括一些 TiDB 集群性能的初步驗證，還有一些數據的同步延時。在去年一年我們做了總體的技術方案設計，包括初步的開發設計、并行驗證、初步的系統上線、業務的初步連通性驗證和具體實施。在 2022 年一季度，我們做了下游系統的改造，包括一些業務代碼以及系統對接等方面的開發。在 2022 年底我們已經完成了全部流量切換和備中心搭建。

可以看到這套系統的改造前后，主要是針對日間變化數據這套原來基于 Lamda 技術架構做了改造，現在換成基于 TiDB 技術架構，下圖表示具體的數據鏈路改造的變化。

左側初始架構是從 OGG 到 kafka 再到 Spark Streaming 的流式處理，最后到 redis 進行落地存儲的消息流處理模式架構, 右側則是改造后的由四個組件現在簡化成由 AR 數據導入導出的同步工具，再最終落地到 TiDB 進行數據存儲。

改造的目的主要是出于五個方向考慮，總體也可以分為運維角度和業務兩個角度。

第一，降低運維難度。原架構的數據鏈路比較長，設計上是從原來的柜臺 DB 到 OGG 然后再到一系列的大數據組件，最后落地到 redis。隨著組件的增多，出問題的概率會比較大一點，并且對運維人員技術棧的儲備要求較高，后續的運維難度也比較大。大數據開源組件的特性在使用中有可能造成在一些業務場景數據的丟失，會影響到客戶的使用體驗。現在升級改造之后，數據鏈路換為柜臺 DB 到 AR 數據同步工具，然后再落入到 TiDB ，極大地簡化了一個數據流轉鏈路，也簡化了技術架構，相較之前運維也較簡便。TiDB 是一個關系型數據庫，對 DBA 來說運維技術的過渡轉換也是十分方便的，加上 TiDB 的強一致性也可以保障寫入數據的高可靠。

第二，性能容量提升。原有架構以 redis 作為最終數據落地存儲，設計初始更多的是基于高可用的出發點進行設計，用了哨兵模型進行部署。而證券行業特點使流量負載和流量峰值很難預測，原有的架構設計在一些業務峰值的數據承載以及性能上會有一定的瓶頸，特別是在數據峰值比較大的時候，如果需要擴展，對架構的改動較大，風險也相應提高。原有架構在線水平橫向擴展能力上不足，缺少對逐漸增加的業務流量承載能力。TiDB 可以支持在線水平彈性擴展，最主要的特點就是彈性擴展對業務是無感知的，如果說缺少計算方面的能力，那么直接擴展 TiDB 節點即可，如果數據量增多，可以直接擴展 TiKV ，并且擴展只需增加節點數，不需要對原有架構進行改動。

第三，縮短應急處理周期。之前的架構因為大數據組件比較多，特別是 kafka 的消費以及重試機制，如果出現問題的話，因為其流式架構設計，出現故障的時候第一我們要定位，第二在時間點的處理方式上我們可能會基于更早的時間點去進行消息重放，需要有一定的時間去進行消息處理，從而進一步拉長應急處理周期，降低故障處理速度，我們發現在一些應急處理場景并沒有達到預期。改造后，在出現故障的時候可以通過 AR 導數工具快速將指定時間的數據恢復到下游 TiDB，能在很短的時間內將業務恢復，提高系統的運維連續性和可用性。

前三點主要是從運維角度出發的，后兩點更多是從業務和開發角度去進行改造。

也就是第四點，簡化數據流轉復雜度。之前是使用 redis 作為最終的數據落地存儲，這塊第一我們在一開始設計的時候沒有打算做長期的存儲保留，而源數據端柜臺 DB 是傳統型關系數據庫，例如 DB2、Oracle 以及 MySQL，從柜臺數據同步到 redis 會經過一些數據轉換，從結構化數據轉換到 KV 結構數據，對于下游的開發、設計也會增加了復雜度。現在轉為 TiDB 后，同樣都是關系型數據庫架構，從柜臺 DB 到 TiDB 的數據結構對于開發團隊來說沒有什么太大的區別，直接進行開發使用，簡化數據流轉復雜度，提高開發的靈活度。

第五點，支持歷史查詢以及復雜分析。隨著業務發展不斷增加的需求，例如報表分析等。原來的架構無法滿足我們將來的一些復雜分析以及客戶的特定需求，業務痛點基于原有架構很難去解決。改造成 TiDB 之后，首先單集群能夠支持 200TB 以上的數據量，可以進行歷史數據的長期存儲， TiFlash 分析引擎可以很好地支持復雜分析，OLTP 和 OLAP 事務分離，也可以跟我們的大數據棧進行無縫銜接，支持后續業務發展。

接下來我們來看實時資產項目的部署架構，2022 年南方主中心生產上線，每臺機器上部署了兩個 TiKV，是一個 32 的架構，PD 和 TiDB 采用混合部署，也是 3(1PD*2TiDB) 的架構設計，在 TiDB Server上層做了 HAProxy ，負責流量的接入以及負載均衡的調度。2022 年底已完成部署深圳備中心。TiDB 數據主要是通過 binlog 方式將主中心的數據進行同步。

以上就是客戶資產中心系統的改造總體情況，接下來介紹 ATP 極速交易系統。

ATP 極速交易系統作為安信證券首批的交易系統改造是比較慎重的。對這個項目的系統改造要求也比較特殊，這套系統改造是一個全面的國產化改造，要支持國產化服務器、操作系統甚至是路由器，包括一些前端應用全部都是國產化的設計。作為交易系統所以改造的最終訴求就是適配性好、業務改造簡單，而源端的數據庫原來使用的是 MySQL，TiDB 對 MySQL 的兼容性好，可以降低原有開發團隊的適配難度，只要把數據直接導入再進行相應的適配開發。交易系統的定級也需要滿足證券行業的兩地三中心的技術要求。

ATP 的整體項目進度還處在上線及試用階段，預計要在 24 年中才會根據改造進度和業務需求進行大規模的客戶遷移和流量接管。

ATP 極速交易業務架構是采用三中心部署。項目比較有特點的地方就是它是一個自底向上全國產化方案，一般的項目改造可能只是針對服務器以及數據庫進行替換。而 ATP 系統是從底層網絡的交換機到服務器以及 CPU，還有操作系統和數據庫全部采用產品。在上層應用，也采用華銳的 ATP 國產化版本，包括機構交易平臺和分布式高性能計算平臺。

這套系統主中心的應用組件采用主備高可用部署方式，組件間實時同步保持強一致性，只要有單點故障的出現，可以實現自動切換，滿足 RPO=0，RTO<10 秒的要求。也能支持系統的水平擴展，作為一個極速交易系統，核心訴求就是快，進行國產化改造之后，需要保證交易時延也要與原來的系統一致。所以在低時延這塊，也能做到微秒級的全鏈路時延。

接下來看具體的部署架構。以南方主中心，深圳科技園備中心，上海金橋災備中心形成一個兩地三中心，一主兩備的級聯部署。備中心和災備中心的配置類數據是通過 TiDB 本身數據庫的 binglog，以異步同步的方式進行數據同步。考慮到時延和性能， 各機房會處理自己的交易類數據，然后直接落盤到本地庫，這樣可以保證交易數據快速地入庫以及對外提供服務。

在網絡環境上采用了華為的交換機，接入交換機是采用雙機的組網，配置 V-STP 模式對外提供服務，同時配置了雙活網關，對于業務網絡來說，把交換機鏈路單獨劃分出一個 VLAN，專門用來業務網絡使用。交換機三層與核心交換機進行互聯，通過靜態以及動態路由實現兩地三中心業務的互通。

TiDB 的整體使用收益，我們從兩個業務場景看。第一個是資產中心，資產中心受益的地方，就是極大地精簡了數據流轉鏈路，把原來多個大數據組件的一套架構，改造成 TiDB 一個國產化數據庫，承載的功能不變。數據處理流轉比較簡單，從傳統的柜臺關系型數據庫到 TiDB 是關系型到關系型，對于開發使用也比較友好。TiDB 提供數據的強一致性保證，支持后續的高并發聯合查詢、水平擴展、復雜分析、開發需求等等。對于極速交易來說，TiDB 首先滿足全棧國產化和全功能兼容的要求，從原來的 MySQL 切換到 TiDB，功能上和兼容性來說是都是不錯的。其次，TiDB 支持兩地三中心的高可用部署，也滿足高可用需求。

最后分享一下 TiDB 在安信證券實踐過程中遇到的一些問題，以及具體是我們怎么做的，希望這些能給大家一些啟發。

首先第一點，就是數據讀寫熱點。TiDB 的底層存儲 TiKV 的數據是以 region 為單位進行存儲，在 region 上按照 key 值有序追加，如果不做特殊處理的話，數據會一路往后面追加，在高并發場景下比較容易產生讀寫的熱點。因為數據比較集中，讀事務與寫事務都會集中在一塊資源上，會產生讀寫熱點。對于這個問題，我們的建議是在進行表結構設計時，盡量使用 Auto Random 方式的自增主鍵，把數據打散，分散存儲，可以減少熱點沖突的現象。

第二點就是 TiDB 內部組件資源爭用的現象。這個場景比較特殊，因為我們的業務場景是有很多的 DDL。在大量 DDL 場景操作下，TiDB 的 region cache 可能會因為某些內在機制沒有及時清理，后續的 SQL 查詢語句進來的時候，可能會找到實際上已經不存在，但是它認為沒有被清理的region。當SQL語句發現數據不存在時，就去尋找下一個可能存在的region，這種情況導致 SQL 執行時間就被不斷拉長，使SQL 執行效率下降進而影響到集群的其他語句，最終表現形式就是業務處理性能下降。我們的處理方式是將 DDL 的應用與其中的一個 TiDB server 進行綁定，也就是將 DDL 場景以及語句進行聚合，盡量爭取是在一個 TiDB server 進行處理，然后其他的業務 通過 HAProxy 進行負載均衡，把其他的一些讀事務分發到其他的 TiDB server 進行處理，減少 DDL 事務與讀事務之間的影響，從而保障讀性能。

第三就是鎖沖突。大部分企業都是從傳統的 Oracle、MySQL 以及 DB2 等數據庫進行改造。而TiDB 的鎖處理機制與傳統數據庫不一樣，其同時存在樂觀事務和悲觀事務。對于開發團隊來說，一些 SQL 的執行在原來數據庫上的執行結果與現有的 TiDB 的執行結果可能會出現差異。建議在改造遷移的時候，比如說從 MySQL 等數據庫遷移，在開發的時候要重視開發規范，比如嚴格使用事務顯式聲明，像 begin 加上需要執行的SQL語句，加上 commit 的方式，特別是對于 DML 語句，盡可能保證這個事務機制與原來的傳統關系型數據庫（像 MySQL）一致，減少開發的復雜度，保證數據的準確性。

寫在最后，自主創新之路確實會出現許多大大小小的問題，這也需要我們一起去協作解決和攻克這些阻礙。

道阻且長，行則將至。行而不綴，未來可期。

總結

以上是生活随笔為你收集整理的TiDB 在安信证券资产中心与极速交易场景的实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。