1、前言

得物 App 從創(chuàng)立之初，關(guān)系型數(shù)據(jù)庫一直使用的開源數(shù)據(jù)庫產(chǎn)品 MySQL。和絕大部分互聯(lián)網(wǎng)公司一樣，隨著業(yè)務(wù)高速增長、數(shù)據(jù)量逐步增多，單實(shí)例、單庫、單表出現(xiàn)性能瓶頸和存儲瓶頸。從選型和架構(gòu)設(shè)計角度來看這很符合發(fā)展規(guī)律，一開始沒必要引入過于復(fù)雜的架構(gòu)導(dǎo)致資源成本和開發(fā)成本過高，而是逐步隨著業(yè)務(wù)發(fā)展速度去迭代架構(gòu)。為了應(yīng)對這些問題，我們采取了諸多措施如單庫按業(yè)務(wù)邏輯拆分成多個庫的垂直拆分，分庫分表的水平拆分、一主多從讀寫分離等。這些技改同時也使得整個業(yè)務(wù)層架構(gòu)更加復(fù)雜，且無法做到透明的彈性，因此我們逐步把目光轉(zhuǎn)向了已經(jīng)趨于成熟的分布式關(guān)系型數(shù)據(jù)庫 TiDB。

?自 2020 年初開始使用 TiDB，隨著運(yùn)維體系的逐步完善，產(chǎn)品自身能力的逐步提升，接入業(yè)務(wù)已經(jīng)涉及得物的多個 業(yè)務(wù)線，其中個別為關(guān)鍵業(yè)務(wù)場景。業(yè)界關(guān)于 TiDB 的功能剖析、場景落地、平臺化建設(shè)都有很多優(yōu)秀的文章。本文基于得物內(nèi)部的實(shí)踐情況，會從選型策略、運(yùn)維手段、運(yùn)營方式、核心場景實(shí)踐等幾個方向講述TiDB 在得物實(shí)踐落地過程。

2、TiDB 架構(gòu)

上圖是我們目前的接入方式和整體架構(gòu)。TiDB 的部署架構(gòu)這里就不做贅述了，需要了解的同學(xué)可以參考官方文檔。我們之所以采用 SLB 來做 TiDB 的負(fù)載均衡接入，就是為了簡化接入成本與運(yùn)維成本，訪問流量的負(fù)載均衡以及節(jié)點(diǎn)擴(kuò)縮容可以通過調(diào)整 SLB 解決。當(dāng)然如果能夠?qū)崿F(xiàn) SDK 負(fù)載均衡與故障剔除，結(jié)合配置中心的流量調(diào)度也是非常好的解決方案。得物 TiDB 部署均采用單機(jī)單實(shí)例部署，TiDB Server、PD 采用無本地 SSD 機(jī)型，TiKV 采用本地 SSD 機(jī)型。既兼顧了性能，又能降低成本。詳細(xì)的機(jī)型選擇會在后面的內(nèi)容提到。

3、MySQL 與 TiDB 的對比

圈內(nèi)一直流傳著一句話，沒有一種數(shù)據(jù)庫是"銀彈"。絕大部分用戶選擇 TiDB 就是為了彌補(bǔ) MySQL 的不足，所以選型階段對兩者做些比較也是在所難免的。本文基于我們內(nèi)部的現(xiàn)狀和場景對兩個產(chǎn)品我們關(guān)注的點(diǎn)進(jìn)行了簡要對比。對比的目的不是為了去印證那個數(shù)據(jù)庫產(chǎn)品能力更強(qiáng)。而是想通過對比來幫助團(tuán)隊在合適的場景選擇合適的產(chǎn)品。

擴(kuò)展性

MySQL

MySQL 就自身擴(kuò)展能力而言主要是來自于垂直擴(kuò)容，但是這個會受限于機(jī)器的規(guī)格上限。水平擴(kuò)容涉及業(yè)務(wù)改造和使用成本提升。改造為分庫分表，對研發(fā)來說是一個費(fèi)力度很高的方案。需要引入 Sharding 邏輯，改造完成后需要業(yè)務(wù) SQL 必須帶 Sharding Key 才能執(zhí)行或者高效執(zhí)行。所以并不是說做不到可擴(kuò)展。

TiDB

由于 TiDB 是計算存儲分離的架構(gòu)，且有狀態(tài)的存儲層 TiKV 是分布式存儲。所以單從上面定義的擴(kuò)展性來說，確實(shí)對比 MySQL 有很大優(yōu)勢。集群處理能力和存儲能力，可以通過擴(kuò)容 TiDB Server、TiKV 簡單實(shí)現(xiàn)。這里需要注意的是，TiKV 屬于有狀態(tài)服務(wù)，擴(kuò)容會涉及到數(shù)據(jù)的 Reblance，過程中 TiKV(region 遷移) 和 PD(調(diào)度) 產(chǎn)生大量交互，為避免影響業(yè)務(wù)，擴(kuò)縮容過程中需要關(guān)注集群情況，根據(jù)需求適當(dāng)調(diào)整遷移力度。

性能

MySQL

