TiDB 在 58 集團的應用與實踐

做者介紹：劉春雷，58 集團高級 DBA，負責 MySQL 和 TiDB 的運維工做，TUG Ambassador。

58 集團業務種類繁多，目前包括的業務有 58 同城、趕集網、安居客、58 金融公司、中華英才網、駕校一點通等，數據庫種類包括 MySQL、Redis、MongoDB、ES、TiDB。咱們本身構建了「58 雲 DB 平臺」，整合了全部數據庫的一體化運維。

本文將重點從運維的角度，介紹 TiDB 在 58 集團應用實踐及後續計劃。

1、TiDB 在 58 集團的使用概況

咱們目前使用 TiDB 的服務器爲 50+ 臺，服務器的配置爲 24 核的 CPU，128G 內存，用的是寶存的閃存卡。部署 TiKV 實例 88 個，集羣共 7 套，每一個業務一套集羣，涉及到 TiDB 多個版本。因爲是單集羣多個庫，目前庫的數量大概是 21 個左右。磁盤目前數據量並不算大，在 10T 左右。涵蓋的業務線大概目前有 7 條，包括 58 招聘、TEG、安居客、用戶增加、信息安全、金融公司還有車業務，後續還會有比較多的業務推動。

2、業務需求及解決方案

圖 1 業務及需求

業務需求目前有 4 點：

• 有大容量、須要長期保留的數據

  目前 MySQL 都是單機存儲，物理機容量有限，大約是 3T 的單機容量，因爲磁盤空間瓶頸，MySQL 擴容比較麻煩。

• 保證業務高可用

  目前咱們在 MySQL 上作的是主從複製+ MHA，這個方案有一個問題是，當主庫掛掉的時候，須要切換主從，就會影響必定時間的寫入，這對於業務來講影響比較大。

• 須要更高的讀寫性能

  MySQL 目前都是單點寫入，也就是主庫寫入，若是要讀的話，就須要經過從域名到從庫來進行讀操做，讀延時比較高，同時讀流量增長會進一步加大延遲高的問題。

• 分庫分表很痛苦

  在數據量特別大的狀況下，就須要分庫分表，分庫分表你們都比較痛苦，由於聚合比較困難，業務側開發同事也要本身維護庫表的對應路由信息。

上面這幾點在 TiDB 上都被很好的解決了，好比 TiDB 能夠水平伸縮，若是計算能力不夠的話，直接加節點就能夠了，並且 TiDB 有多副本，能夠保證數據安全及高可用。另外，TiDB Server 沒有狀態，支持多點讀寫。TiDB 無需分庫分表，操做比較簡單，也不用按期清理數據。

3、TiDB 環境建設

TiDB 的環境建設包括開發工具進行慢 SQL 的分析，完善監控系統，並把 TiDB 接入到「58 雲 DB 平臺」，收集數據、作可視化報表等等。

1. 架構

圖 2 TiDB 部署架構

TiDB 在 58 集團應用的架構如上圖，主要分爲管理機、雲平臺、監控、TiDB 集羣等四個模塊：

• 管理機

  主要是負責環境部署、監控程序、拓撲查詢後、 SQL 的分析、報表程序、TiDB 集羣的狀態檢查工具。

• 58 雲 DB 平臺

  平臺主要功能有元信息維護、工單處理、集羣信息的具體展現、監控概覽，還有一些自助查詢的接入，好比開發利用自助查詢查看各自業務的 TiDB 集羣狀況。此外還有運營報表、TiDB 集羣申請等功能。

• 監控

  包括實例監控、服務器監控和報警。

• 具體的 TiDB 集羣

  主要分爲讀寫 DNS 和只讀 DNS，分別下接讀寫 TGW 和只讀 TGW（TGW 是騰訊的 Tencent GateWay），經過讀寫帳號或者只讀帳號，路由到具體的 TiDB 集羣上。

2. TiDB 生態工具

咱們最近開發瞭如下幾個運維工具。

(1) 拓撲查詢工具：qtidb

用於查看一個集羣的具體拓撲狀況。

(2) SQL 分析工具：tidb_slow_query

TiDB 2.X 版本的慢 SQL 收集分析相比起來複雜一些，還不支持 pt-query-degist 這個工具（在最新的 2.1 及 3.0 版本中已支持），因此咱們就着手寫了一個 SQL 分析工具，直接分析慢 SQL 的一個日誌文件，將結果彙總展現（這個問題在 TiDB 3.0 中已經已經很好的解決了，直接從 SLOW_QUERY 這張表提取結果，直接進行彙總展現）。

圖 3 慢 SQL 分析工具

這個針對 TiDB 2.X 版本的慢 SQL 分析工具，主要是判斷慢日誌的採集區間，把全部的 SQL 格式化、邏輯化，把每類 SQL 的類型、具體信息採集出來，而後再把此類邏輯 SQL 的具體 SQL 放在一個具體的文件上，而後再去展現它的具體狀況，以下圖所示。

圖 4 慢SQL 分析結果舉例

主要信息包括好比排序狀況、庫名、帳號、平均執行時間、執行次數、具體邏輯 SQL 等。

(3) 狀態檢查工具：tidb_check

