摘要：年月日，平安科技數據庫產品資深工程師何志勇在第十屆數據庫技術大會上分享了在平安核心系統的引入及應用，通過對進行測試，詳細解析如何選擇適用于金融行業級別的開源分布式數據庫，以及平安財神節活動中引入的全流程應用實踐案例分享。

作者：何志勇
本文轉載自公眾號「平安科技數據庫產品團隊」。

2019 年 5 月 9 日，平安科技數據庫產品資深工程師何志勇在第十屆數據庫技術大會 DTCC 上分享了《TiDB 在平安核心系統的引入及應用》，通過對 TiDB 進行 POC 測試，詳細解析如何選擇適用于金融行業級別的開源分布式數據庫，以及平安“財神節”活動中引入 TiDB 的全流程應用實踐案例分享。本文根據演講內容整理。

作為一名運維人員，引入一個新的數據庫產品前必須要明確幾點：

從業務的角度，引入的產品能否滿足業務基本需求和使用場景。

從運維管理角度看，這產品必須是可運維、可管理的，并且我們需要對其相應的功能與特性，要有一個很好的了解。

產品性能穩定。

所以在我們引入前從以下六個方面分別對 TiDB 進行測試驗證，其中功能與架構、配置與管理、備份與恢復都是針對我們運維管理，SQL 特性、基準測試、應用場景測試則是應對業務需求和業務場景的。

TiDB 事務隔級別為 SI，支持 Spark 生態，支持動態擴容，跨數據中心部署。

這是 TiDB 官網最新的架構圖：

從左至右看，可以通過 MySQL 或 MySQL 客戶端接入 TiDB，TiDB 有 TiDB、PD、TiKV 三個組件，組件之間功能相互獨立，需獨立部署，分別負責計算、調度、存儲功能；同時又相互協作，共同完成用戶請求處理。在 TiKV 層各節點是使用 Raft 協議保證節點間數據的一致性，同時它還提供 Spark 接口供大數據分析。

從上往下看，可通過 Data Miaration 工具從 MySQL 遷移到 TiDB，同時提供備份恢復功能、內部性能監控監測及診斷、支持容器化部署。

TiDB 從架構及生態上基本上具備了傳統數據庫應有的功能。

兼容 mysql 語法，2.0 版本不支持窗口函數、分區表、視圖、trigger 等。

支持在線 DDL，2.0 只支持串行的 DDL、不支持并發，在優化器上支持 RBO 與 CBO，能對單會話進行管理，可以支持復雜的 SQL。

備份恢復工具均為開源，支持多線程備份恢復，當前版本不支持物理備份，loader 恢復時間偏長。

TiDB 在單條 SQL 的性能較好，高并發場景下性能較穩定，但 DML 事務大小有限制。

支持標量子查詢，能支持非常復雜的查詢，查詢引擎可朔性強。

這個應用場景是我們的產險的實際分析場景，表數據量不大但是 SQL 較為復雜，是典型的星型查詢。在 Oracle 用了 134 秒，但是 TiDB 用了 50 分鐘，我們覺得很詫異，與 TiDB 的同事咨詢后，他們通過現場支持我們優化底層代碼后 34 秒可以跑出來。

“財神節”是中國平安綜合性年度線上金融狂歡節。2019 年平安集團“財神節”活動于 1 月 8 日正式啟動，涉及壽險、產險、銀行、養老險、健康險、普惠、證券、基金、健康互聯、陸金所、壹錢包、互娛、不動產等多個領域，活動參與的 BU 數量與推廣的力度是歷年之最。單日成交額超過 1000 億，在單日交易額破千億背后是幾百個后臺數據庫實例的運維保障。

我們看下活動業務場景的特點：

參與門檻低：暖寶保這個業務保費價格低至 19.9，所以人人都可以參與。

我們的推廣力度很大：以微服務的方式對接如平安健康、好福利、平安銀行、陸金所等所有 APP 端，同時配合各種合作伙伴的宣傳。

典型的互聯網活動形式：如秒殺、紅包雨，所以對數據庫的要求是高并發、低延遲、高響應、高可用，2-5 年在線數據存儲量預計達到 20~50TB，而這些只是預估，有可能遠遠大于以上評估值。

平安在用的開源數據庫有很多，那在這么多數據庫中，我們選擇什么數據庫呢？

綜合對比考量最終我們選擇 TiDB，在選擇的同時也面臨著挑戰：

時間緊迫

2018 年 12 月 17 日~2019 年 1 月 7 日，20 天時間內完成開發測試到生產上線，時間短，風險大

開發零使用經驗

現有開發大都是基于傳統 Oracle 保險業務，對于 TiDB 沒有使用經驗