關(guān)于 RT。MySQL 由于是單機(jī)數(shù)據(jù)庫，所以對于點(diǎn)查或簡單查詢的 RT、熱點(diǎn)更新的 RT 與 TPS ，相比分布式數(shù)據(jù)庫有天然優(yōu)勢。數(shù)據(jù)獲取鏈路短(單機(jī)數(shù)據(jù)庫本地調(diào)用，分布式數(shù)據(jù)庫涉及存算分離)，且不用考慮分布式事務(wù)的沖突檢測。所以總體的訪問 RT 要低于 TiDB，具體數(shù)據(jù)這邊就不羅列了，社區(qū)有不少性能壓測的帖子。

關(guān)于聚合查詢?；ヂ?lián)網(wǎng)公司在 C 端基本不存在此類問題，也是不允許的。所以主要是場景在 B 端。解決方法一般是分為幾種：1.提供專門的只讀實(shí)例給 B 端提供查詢能力；2.異構(gòu)數(shù)據(jù)來解決（MySQL+ES、ADB 等等）。

關(guān)于優(yōu)化器。MySQL 多年的積累，在優(yōu)化器的穩(wěn)定性雖然不如商用數(shù)據(jù)庫那么可靠，偶爾也有走錯索引的情況。一般只能通過修改 SQL、修改索引來解決，切記別用 force index 這種有坑的解決方案。但是總體來說我們遇到的 MySQL 走錯索引的情況要遠(yuǎn)低于 TiDB。

TiDB

關(guān)于 RT。分布式數(shù)據(jù)庫解決的更多是吞吐量和容量上的需求，比如點(diǎn)查或簡單查詢的 RT 無法像單機(jī)數(shù)據(jù)庫那么短，但是可以通過節(jié)點(diǎn)擴(kuò)容的方式提升 QPS 吞吐量。熱點(diǎn)數(shù)據(jù)這里就不展開講了，它本身也不是分布式數(shù)據(jù)庫能解決的范疇。如果你的業(yè)務(wù)場景是一個對 RT 要求很高的場景，那么優(yōu)先使用 MySQL。如果是高吞吐量需求優(yōu)先，可以嘗試使用 TiDB。

關(guān)于聚合查詢。由于 TiDB 的存儲節(jié)點(diǎn) TiKV 不只是具備存儲能力，TiKV 實(shí)現(xiàn)了coprocessor 框架來支持分布式計算的能力。所以理論上通過加機(jī)器就能擴(kuò)展計算能力，從我們實(shí)際使用的場景來看也是如此，這部分的能力就要優(yōu)于 MySQL。具體的效果在本文最后的章節(jié)會有體現(xiàn)。

關(guān)于優(yōu)化器。這個是大家對 TiDB 一直以來吐槽的點(diǎn)之一，有時候統(tǒng)計信息健康度 90 以上的情況下，還是會走錯索引，當(dāng)然這里有一部分原因可能是條件過多和索引過多導(dǎo)致的。為了解決問題，核心服務(wù)上線的 SQL 就必須一一 Review。如果無法正確使用索引的就使用 SPM 綁定，雖然能解決，但是使用成本還是略高。希望官方繼續(xù)加油。

資源成本

MySQL

如果是一個數(shù)據(jù)量小且查詢模型比較簡單的需求(比如：1-2TB，簡單查詢?yōu)橹?，那么肯定是 MySQL 成本較低。以我們 TiDB 基礎(chǔ)配置為例，相比 MySQL 成本高出 27%(該成本是用高可用的 MySQL 對標(biāo)3 TiDB、3 TiKV、3 PD 的 TiDB)。所以得物內(nèi)部選型，單從資源成本角度考慮，還是首選 MySQL。

TiDB

如果是一個數(shù)據(jù)量較大且持續(xù)增長或查詢模型比較復(fù)雜的需求(比如：3-5 TB 以上，多條件查詢、聚合查詢等)。一般該類型的業(yè)務(wù)都采用分庫分表的解決方案。以得物一個分庫分表的集群(10個寫實(shí)例、10個讀實(shí)例)為例，替換為 TiDB(6 TiDB、12 TiKV、3 PD)，成本相比 MySQL 成本節(jié)省 58%。此例子只作為得物一個業(yè)務(wù)場景的替換結(jié)果，不代表所有場景。為了驗證這個結(jié)論，本文后面的內(nèi)容會講到這個核心場景的實(shí)踐。

運(yùn)維成本

MySQL

MySQL 作為被使用最多的開源關(guān)系型數(shù)據(jù)庫，從社區(qū)活躍度、產(chǎn)品成熟度、周邊生態(tài)工具、解決方案積累等方面來看都是非常優(yōu)先的產(chǎn)品。主從架構(gòu)的 MySQL 維護(hù)成本極低，當(dāng)主庫異常或無法修復(fù)時，我們只需要切換即可。

另外得益于優(yōu)秀的社區(qū)生態(tài)，運(yùn)維工具、數(shù)據(jù)庫接入組件、數(shù)據(jù)同步組件都有非常多的成熟工具，稍加改造就可以實(shí)現(xiàn)本地化適配。

TiDB

