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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我們看下活動(dòng)業(yè)務(wù)場(chǎng)景的特點(diǎn)：

參與門(mén)檻低：暖寶保這個(gè)業(yè)務(wù)保費(fèi)價(jià)格低至 19.9，所以人人都可以參與。

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

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

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

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

時(shí)間緊迫

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

開(kāi)發(fā)零使用經(jīng)驗(yàn)

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

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

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

DB 運(yùn)維管理

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

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

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

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

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

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

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

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

TiKV 性能中的“木桶原理”：TiKV 中一個(gè)節(jié)點(diǎn)的寫(xiě)入性能變慢會(huì)影響到整個(gè)集群的 TPS 與響應(yīng)時(shí)間。

上線時(shí)我們做了以下兩方面改善：

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

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

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

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

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

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

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

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

在使用過(guò)程中遇到如下問(wèn)題：

（1） 2.0.10 版本下 in 不能下推到表過(guò)渡問(wèn)題

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

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

我們?cè)谂苊畹臅r(shí)候沒(méi)有問(wèn)題，并且結(jié)果是可以的，但是跑完后就斷掉了，從后臺(tái)看也是有問(wèn)題的，重啟 TiDB 組件也不行，后來(lái)找到代碼我們發(fā)現(xiàn)這是一個(gè) bug。

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

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

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

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

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

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

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

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

失?。河绊懶袛?shù)為 0 || 影響行數(shù)為 1 && commit 時(shí)出現(xiàn)異常。

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