[[282287]]

今天主要和大家分享以下內(nèi)容：

• 轉(zhuǎn)轉(zhuǎn)引入 TiDB 主要解決什么問題;
• 大規(guī)模線上應(yīng)用遇到的問題;
• TiDB 集群標(biāo)準(zhǔn)化和未來展望。

下面都是轉(zhuǎn)轉(zhuǎn)應(yīng)用 TiDB 時(shí)的一些經(jīng)驗(yàn)，供大家參考。

轉(zhuǎn)轉(zhuǎn)引入TiDB主要解決什么問題

轉(zhuǎn)轉(zhuǎn)引入 TiDB 首先解決了分庫分表的問題。某些場(chǎng)景不便于分庫分表， 分庫分表會(huì)使業(yè)務(wù)層開發(fā)邏輯變得越來越復(fù)雜，不利于降本增效的方向。其次解決了海量數(shù)據(jù)存儲(chǔ)的問題。單機(jī)容量有瓶頸，會(huì)影響最終集群的效果。

大規(guī)模線上應(yīng)用遇到的問題

轉(zhuǎn)轉(zhuǎn)在 2018 年就開始調(diào)研 TiDB，從 1.0 到 3.0。目前集群數(shù)量 30+/數(shù)據(jù)量200T+/數(shù)據(jù)節(jié)點(diǎn)/500+/日訪問量 1000 億+，主要承載用戶、交易、IM、商業(yè)等業(yè)務(wù)。

1、性能問題定位

隨著業(yè)務(wù)的擴(kuò)展，集群數(shù)量的增加，維護(hù)成本也會(huì)相應(yīng)增加。我們首先遇到的第一個(gè)問題，也是我們經(jīng)常會(huì)遇到的問題就是性能問題的定位。

業(yè)務(wù) SQL 響應(yīng)耗時(shí)突然增加了，如何定位是哪些 SQL 導(dǎo)致的?下面這圖大家在使用 TiDB 時(shí)會(huì)經(jīng)常見到，可以明顯看到某一時(shí)刻集群的響應(yīng)延遲變慢了，業(yè)務(wù)也想要知道為什么變慢了，這時(shí)候我們就要定位問題。

通常我們要打開 TiDB 監(jiān)控平臺(tái)看一些指標(biāo)：Query 的指標(biāo)、事務(wù)的指標(biāo)等，看完之后我們?cè)倏?TiDB 日志，監(jiān)控過濾關(guān)鍵字后再結(jié)合上下文去了解 TiDB 發(fā)生了什么情況。最后去看 TiKV 的日志，通過關(guān)鍵字分析后基本上能夠定位出來問題了。

如果維護(hù)的集群只是一套或兩套，沒有問題。但是當(dāng)集群增加到上十套或上百套，節(jié)點(diǎn)相應(yīng)增加時(shí)，我們?cè)趺炊ㄎ粏栴}?

2、集群管理

接下來是集群管理。運(yùn)維單套集群時(shí)沒有問題，但是管理多套集群時(shí)會(huì)遇到例如集群部署、集群版本升級(jí)、配置不兼容等問題。

簡(jiǎn)單細(xì)說一下，比如說在集群部署時(shí)，PD 在 Systemd 下會(huì)有問題，因?yàn)槊颗_(tái)機(jī)器只支持一個(gè) PD，可以通過 supervise解決，但是在起停時(shí)容易失敗。版本升級(jí)時(shí)，早期兩星期升一次級(jí)，和官方同步，但后來跟不上了，所以我們就會(huì)選擇一個(gè)版本停下來，然后觀望。

在版本升級(jí)的時(shí)候，我們遇到的問題是配置不一樣，小版本也不一樣，由于我們做了一些自定義的配置，可能在這個(gè)版本就不生效了，導(dǎo)致升級(jí)時(shí)出問題、報(bào)錯(cuò)。因?yàn)槎际蔷€上的集群，每次成本都很高。整體來說，集群管理難度增加，每次升級(jí)版本的體驗(yàn)都不太友好。

3、日志規(guī)范不統(tǒng)一

第三個(gè)問題：日志規(guī)范不統(tǒng)一。這個(gè)問題對(duì)于剛剛使用 TiDB 的用戶來說感受可能不太深，但其實(shí)1.0 的日志和 2.0 的日志是不一樣的。比如說慢日志這個(gè)日志格式，2.1 版本的關(guān)鍵字變化和 2.0 版本不兼容。這個(gè)對(duì)于我們運(yùn)維人員來說成本很高。慢日志格式從 2.1.8 之后徹底變成 MySQL 形式，上下版本不太兼容，線上目前是多版本并存，所以極大地增加了日志處理的難度。

4、慢 SQL 對(duì)集群整體穩(wěn)定性的影響