分布式的架構(gòu)的設(shè)計沒有像 MySQL 這樣的主從，每個存儲節(jié)點(diǎn)都是提供讀寫。當(dāng)一個節(jié)點(diǎn)出問題的時候，會影響整個集群的訪問。無法實(shí)現(xiàn) MySQL 這樣通過主從切換實(shí)現(xiàn)快速的故障隔離。

TiDB 由 3 個角色組成，當(dāng)出現(xiàn)問題的時候無法快速定位問題(當(dāng)然也是我們個人能力需要提升的點(diǎn))，比如當(dāng)某個時間點(diǎn)的查詢超過預(yù)期的時候，需要排查執(zhí)行計劃、各個節(jié)點(diǎn)的負(fù)載情況、各節(jié)點(diǎn)的網(wǎng)絡(luò)情況。雖然提供了完善的監(jiān)控，但是指標(biāo)與節(jié)點(diǎn)過多需要一一排查才能有結(jié)論。不像 MySQL 出現(xiàn)查詢超預(yù)期的問題，基本上通過幾個核心指標(biāo)就能判斷出根因。

結(jié)構(gòu)變更(DDL)

MySQL

這里以我們主要使用的 MySQL 5.7 為例，較大數(shù)據(jù)量的情況下 DDL 成本較高，為了規(guī)避鎖表和主從延遲的問題，一般都是用工具去執(zhí)行。我們通常使用的兩個知名開源無鎖 DDL 工具：Percona 開源的 pt-osc、Github 開源的 gh-ost。目前我們和大部分公司一樣都在通過定制化開發(fā)的 gh-ost 來變更。但是用工具只是解決了前面提到的鎖表和主從延遲問題，隨著數(shù)據(jù)量規(guī)模上升，變更時長也逐步上升。另外工具的 Bug 也會帶來數(shù)據(jù)丟失的風(fēng)險。當(dāng)然 MySQL 8.0 的特性 Instant Add Column 推出以后解決了加列的痛點(diǎn)，但是也只解決了一部分。

TiDB

TiDB 的 DDL 通過實(shí)現(xiàn) Google F1 的在線異步 schema 變更算法，來完成在分布式場景下的無鎖，在線 schema 變更。DDL 變更中除過 add index 以外其他都不需要做數(shù)據(jù)回填，修改完元信息即可，所以可以立即完成。而 add index 會做兩件事情：1.修改 table 的元信息，把 indexInfo加入到 table 的元信息中去；2.把 table 中已有了的數(shù)據(jù)行，把 index columns的值全部回填到 index record中去。變更速度取決于表中的數(shù)據(jù)和系統(tǒng)負(fù)載。所以 TiDB 在 DDL 操作上解決了很多 MySQL 上的痛點(diǎn)，但是與 MySQL 相比，TiDB 的 DDL 還是有些不一樣的地方的，也帶來了一些限制：

1. 不能在單條 ALTER TABLE 語句中完成多個操作。MySQL 下會把多個同一張表的 DDL 進(jìn)行合并，然后使用 gh-ost 或者 pt-osc 工具一次性執(zhí)行。TiDB 里只能一個個單獨(dú)去執(zhí)行；(6.2 已經(jīng)支持了ALTER TABLE語句增刪改多個列或索引)
2. 不支持不同類型的索引 (HASH|BTREE|RTREE|FULLTEXT)；
3. 不支持添加 / 刪除主鍵，除非開啟了 alter-primary-key 配置項；
4. 不支持將字段類型修改為其超集，例如不支持從 INTEGER 修改為 VARCHAR，或者從 TIMESTAMP 修改為 DATETIME，否則可能輸出的錯誤信息 Unsupported modify column
5. 更改 / 修改數(shù)據(jù)類型時，尚未支持“有損更改”，例如不支持從 BIGINT 更改為 INT;
6. 更改 / 修改 DECIMAL 類型時，不支持更改精度 ;
7. 更改 / 修改整數(shù)列時，不允許更改 UNSIGNED 屬性 ;

這里大部分限制可以在結(jié)構(gòu)設(shè)計階段和后期規(guī)范來規(guī)避掉，比如一個表的多個 DDL 操作無法合并的問題，可以通過自動化手段降低復(fù)雜度；BIGINT 更改為 INT 這種長改短的就是日常變更規(guī)范中要管控的。

產(chǎn)品流行度

MySQL

如果我們從 MySQL 1.0 開始算起至今已經(jīng)有 26 年了。這期間幾經(jīng)周轉(zhuǎn)，最終歸到了 Oracle 旗下。版本也從 1.0 來到了 8.0。作為一個久經(jīng)錘煉的數(shù)據(jù)，特別是作為互聯(lián)網(wǎng)盛行時期依賴的主流數(shù)據(jù)庫，不論是產(chǎn)品成熟度和社區(qū)活躍度都得到了極大的促進(jìn)。MySQL 在 DB-Engines 的開源數(shù)據(jù)庫中排名久居第一。

圖片數(shù)據(jù)來源 DB-engines 官網(wǎng)

TiDB