并發量與擴容

互聯網業務并發需求前期不可完全需求，前期不能很好的以實際壓力進行測試，與資源準備

DB 運維管理

TiDB 還處于生產落地階段，一類系統尚未使用過 TiDB，沒有大規模應用運維經驗

基于以上挑戰，我們在 9 臺 PC 服務器上做了驗證測試，測試工具是 jmeter，TiKV 節點數我們是逐步增加的，具體的測試過程如下:

總結一下，就是：

TiDB 吞吐：在 select 中即 point select，TiDB 的吞吐比較好。

彈性擴容：在 insert 場景下隨著節點數的增加，TPS 也會相應的增加，每增加 3 個節點 TPS 可提升 12%~20% 左右，同時在相同 TiKV 節點數下，TPS 與響應時間，此消彼長。

批量提交性能尤佳：業務中一個保單需要同時寫 7 個表，7 個表同時 commit 比單表 commit TPS 高，相同 TPS 場景下延遲更小。

初始化 region 分裂耗時長：因在測試時沒有預熱數據（表為空表），對空表寫入前幾分鐘，響應時間會比較大，約 5~8 分鐘后響應時間趨于穩定。在前幾分鐘內響應時間大，是因為每個表初始化完都是一個 region,大量 insert 進來后需要進行分裂，消耗時間比較大。

Raftstore cpu 高問題：由于 Raftstore 還是單線程，測試中從監控指標看到 CPU 達到瓶頸是raftrestore 線程。

TiKV 性能中的“木桶原理”：TiKV 中一個節點的寫入性能變慢會影響到整個集群的 TPS 與響應時間。

上線時我們做了以下兩方面改善：

1. 優化表的定義與索引

表定義：不使用自增長列（自增長的 rowid）作為主鍵，避免大量 INSERT 時把數據集中寫入單個 Region，造成寫入熱點。

索引：使用有實際含義的列作為主鍵，同時減少表不必要的索引，以加快寫入的速度。

2. 對表的 region 進行強制分裂

查找表對應的 region：curl http://$tidb_ip:$status_port /tables/$schema/$table_name/regions

使用 pd-ctl 工具 split 對應表的 region：operator add split-region $region_id

打散表的隱式 id，打散表的數據分布：alter table $table_name shard_row_id_bits=6;

我們使用了 25 臺機器，后面還臨時準備了 10 臺機器去應對高并發的不時之需。

在使用過程中遇到如下問題：

（1） 2.0.10 版本下 in 不能下推到表過渡問題

大家看到我們兩個相同的表結構，同時寫入一些數據，在兩個表進行關聯的時候，發現過濾條件 t1.id=1 時，上面那個執行計劃可以下推到兩個表進行過濾，兩個表可以完全精準的把數據取出來，但是下面把等號后改成 in 的時候，對 t2 表進行全表掃描，如果 t2 表數據量很大時就會很慢，這是 TiDB 的一個 bug，解決方案就是不要用 in，在 2.1 版本修復了這個 bug。

（2） 2.0.10 下時區設置導致客戶端不能連

我們在跑命令的時候沒有問題，并且結果是可以的，但是跑完后就斷掉了，從后臺看也是有問題的，重啟 TiDB 組件也不行，后來找到代碼我們發現這是一個 bug。

原因：這個 bug 會在你連接時 check 這個時區，導致用戶不能連接。

解決辦法：我們找研發同事重新編譯一個 tidb-server 登入服務器，把時區設置為正確的，然后使用最初的 TiDB 組件登錄，2.1 版本后這個 bug 修復。

（3） Spring 框架下 TiDB 事務

這個問題是比較重要的問題，有個產品需要生成一個唯一的保單號，業務是批量生成的，當時在 TiDB 中我們建了一個表，表中只有一條數據，但是我們發現會有重復保單號出來。

原因：TiDB 使用樂觀事務模型，在高并發執行 Update 語句對同一條記錄更新時，不同事務拿的版本值可能是相同的，由于不同事務只有在提交時，才會檢查沖突，而不是像 Oracle、MySQL、PG 那樣，使用鎖機制來實現對一記錄的串行化更改。

解決辦法：Spring 開發框架下，對事務的管理是使用注解式的，無法捕獲到 TiDB commit 時的返回狀態。因此需要將 spring 注解式事務改成編程式事務，并對 commit 狀態進行捕獲，根據狀態來決定是重試機制，具體步驟：

利用 redis 實現分布式鎖，執行 SQL。

捕獲事務 commit 狀態，并判斷更新成功還是失敗：

失敗：影響行數為 0 || 影響行數為 1 && commit 時出現異常。

成功：影響行數為 1 && commit 時無異常。