第四個(gè)問題：慢 SQL 對(duì)集群整體穩(wěn)定性的影響。對(duì)于日常來說，線上復(fù)雜統(tǒng)計(jì) SQL，大數(shù)據(jù)的 ETL 需求，以及數(shù)據(jù)臨時(shí)抽取需求都很正常，但是直接在線上操作時(shí)有可能會(huì)導(dǎo)致整個(gè)集群響應(yīng)延時(shí)變慢，最終影響整個(gè)業(yè)務(wù)的響應(yīng)延時(shí)。

5、優(yōu)化器不能正確命中索引概率較高

第五個(gè)問題：優(yōu)化器不能正確命中索引概率較高，這個(gè)問題業(yè)務(wù)經(jīng)常遇到。我的 SQL 一模一樣，一個(gè)兩秒，一個(gè)幾十毫秒，怎么解釋?比如說，在我們開啟了統(tǒng)計(jì)信息自動(dòng)統(tǒng)計(jì)、表的統(tǒng)計(jì)信息相對(duì)良好的情況下，兩個(gè)一樣的 SQL，一個(gè)走了索引，一個(gè)走了全程掃描，執(zhí)行計(jì)劃不一樣。為什么在統(tǒng)計(jì)信息相對(duì)良好的情況下索引正確命中概率不高?大家可以先思考一下。

6、事務(wù)沖突會(huì)導(dǎo)致集群性能嚴(yán)重下降

第六個(gè)問題：事務(wù)沖突會(huì)導(dǎo)致集群性能嚴(yán)重下降。例如圖中的這個(gè)問題 SQL，執(zhí)行時(shí)有一個(gè)并發(fā)更新的場(chǎng)景，在 TiDB retry_limite = 3 的情況下會(huì)嚴(yán)重影響集群性能。可以看到當(dāng) retry 出現(xiàn)時(shí)，整體鎖的狀態(tài)比較高，響應(yīng)延時(shí)也相應(yīng)增加。

TiDB集群標(biāo)準(zhǔn)化

剛剛我們整理了比較有代表性的六個(gè)問題，相信大家也有過思考。轉(zhuǎn)轉(zhuǎn)通過 TiDB 的標(biāo)準(zhǔn)化來解決：集群部署、信息收集、監(jiān)控告警和業(yè)務(wù)上線中遇到的問題。

1、集群部署標(biāo)準(zhǔn)化

在集群部署標(biāo)準(zhǔn)化方面，轉(zhuǎn)轉(zhuǎn)至少部署 3 個(gè)以上的 TiDB Server，用于 TiDB 高可用，為數(shù)據(jù)提供穩(wěn)定的接入，需要萬兆網(wǎng)卡和機(jī)械磁盤。其次需要 3 個(gè) PD Server, 千兆或萬兆網(wǎng)卡都可以，機(jī)械磁盤。最后至少 6 個(gè) TiKV Server，單獨(dú) TiKV 容量不超過 400GB，但這也因企業(yè)的使用而異，最好使用固態(tài)硬盤。

對(duì)于部署管理的建議：

• 作為 MySQL 應(yīng)用場(chǎng)景的補(bǔ)充，我們不建議接入 TiDB 的容量特別少，建議至少大于 500GB，避免浪費(fèi)資源;
• 單獨(dú) TiKV 容量不超過 400GB，這可以有效縮短 TiKV 故障之后的恢復(fù)時(shí)間;
• TiDB/TiKV 在高并發(fā)下千兆網(wǎng)卡會(huì)成為容量瓶頸，請(qǐng)使用萬兆網(wǎng)卡;
• TiKV 單機(jī)多實(shí)例，可以使用多盤掛載，將 IO 進(jìn)行隔離，目前應(yīng)用效果較好。

2、信息收集

接下來是信息收集的標(biāo)準(zhǔn)化。我們一直和官方吐槽日志能不能固定下來，一路從 1.0 追到 3.0，算是資深老用戶。對(duì)于新上 TiDB 的用戶，建議使用 2.1.8 之后的版本，日志相對(duì)穩(wěn)定，做日志的 ETL 也相對(duì)容易。官方會(huì)在未來的版本中將格式固定下來，這對(duì)社區(qū)來說是一件非常好的事情。

目前對(duì)于轉(zhuǎn)轉(zhuǎn)來說，經(jīng)過我們的規(guī)范，主要問題還是在 TiDB 的慢查詢這塊，我們針對(duì)慢查詢開發(fā)了對(duì)應(yīng)的實(shí)時(shí)慢查詢視圖，方便業(yè)務(wù) RD 觀察集群慢查詢信息。目前主要通過 Flume 進(jìn)行日志采集，最終通過平臺(tái)進(jìn)行統(tǒng)一處理、展示和告警。

3、監(jiān)控告警