TiDB 從 2015 年創(chuàng)立并開源至今已經(jīng) 7 年，作為一個復(fù)雜的基礎(chǔ)軟件來說確實(shí)還比較年輕。依賴早期的 3 個創(chuàng)始人互聯(lián)網(wǎng)背景出身，深知大家在關(guān)系型數(shù)據(jù)庫上的痛點(diǎn)。所以 TiDB 推出后獲得了不少用戶的推崇，特別是互聯(lián)網(wǎng)行業(yè)。社區(qū)在 TiDB 的發(fā)展中也起到了至關(guān)重要的作用，從打磨產(chǎn)品、需求提煉、落地場景總結(jié)等。目前 TiDB 在 DB-Engines 排名為 98，進(jìn)一步證明了基礎(chǔ)軟件的難度以及作為一款國產(chǎn)數(shù)據(jù)庫在國際化進(jìn)程中還有很大的空間。從墨天輪中國數(shù)據(jù)庫排行的情況，可以看到 TiDB 長期以來保持第一的位置。在 12 月跌落榜首，由 OceanBase 取代。

圖片數(shù)據(jù)來源 墨天輪

4、TiDB 在得物的運(yùn)維體系落地及探索?

4.1 選型

關(guān)于數(shù)據(jù)庫選型，我們一向非常謹(jǐn)慎，會根據(jù)具體的業(yè)務(wù)情況來推薦合適的數(shù)據(jù)庫。要避免陷入“手拿鐵錘的人,看什么都像釘子”的誤區(qū)。不是為了使用 TiDB 而使用，要去解決一些 MySQL 無法滿足或者改造成本比較高的場景。關(guān)系型數(shù)據(jù)庫我們還是優(yōu)先推薦MySQL。能用分庫分表能解決的問題盡量選擇 MySQL。畢竟運(yùn)維成本相對較低、數(shù)據(jù)庫版本更加穩(wěn)定、單點(diǎn)查詢速度更快、單機(jī)QPS性能更高這些特性是分布式數(shù)據(jù)庫無法滿足的。以下是我們總結(jié)的關(guān)于選型的兩個大方向。

適合接入的場景：

• 分庫分表場景:上游 MySQL 分庫分表，業(yè)務(wù)查詢時無法使用到分片
• 磁盤使用大場景: CPU 和內(nèi)存使用率低但磁盤容量達(dá)到 MySQL 瓶頸
• 分析 SQL 多場景:業(yè)務(wù)邏輯比較復(fù)雜，存在并發(fā)查詢+分析查詢
• 數(shù)據(jù)歸檔場景:數(shù)據(jù)冷熱分離、定期歸檔、數(shù)據(jù)重要，不能丟失
• 日志流水場景:日志流水業(yè)務(wù)、單表較大、寫入平穩(wěn)、查詢不多

不適合接入的場景：

• 數(shù)據(jù)抽取場景:下游存在大數(shù)據(jù)或者其他業(yè)務(wù)部門進(jìn)行數(shù)據(jù)抽取
• 讀寫分離的場景: TIDB 沒有主從的概念，無法進(jìn)行讀寫分離
• 指定點(diǎn)恢復(fù)場景:指定時間點(diǎn)級別恢復(fù)，需要恢復(fù)到某個時間點(diǎn)
• 數(shù)據(jù)熱點(diǎn)場景:高并發(fā)單行更新、熱點(diǎn)小表、熱點(diǎn)庫存

4.2 運(yùn)維標(biāo)準(zhǔn)化

業(yè)務(wù)接入

場景：當(dāng)業(yè)務(wù)選型考慮TiDB時，我們會根據(jù)業(yè)務(wù)的使用場景和業(yè)務(wù)特點(diǎn)綜合評估是否適合TiDB(優(yōu)先 推薦使用MySQL)。

配置：評估業(yè)務(wù)成本壓力和未來一年數(shù)據(jù)量、TPS，選擇合適的TiDB集群配置。

使用：給使用方提供 MySQL 和 TiDB 的差異及其規(guī)范，避免增加開發(fā)周期和成本。

資源規(guī)格

根據(jù)不同業(yè)務(wù)場景，我們定義了不同的服務(wù)器配置。由于借助云上的資源交付能力和隔離能力， 我們無需像 IDC 那樣，在高規(guī)格機(jī)器上采用多實(shí)例部署。這樣避免了混部帶來兩個問題：1.多個實(shí)例之間的資源爭奪；2.高規(guī)則機(jī)器部署密度與穩(wěn)定性的權(quán)衡。

數(shù)據(jù)庫備份

備份工具：BR[官方物理備份工具]

備份策略：凌晨低峰期進(jìn)行數(shù)據(jù)全量備份

備份保留周期：7天

在線業(yè)務(wù)

對于在線業(yè)務(wù)，除了常規(guī)的BR備份外會額外調(diào)整 tikv_gc_life_time 時間為 1-3 天，當(dāng)業(yè)務(wù)出現(xiàn)誤操作時可以恢復(fù)三天內(nèi)任意時間的數(shù)據(jù)。

離線業(yè)務(wù)

TiDB集群離線業(yè)務(wù)大部分是從上游RDS同步到TiDB的場景。上游RDS會有一份最近的數(shù)據(jù)，所以對于離線業(yè)務(wù)只有常規(guī)的BR備份。

