[[282287]]

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

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

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

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

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

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

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

1、性能問題定位

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

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

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

如果維護的集群只是一套或兩套，沒有問題。但是當(dāng)集群增加到上十套或上百套，節(jié)點相應(yīng)增加時，我們怎么定位問題?

2、集群管理

接下來是集群管理。運維單套集群時沒有問題，但是管理多套集群時會遇到例如集群部署、集群版本升級、配置不兼容等問題。

簡單細說一下，比如說在集群部署時，PD 在 Systemd 下會有問題，因為每臺機器只支持一個 PD，可以通過 supervise解決，但是在起停時容易失敗。版本升級時，早期兩星期升一次級，和官方同步，但后來跟不上了，所以我們就會選擇一個版本停下來，然后觀望。

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

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

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

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

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

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

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

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

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

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

剛剛我們整理了比較有代表性的六個問題，相信大家也有過思考。轉(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 個以上的 TiDB Server，用于 TiDB 高可用，為數(shù)據(jù)提供穩(wěn)定的接入，需要萬兆網(wǎng)卡和機械磁盤。其次需要 3 個 PD Server, 千兆或萬兆網(wǎng)卡都可以，機械磁盤。最后至少 6 個 TiKV Server，單獨 TiKV 容量不超過 400GB，但這也因企業(yè)的使用而異，最好使用固態(tài)硬盤。

對于部署管理的建議：

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

2、信息收集

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

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

3、監(jiān)控告警

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

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

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

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

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

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

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

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

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

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

Q & A

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

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

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

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

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

A：一個集群只有一個 DB。