本文根據安信證券資深資料庫架構師李軻在 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）一致，減少開發的複雜度，保證資料的準確性。
寫在最後，自主創新之路確實會出現許多大大小小的問題，這也需要我們一起去協作解決和攻克這些阻礙。
道阻且長，行則將至。行而不綴，未來可期。