4.3 穩(wěn)定性治理

變更管理

面向 DBA 的流程管控

上圖的流程主要是用于管控非白屏化的 TiDB 基礎(chǔ)設(shè)施變更。通過變更文檔整理、運(yùn)維小組 Review 的機(jī)制，確保復(fù)雜變更的規(guī)范化。

面向研發(fā)變更的系統(tǒng)管控

DML\DDL 變更工單風(fēng)險自動化識別

語法檢查：

1. DDL 與 DML 類型判斷，確保每次執(zhí)行的內(nèi)容是同一個類型
2. SQL 語法檢查，確保提交的 SQL 語法是正確的

合規(guī)檢查：

變更合規(guī)性檢查，確保提交的 SQL 是可以按照 DBA 定義的規(guī)范設(shè)計(可以使用的字段類型、字段命名、索引命名、索引數(shù)量，字段長度由長修改短等限制)，簡單說就是要么允許，要么不允許

風(fēng)險識別：

1. 該項的作用是將允許執(zhí)行的進(jìn)行風(fēng)險識別，研發(fā)可以根據(jù)風(fēng)險等級選擇執(zhí)行時間，DBA 也能在審批階段判斷是否合理，并修改執(zhí)行時間。
2. 相關(guān)風(fēng)險定義

下圖是基于以上提到的能力，實(shí)現(xiàn)的 TiDB 變更管控功能。

穩(wěn)定性巡檢

數(shù)據(jù)庫巡檢手段是相當(dāng)于告警比較前置的一個動作，巡檢閾值相比告警較低，目的是為了提前發(fā)現(xiàn)問題并跟進(jìn)解決。收益是：1.降低告警數(shù)量；2.避免小問題逐步積累導(dǎo)致大問題。我們的做法是按照自定義的評分規(guī)則，雙日晨會對焦，對有風(fēng)險的服務(wù)進(jìn)行問題跟進(jìn)。

巡檢指標(biāo)的數(shù)據(jù)采集來自于監(jiān)控系統(tǒng)，我們會統(tǒng)計相關(guān)指標(biāo)的峰值。每天記錄一個點(diǎn)，展示近 30 天內(nèi)的指標(biāo)值。

某集群的巡檢情況?

慢查治理

雖然 TiDB 自帶的 Dashboard 可以提供慢查的白屏化，但是這需要提供賬號給研發(fā)，5.0 之前的版本還必須使用 root 賬號登錄，另外就是我們希望慢查治理可以結(jié)合內(nèi)部系統(tǒng)進(jìn)行管理。所以對于這部分做了些自研工作，將日志采集并加工后存入 ES。DBA 平臺可以通過報表等手段進(jìn)行推進(jìn)治理。

下面兩張圖就是我們內(nèi)部的平臺對慢查治理的閉環(huán)管理方案。DBA 或者研發(fā) TL 在平臺指派 SQL，處理人就會收到治理消息，處理完成后可以在后臺進(jìn)行狀態(tài)變更。然后基于這些數(shù)據(jù)可以做報表優(yōu)化治理效果。

告警管理

基于 TiDB 官方的監(jiān)控方案，我們在告警部分做了些定制化，Prometheus 中配置的 rule 觸發(fā)后會把告警信息推送至我們自己的數(shù)據(jù)庫管理平臺 OneDBA，由平臺處理后進(jìn)行發(fā)送。平臺的告警管理模塊的實(shí)現(xiàn)類似于 Alertmanager，不同的我們新增了自定義的需求，比如元信息關(guān)聯(lián)、支持集群指標(biāo)級別的閾值定義、告警沉默、告警降噪、告警治理閉環(huán)(有告警通知和認(rèn)領(lǐng)，確保及時跟進(jìn)處理)。另外這里的 Prometheus 主要功能是做數(shù)據(jù)采集與告警，數(shù)據(jù)存儲與趨勢圖查看在公司統(tǒng)一監(jiān)控平臺，降低不必要的存儲資源投入。由于我們管理的數(shù)據(jù)庫類型比較多，所以在告警方案上做了收斂。這里講到的方案就是得物數(shù)據(jù)庫團(tuán)隊目前針對負(fù)責(zé)的所有數(shù)據(jù)庫的管理方案。

閾值管理

故障演練

故障演練的目的是為了鞏固目前的系統(tǒng)高可用。我們針對 TiDB 制定了一套故意演練流程，包含了 8 個場景。

【演練場景1】TiKV Server 1 個節(jié)點(diǎn)宕機(jī)

【演練場景2】TiDB Server 1 個節(jié)點(diǎn)宕機(jī)

【演練場景3】PD Server  1 個節(jié)點(diǎn)宕機(jī)

【演練場景4】PD Server 節(jié)點(diǎn)重啟

【演練場景5】TiKV Server 節(jié)點(diǎn)重啟

【演練場景6】應(yīng)用高并發(fā)寫入，CPU、IO告警是否及時發(fā)送

【演練場景7】PD Server Leader、follow節(jié)點(diǎn)重啟

