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

作者：何志勇
本文轉(zhuǎn)載自公眾號「平安科技數(shù)據(jù)庫產(chǎn)品團(tuán)隊」。

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

作為一名運維人員，引入一個新的數(shù)據(jù)庫產(chǎn)品前必須要明確幾點：

從業(yè)務(wù)的角度，引入的產(chǎn)品能否滿足業(yè)務(wù)基本需求和使用場景。

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

產(chǎn)品性能穩(wěn)定。

所以在我們引入前從以下六個方面分別對 TiDB 進(jìn)行測試驗證，其中功能與架構(gòu)、配置與管理、備份與恢復(fù)都是針對我們運維管理，SQL 特性、基準(zhǔn)測試、應(yīng)用場景測試則是應(yīng)對業(yè)務(wù)需求和業(yè)務(wù)場景的。

TiDB 事務(wù)隔級別為 SI，支持 Spark 生態(tài)，支持動態(tài)擴(kuò)容，跨數(shù)據(jù)中心部署。

這是 TiDB 官網(wǎng)最新的架構(gòu)圖：

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

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

TiDB 從架構(gòu)及生態(tài)上基本上具備了傳統(tǒng)數(shù)據(jù)庫應(yīng)有的功能。

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

支持在線 DDL，2.0 只支持串行的 DDL、不支持并發(fā)，在優(yōu)化器上支持 RBO 與 CBO，能對單會話進(jìn)行管理，可以支持復(fù)雜的 SQL。

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

TiDB 在單條 SQL 的性能較好，高并發(fā)場景下性能較穩(wěn)定，但 DML 事務(wù)大小有限制。

支持標(biāo)量子查詢，能支持非常復(fù)雜的查詢，查詢引擎可朔性強。

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

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

我們看下活動業(yè)務(wù)場景的特點：

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

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

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

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

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

時間緊迫

2018 年 12 月 17 日~2019 年 1 月 7 日，20 天時間內(nèi)完成開發(fā)測試到生產(chǎn)上線，時間短，風(fēng)險大

開發(fā)零使用經(jīng)驗

現(xiàn)有開發(fā)大都是基于傳統(tǒng) Oracle 保險業(yè)務(wù)，對于 TiDB 沒有使用經(jīng)驗

并發(fā)量與擴(kuò)容

互聯(lián)網(wǎng)業(yè)務(wù)并發(fā)需求前期不可完全需求，前期不能很好的以實際壓力進(jìn)行測試，與資源準(zhǔn)備

DB 運維管理

TiDB 還處于生產(chǎn)落地階段，一類系統(tǒng)尚未使用過 TiDB，沒有大規(guī)模應(yīng)用運維經(jīng)驗

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

總結(jié)一下，就是：

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

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

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

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

Raftstore cpu 高問題：由于 Raftstore 還是單線程，測試中從監(jiān)控指標(biāo)看到 CPU 達(dá)到瓶頸是raftrestore 線程。

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

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

1. 優(yōu)化表的定義與索引

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

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

2. 對表的 region 進(jìn)行強制分裂

查找表對應(yīng)的 region：curl http://$tidb_ip:$status_port /tables/$schema/$table_name/regions

使用 pd-ctl 工具 split 對應(yīng)表的 region：operator add split-region $region_id

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

我們使用了 25 臺機(jī)器，后面還臨時準(zhǔn)備了 10 臺機(jī)器去應(yīng)對高并發(fā)的不時之需。

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

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

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

（2） 2.0.10 下時區(qū)設(shè)置導(dǎo)致客戶端不能連

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

原因：這個 bug 會在你連接時 check 這個時區(qū)，導(dǎo)致用戶不能連接。

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

（3） Spring 框架下 TiDB 事務(wù)

這個問題是比較重要的問題，有個產(chǎn)品需要生成一個唯一的保單號，業(yè)務(wù)是批量生成的，當(dāng)時在 TiDB 中我們建了一個表，表中只有一條數(shù)據(jù)，但是我們發(fā)現(xiàn)會有重復(fù)保單號出來。

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

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

利用 redis 實現(xiàn)分布式鎖，執(zhí)行 SQL。

捕獲事務(wù) commit 狀態(tài)，并判斷更新成功還是失敗：

失敗：影響行數(shù)為 0 || 影響行數(shù)為 1 && commit 時出現(xiàn)異常。

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