下面是告警監(jiān)控標(biāo)準(zhǔn)化。TiDB 的原生報(bào)警有很多種告警和監(jiān)控，轉(zhuǎn)轉(zhuǎn)做了梳理，確保每次告警都能起到預(yù)警的效果，并且有意義，但不一定每次告警都需要人工干預(yù)。如果每天都在收?qǐng)?bào)警，會(huì)產(chǎn)生疲勞，大家就不看了，所以我們希望做到告警收斂。

還有就是告警做了簡(jiǎn)化，做定制，讓收到的人更容易理解信息。業(yè)務(wù) RD 根本看不懂 TiDB 的原生報(bào)警，他們只想知道出了什么問題，所以我們做了處理。

最后就是監(jiān)控簡(jiǎn)化，通過掃描關(guān)鍵指標(biāo)獲取集群瞬時(shí)狀態(tài)，這個(gè)目前還在和 TiDB 的同學(xué)一起做這個(gè)事情，希望能夠兼容多個(gè)版本可以獲取到集群的瞬時(shí)值，以便快速了解到集群?jiǎn)栴}、狀態(tài)，定位大方向故障。

4、業(yè)務(wù)上線

最后是業(yè)務(wù)上線標(biāo)準(zhǔn)化 。

第一是 SQL 優(yōu)化，表結(jié)構(gòu)、索引及列表全部?jī)?yōu)化。DBA 要全程參與業(yè)務(wù)上線，包括建表、SQL List，審視表結(jié)構(gòu)和 SQL，也就是我們每次要上線 TiDB 集群時(shí)，都要和業(yè)務(wù)去討論有些地方可能有問題。SQL 要全部使用 Force Index，用于解決優(yōu)化器不能正確命中索引概率高的問題。3.0 GA 中包含 SQL Plan Management，目前雖然是實(shí)驗(yàn)特性，但是大家可以測(cè)一下，這個(gè)是美團(tuán)和 TiDB 一起聯(lián)合開發(fā)的功能。然后響應(yīng)延時(shí)我們要求比較高，99.9% 控制在 100 ms 以下，99% 控制在 10 ms 以下才能上線，能解決一些常規(guī)的響應(yīng)延時(shí)。接下來就是 TiDB Explain, DBA 需要熟練掌握，并且將如何解讀其中的內(nèi)容告訴開發(fā)后才能上線。

第二是業(yè)務(wù)邏輯。在已有的業(yè)務(wù)場(chǎng)景下，并發(fā)更新同一條記錄的情況下會(huì)觸發(fā) TiDB retry，在當(dāng)前的事務(wù)模型(樂觀鎖)下表現(xiàn)并不好，怎么解決?我們使用的是轉(zhuǎn)轉(zhuǎn)自研的分布式鎖 ZZLock，即將樂觀鎖加一個(gè)分布式鎖來模擬悲觀鎖，這樣對(duì)業(yè)務(wù)響應(yīng)延時(shí)沒有問題，可以將沖突時(shí)間降到比較平穩(wěn)的時(shí)間。

第三是數(shù)據(jù)抽取，這是非常普遍的需求，我們使用了 binlog 這個(gè)組件，將 tidb-server 變更數(shù)據(jù)寫到 Pump Cluster，然后 Drainer 將數(shù)據(jù)應(yīng)用到下游集群，通過訪問下游集群，解決在線上進(jìn)行的復(fù)雜查詢、抽取等時(shí)效要求不高的需求。

TiDB未來規(guī)劃和展望

對(duì)于 TiDB 未來規(guī)劃和展望，整體來說還是圍繞降本增效這個(gè)主題，我們正在和 PingCAP 進(jìn)行容器試點(diǎn)，接下來會(huì)將 TiDB 跑在云上面。

Q & A

Q1：轉(zhuǎn)轉(zhuǎn)現(xiàn)在最大的集群是什么場(chǎng)景下的，大概有幾個(gè)節(jié)點(diǎn)?訪問 QPS 峰值有多少，數(shù)據(jù)量有多大?

A：目前最大的集群是 IM 集群，有上百個(gè)節(jié)點(diǎn)，數(shù)據(jù)量上百億。整體來說 TiKV 集群比較多，整體響應(yīng)不錯(cuò)，SQL 都是基于主鍵查詢，業(yè)務(wù)方面做得很好。

Q2：當(dāng)前線上版本分布情況是什么?為什么不都升級(jí)到2.1.8?

A：目前有 2.0、 2.0.5、2.1.7、2.1.8，主流版本是2.1.8。2.1.8以下版本還比較穩(wěn)定，有升級(jí)規(guī)劃但是業(yè)務(wù)還沒有什么需求，所以想和業(yè)務(wù)一起升上去。如果 3.0 測(cè)試效果較好，會(huì)考慮直接升級(jí)到 3.0。

Q3：一個(gè)集群有多個(gè) DB，還是只有一個(gè) DB?隔離怎么考慮?

A：一個(gè)集群只有一個(gè) DB。