【演練場景8】TiDB 集群 宕機(jī)一個TiDB Server節(jié)點(diǎn)

以上的場景我們通過 ChaosBlade 實(shí)現(xiàn)了 100% 自動化故障注入。故障演練也促使我們達(dá)成整個技術(shù)部的目標(biāo)：1 分鐘發(fā)現(xiàn)，5 分鐘止損，10 分鐘定位。目前也正在計劃將該流程引入新集群交付前以及版本升級后的標(biāo)準(zhǔn)化流程。

4.4 人才儲備

專業(yè)認(rèn)證

PingCAP 目前有三個認(rèn)證，分別是 PCTA、PCTP、PCSD。前兩個是早期推出面向 DBA 從業(yè)者崗位初高級認(rèn)證。得物 DBA  團(tuán)隊有 6 位同學(xué)獲得TiDB的 PCTA 認(rèn)證考試、其中 5 位同學(xué)獲得了進(jìn)階的 PCTP (TiDB專家)認(rèn)證考試。認(rèn)證雖然不能完全代表實(shí)力，但是代表了 DBA 團(tuán)隊對技術(shù)的追求和 DBA 團(tuán)隊在得物做好 TiDB 服務(wù)支持的決心與態(tài)度。

通過PCTP認(rèn)證學(xué)習(xí)，團(tuán)隊成員深入了解TiDB數(shù)據(jù)庫的體系架構(gòu)、設(shè)計理念與各個組件的運(yùn)行原理。學(xué)習(xí)并掌握 TiDB 數(shù)據(jù)庫的體系架構(gòu)，設(shè)計實(shí)踐，性能監(jiān)控、參數(shù)優(yōu)化、故障排除、SQL優(yōu)化和高可用設(shè)計。這個對于公司和團(tuán)隊來說就是人才和技術(shù)上的儲備。

部分在職的 PCTP 得物 DBA 證書截圖

運(yùn)維小組

對自建數(shù)據(jù)庫服務(wù)我們采用了小組負(fù)責(zé)制，以 TiDB 為例，會有 3 名同學(xué)負(fù)責(zé)基礎(chǔ)設(shè)施運(yùn)維的工作(資源評估、變更流程評估、二線問題處理等)，其中一名是 Owner。關(guān)于日常業(yè)務(wù)側(cè)的變更、SQL 優(yōu)化等由具體對接業(yè)務(wù)的 DBA 負(fù)責(zé)處理。這樣既解決了人員互備問題，又解決了變更風(fēng)險評估問題，還解決了運(yùn)維小組運(yùn)維壓力的問題。

4.5 技術(shù)運(yùn)營

對于一個新興數(shù)據(jù)庫，DBA 基于產(chǎn)品特性介紹、場景分析、案例分享等，在公司內(nèi)部的技術(shù)運(yùn)營也非常重要。它決定了研發(fā)同學(xué)對這個產(chǎn)品的認(rèn)知和信心。好的技術(shù)氛圍一定是得益于公司內(nèi)部完善的機(jī)制和平臺，同時你也能合理的加以利用。這里沒有講到對外分享，是因為我們的原則是先內(nèi)部沉淀修煉，然后再對外分享。以下是我們對于 TiDB 的技術(shù)運(yùn)營在公司內(nèi)部的 3 個主戰(zhàn)場。

技術(shù)分享

技術(shù)夜校是得物技術(shù)部技術(shù)文化的特色之一。為技術(shù)部有意分享的同學(xué)提供一個平臺，就現(xiàn)有技術(shù)實(shí)戰(zhàn)經(jīng)驗、技術(shù)研究成果、重點(diǎn)項目回顧等，在技術(shù)部與同學(xué)們做分享和交流，營造濃厚的技術(shù)分享氛圍，形成技術(shù)知識沉淀，打造學(xué)習(xí)型組織，提升技術(shù)影響力，拓寬技術(shù)同學(xué)的知識面。

這是一個能夠有力促進(jìn)技術(shù)影響力和產(chǎn)品影響力的機(jī)會，我們當(dāng)然也不能錯過。本文的作者在剛?cè)肼毜梦锏臅r候就分享了《分布式數(shù)據(jù)庫 TiDB 的設(shè)計和架構(gòu)》，培訓(xùn)教室座無虛席，參與人次創(chuàng)下新高。這次分享讓研發(fā)對 TiDB 也有了一個全面的認(rèn)識。所以技術(shù)分享一定程度上解決了前面說的產(chǎn)品能力認(rèn)知問題。

技術(shù)博客

"毒"家博客也是得物技術(shù)部技術(shù)文化的特色之一。初衷是為了各位同學(xué)們交流技術(shù)心得，通過輸入與輸出的方式促進(jìn)進(jìn)步、相互成長。很多高質(zhì)量文章也被推送到了得物技術(shù)公眾號。

DBA 團(tuán)隊借助內(nèi)部的技術(shù)博客平臺，輸出了多篇有關(guān) TiDB 的技術(shù)文章。內(nèi)容涵蓋核心原理分析、優(yōu)化案例、故障 case 分析、業(yè)務(wù)場景落地等。在整個氛圍的帶動下，不少研發(fā)同學(xué)也發(fā)表了關(guān)于 TiDB 的學(xué)習(xí)和落地的技術(shù)文章。