咱們會臨時查看某個集羣的狀態，好比宕機檢查等等。這是跟監控相似的工具，防止集羣繁忙時的狀態誤報狀況。由於咱們當前的監控是經過 Prometheus 來獲取數據的，但 Prometheus 是單點，若是 Prometheus 掛了，或者在 TiDB 集羣特別繁忙的時候，可能從 Prometheus 採集數據延遲高，而後你們判斷 TiDB 集羣可能掛掉了，這時咱們就會用 tidb_check 查看 TiDB 集羣的真實狀態。

圖 5 TiDB 狀態檢查工具

主要實現方式是根據元信息來生成一個實例的拓撲的文件，咱們查看集羣的全部的拓撲以後再去從 Prometheus 獲取數據而後彙總，最後把結果推送到 Zabbix 進行報警服務（目前咱們用 Zabbix 作統一監控、報警平臺，後面暫時沒有用官方推薦的 Altermanager），而後再入庫進行展現。其實集羣狀態誤報的問題也能夠從另一個角度來解決，從各個組件的一個接口去獲取集羣的一個狀態，防止 Prometheus 單點或其餘的問題致使誤報，這個功能目前也在開發中。

(4) 報表信息收集工具：tidb_report

報表信息收集工具也是經過 Prometheus 的一個接口來獲取數據，獲取當前的數據庫和表的狀況，到具體的集羣上面去查，在 TiDB 3.0 版本下也會查一些 Slow Query 的表，彙總慢 SQL 的狀況。

(5) 監控自動化工具：tidb_monitor

監控咱們是經過 tidb_monitor 這個工具，從 Prometheus 來獲取各個節點的監控數據，邏輯化以後推到 Zabbix，咱們的監控平臺，而後利用 Zabbix 進行趨勢圖展現和報警。

3. 平臺化

圖 6 運維管理平臺架構

在平臺化方面，咱們把 TiDB 接入到了「58 雲 DB 平臺」，利用開源 inception 來處理 DDL/DML 工單。平臺分爲管理端和用戶端，管理端就是 DBA 用來作元信息維護、工單處理、運營報表、監控概覽等。用戶端方面，業務會在上面申請 TiDB 集羣、DDL/DML 工單，帳號管理，查看集羣的信息及監控狀況，他們還能夠自助查詢庫中的數據。

圖 7 運維管理平臺展現（1/2）

圖 8 運維管理平臺展現（2/2）

TiDB 運維管理方面主要是集羣的信息展現、查看集羣的監控，或者添加 TiDB/TiKV/PD 節點。另外咱們也能夠批量添加實例，選好機器、配好角色，而後指定開發負責人，就能夠直接添加了。

4. 可視化報表

圖 9 可視化報表分類

可視化報表方面的工做是將 Prometheus 或者服務器的 Zabbix 的監控數據彙總放在平臺上，提供給開發人員和 DBA 查看，主要維度包括服務器負載狀況、CPU 內存、磁盤、網絡、IO 等。集羣方面是經過 Prometheus 的接口獲取該集羣當前使用量和總容量狀況，庫、表方面就是經過按期採集觀察庫的數據增加狀況。

4、業務及 TiDB 使用狀況

圖 10 目前使用 TiDB 的業務

目前，58 集團使用 TiDB 的業務主要有 TEG 業務、安居客（日誌類）、用戶增加業務（58 諮詢、通信錄數據保存）、信息安全（驗真中心）、金融公司（金融實時數據倉庫底層存儲）、車業務（二手車話單分配） 等，其中應用最多的是 TEG 業務。

TEG 的業務主要包含 WList、WTable 管理後臺、搜索指數等，這些都是咱們自研數據庫的管理端，目前寫入量比較大，數據量在 6T 左右，數據增加 500G/月 左右，近半年 TEG 業務損壞了 8 塊閃存卡，可是都沒有影響業務，讓咱們充分感覺到了 TiDB 高可用的優點。

圖 11 TiDB 數據庫總量增加趨勢

目前 TiDB 在 58 集團內部應用總量增加趨勢是很快的，從 2018 年中開始接入 TiDB，到目前 TiKV 實例是達到 88 個，庫的增加是達到 22 個左右，尤爲是今年第二季度開始發力增加。

5、後續計劃

咱們後續計劃將服務管理平臺、PMC 訂單流水等 6 個業務，共 18 套 MySQL 集羣所有遷移到 TiDB，總計磁盤量 30T，數據量 2000 億。其中最重要的是 PMC 訂單流水這個庫，它有 8 套 MySQL 集羣都是分庫，每套集羣磁盤量 2T，遷移 TiDB 的過程應該會有很大的挑戰。

圖 12 後續計劃使用 TiDB 的業務

在運維方面，咱們已經着手準備版本升級，可能會所有遷到 TiDB 3.0 版本，目前已經升級了一套，仍是很是平穩的。至於監控完善，剛剛已經提到過，以後監控工具將經過多個組件接口來獲取數據，防止單點問題致使誤報。在報表功能方面，咱們也在持續開發完善，好比包括 3.0 版本下的慢 SQL 查詢的優化等。另外，由於有數倉類的業務，因此咱們也考慮使用 TiSpark 和 TiFlash 提高系統性能。最後，咱們也在作自動化部署、擴縮容、故障處理方面的開發。

本文整理自劉春雷老師在 TiDB TechDay 2019 成都站上的演講。

原文閱讀：pingcap.com/cases-cn/us…

更多案例閱讀：pingcap.com/cases-cn/