課程錄制

組織內(nèi)部的技術(shù)分享的投入較大，分享的頻次不宜太高，否則參與度也會比較低。而且從內(nèi)容深度、知識獲取效率、自助學(xué)習(xí)來看，分享也不是長期的方案。錄制視頻課程的事情就提上日程了，視頻課程的好處是可以濃縮知識點(diǎn)，將技術(shù)分享 40 分鐘的內(nèi)容(有一些不必要的內(nèi)容，比如重復(fù)的話、口頭語等)壓縮至 15 分鐘。完美解決了前面提到的問題。正好公司內(nèi)部有一個自研的學(xué)習(xí)平臺，日常就用于發(fā)布各種培訓(xùn)、學(xué)習(xí)的視頻。為確保錄制效果和效率我們前期的課程都準(zhǔn)備了稿件。我們基于這個平臺也發(fā)布了一期( 5 節(jié))課程，最近已經(jīng)在籌備第二期的課程內(nèi)容了。

課程錄制也可以使 DBA 再一次復(fù)習(xí)細(xì)節(jié)知識，因為要講清楚知識點(diǎn)，就必須自己深入理解。這個一定程度上表明了我們對 TiDB 的了解程度和做好它的決心，也給了研發(fā)使用的信心。

5、TiDB 在核心業(yè)務(wù)場景實(shí)踐

5.1 業(yè)務(wù)痛點(diǎn)

得物商家訂單庫由早期 MySQL 單庫進(jìn)階到 MySQL 分庫分表，這個方案支撐了業(yè)務(wù)的高速發(fā)展。而以商家 ID 做 shareding-key，會使的同一個商家的訂單數(shù)據(jù)都會在一個表中，隨著訂單量的逐步提升，最終大商家的查詢會形成了單點(diǎn)性能問題。主要體現(xiàn)在慢 SQL 較多和 數(shù)據(jù)庫負(fù)載上升，每天約 1W 條慢 SQL，部分統(tǒng)計類查詢已經(jīng)超 10S。另外就是單機(jī)容量也有上限，垂直擴(kuò)容受限。隨著訂單量的上升，系統(tǒng)整體的性能和容量需要最進(jìn)一步的規(guī)劃。

5.2 解決思路

基于以上提到的問題，我們對所有的解決方案都做了對比。表格中是對四種解決方案的關(guān)鍵信息提煉。我們希望能夠選擇一個比較長期的方案，可以支撐未來 3-5 年的需求，既要解決性能問題，還要解決容量問題，又要比較低的研發(fā)成本。所以最終選擇了引入分布式數(shù)據(jù)庫的方案。

5.3 數(shù)據(jù)庫選型

基于目前得物在使用的數(shù)據(jù)庫進(jìn)行了評估，主要包含以下三種選擇。

由于得物在 2020 年就引入了 TiDB。雖然沒有大規(guī)模推廣，但是陸續(xù)也有不少業(yè)務(wù)接入。大部分的業(yè)務(wù)把它作為 MySQL 分庫分表的聚合庫使用，有一小部分業(yè)務(wù)是直接接入了讀寫需求。基于之前的實(shí)踐經(jīng)驗和業(yè)務(wù)需求，經(jīng)過和研發(fā)團(tuán)隊的協(xié)商，直接采用的讀寫庫的使用方案。另外一個方面是從只讀過渡到全量讀寫的周期會比較長，會產(chǎn)生不必要的并行成本和延遲項目時間。

5.4 兼容性&性能測試

兼容性測試

SQL 兼容性的問題，我們并沒有完全依賴后期的業(yè)務(wù)測試來驗證。而是通過獲取 MySQL 上的全量 SQL 的方式進(jìn)行驗證。由于我們將全量 SQL 存儲在了 Clickhouse，并且存儲前做了SQL 指紋提取。所以很容易可以獲得去重后的業(yè)務(wù) SQL。然后將所有類型的 SQL  樣本在 TiDB 中進(jìn)行回放，這里主要針對 Select。最終測試所有業(yè)務(wù) SQL 100% 兼容。

SQL 指紋?

性能測試

單量較少的商家場景性能測試

和預(yù)期的結(jié)果一樣，由于 TiDB 分布式的架構(gòu)，數(shù)據(jù)獲取路徑比 MySQL 要長，所以 RT 上相比 MySQL 分別多出 91%、76%、52%。從這里可以看出隨著并發(fā)的上升，TiDB 和 MySQL 之間的  RT 差距也逐步縮短。由于 TiDB 可以通過擴(kuò)展 DB 和 KV 節(jié)點(diǎn)提升 QPS 能力，我們在壓測中也做了相關(guān)驗證，符合預(yù)期。包括現(xiàn)有數(shù)據(jù)量翻一倍的基礎(chǔ)上對性能的影響也做了驗證，結(jié)論是無影響。為了方便和后面的內(nèi)容對比，我們這里只提供了 RT 的指標(biāo)。

單量較多的商家場景性能測試

我們挑了幾個出現(xiàn)頻率較高且查詢較慢的 SQL進(jìn)行測試，詳情參照以下內(nèi)容。

SQL1

SELECT *  FROM table_name WHERE xx_id= 1203030   AND xx_status IN(4000, 3040)   AND is_del= 0 ORDER BY id DESC,         create_time DESC  LIMIT 20

SQL2

SELECT [column_name] FROM table_nameWHERE xx_id = 1203030        AND xx_status = 8010        AND close_type = 13        AND close_time > ‘2022-06-19 18:16:24.519'LIMIT 0, 30000

SQL3

SELECT * FROM table_name WHERE xx_id= 1203030   AND xx_status IN(7000, 8000, 8010)   AND is_del= 0ORDER BY id DESC,create_time DESC 
LIMIT 20

SQL4

select count(*)  from table_name WHERE(seller_id= 1203030   and is_del= 0   and biz_type in('0', '12')   and create_time>= '2021-11-01 00:00:00.0'   and create_time< '2021-11-30 23:59:59.0'   and(xx_status<> 1000 R biz_type<> 21))

關(guān)于 xxDB 特別做了處理，大家可以忽略，因為我們主要對比的是 MySQL 和 TiDB。從測試結(jié)果來看效果很好，完全滿足業(yè)務(wù)側(cè)的要求。

5.5  遇到的一些問題

SQL 執(zhí)行計劃

問題：

首先說明一下，統(tǒng)計信息健康度是 90 以上。SQL 還是會選錯索引。我們分析了一下，主要是兩個問題：1.查詢條件比較多，索引也比較多；2.優(yōu)化器的能力待提升。

解決方案：

上線前和研發(fā)對已有 SQL 進(jìn)行了全面的 Review，如果執(zhí)行計劃不對，就通過 SPM 解決。

Bug

問題1：

Update 語句并發(fā)執(zhí)行耗時 3S，經(jīng)過排查是由于研發(fā)未使用顯示事務(wù)，所以第一次執(zhí)行是樂觀事務(wù)，第二次重試才是悲觀事務(wù)。調(diào)整以后遇到了悲觀事務(wù)下，偶發(fā)性的寫寫沖突的問題。經(jīng)排查是由于悲觀鎖未獲取到導(dǎo)致的寫寫沖突，需要升級到 5.3.2 才能解決。

解決方案：

升級版本到 5.3.2 解決

問題 2：

TiDB出現(xiàn)部分節(jié)點(diǎn)不可用，SQL執(zhí)行報 Region is unavailable 錯誤。經(jīng)排查是 5.3.2 引入的 TiKV  bug。

PD leader 發(fā)生切換后，TiKV 向 PD client 發(fā)送心跳請求失敗后不會重試，只能等待與 PD client 重連。

這樣，故障 TiKV 節(jié)點(diǎn)上的 Region 的信息會逐步變舊，使得 TiDB 無法獲取最新的 Region 信息，導(dǎo)致 SQL 執(zhí)行出錯。

解決方案：

這是一個讓人后背發(fā)涼的 bug。當(dāng)時的判斷是由于 PD 切換導(dǎo)致的，但是不清楚是 bug。我們采用了影響最小的故障恢復(fù)方案(把 PD leader 切回去，因為原 PD Leader 沒有掛，只是發(fā)生了切換)。問題解決后在官方發(fā)現(xiàn)了這個bug fix。所以又安排了升級。

這是我們上線過程中遇到的幾個典型問題?？傮w來說引入一個新數(shù)據(jù)庫就會帶來一定的試錯成本，所以我們依然處于謹(jǐn)慎選型的狀態(tài)。另外就是吐槽一下，就上面的問題 2，建議官方要加強(qiáng) Code Review 和混沌工程演練。

5.6 上線效果

性能收益

為了確保上線穩(wěn)定性，我們通過灰度切流的方式逐步放量。完全切流后成果顯著，慢 SQL 幾乎全部消失，如下圖所示。

成本收益

由于 MySQL 的分庫分表集群由 10個寫實(shí)例、10個讀實(shí)例構(gòu)成，遷移至 TiDB 后的集群規(guī)模為 TiDB*6、TiKV*12。成本下降了58%。所以再重復(fù)說一下選對了場景，TiDB 也能順帶節(jié)省成本。

大促考驗

項目上線后輕松應(yīng)對了今年的雙 11、雙 12，大促中的系統(tǒng) RT表現(xiàn)穩(wěn)定。

6、總結(jié)

最后特別說明下，文章中涉及一些產(chǎn)品的對比只是基于我們當(dāng)時的場景和需求進(jìn)行的分析，并不代表某個數(shù)據(jù)庫產(chǎn)品的好壞。寫這篇文章的目的是想把我們 TiDB 落地經(jīng)驗做個階段性總結(jié)，順便也能給同行們做個大方向上的參考。我們的這套方法論，理論上適用于任何一個需要再企業(yè)內(nèi)部引入新型數(shù)據(jù)，并且推廣的場景。本文涉及的內(nèi)容和方向比較多，無法每個模塊都做深入的探討。后面我們也會把大家感興趣的模塊單獨(dú)拆分出來做幾期深入分享。