TiDB 4.0 新特性在電商行業的探索

446次閱讀

作者介紹：冀浩東，轉轉公司數據庫負責人，負責轉轉公司整體的數據庫運營。

初引入 TiDB 解決了哪些問題？

轉轉使用 TiDB 主要解決了兩個問題，一個是分庫分表問題，另一個是運維復雜度。

分庫分表是一個非常普遍的問題，會增加我們業務邏輯的復雜性，并且多維度的 mapping 可能導致我們整體性能的下降。有了 TiDB 我們可以不用再考慮分庫分表，不再需要寫那么多的復雜邏輯。

對于運維復雜度來說，TiDB 可以做到快速的水平擴展，無需 DBA 進行復雜的數據搬遷，也無需業務進行流量遷移，并且大表的 Online DDL，基本上對于業務感知力度不大。

產生的新問題

引入 TiDB 后，隨之也帶來了一些新的問題。

部署慢、管理難。TiDB Ansible 在管理多個 TiDB 集群的時候，會有各種各樣不同的異常，這會極大的增加我們的運維復雜度。

熱點無法快速定位。對于電商場景，數據熱點是一個比較常見的問題。因為 TiDB 節點眾多，無法快速定位熱點 KEY，需要查詢各個節點的日志，逐步排查，排查成本較高。

無法快速查看集群狀態。監控項太多，并且日志都比較分散，某一時間我們要確認集群狀態，只能是一步一步來，慢慢的分析，無法迅速對集群異常進行定位。

數據抽取會增加線上響應延時。這是一個非常常見的問題，因為數據抽取也影響我們 TiKV 的性能。

超大集群無法做到有效的備份。對于超大集群的快速的備份和恢復，其實是一個亟待解決的問題。之前，我們在數據量規模非常大的情況下才會用到 TiDB，這個時候備份其實是非常迫切的。之前我們一直是邏輯備份，但是邏輯備份對于我們來講有效性并不高。

TiKV 線程池的配置復雜及對業務的影響。部署 TiKV 時會配置線程數量，需要配置 3 個優先級；對于不同業務的場景需要配置 readpool.storage / readpool.coprocessor 兩個 readpool 線程池；。隨著我們業務的發展與迭代，我們的 SQL 也都不一樣，所以在使用 readpool 的時候，方式也不一樣，并且如果調整線程配置，會不同程度的影響業務訪問。

TiDB 4.0 解決了哪些問題？

那我們接下來看一下 TiDB 4.0 版本可以解決哪些問題。

集群部署管理問題——TiUP

之前在使用 TiDB Ansible 管理的時候，其實是比較困難的，并且 TiDB Ansible 自身也存在一些問題。TiDB 4.0 開發了一個全新的組件管理工具——TiUP，這個工具目前在體驗上是非常好的，我們在一分鐘內就可以部署完成 3 個 TiDB，3 個 PD， 3 個 TiKV 和 1 個 TiFlash，這個效果是非常驚艷的，而且 TiUP 也有大量的參數可以查看我們集群的狀態。我們要特別提醒一點，TiFlash 的端口管理非常復雜，有特別多的端口，大家在使用的時候一定要做好 TiFlash 端口管理。

數據熱點問題——Key Visualizer

在早期，熱點問題我們只能通過各種日志去排查，然后慢慢的分析，再找到它。現在有一個新的可視化工具叫 Key Visualizer，它可以快速直觀的觀察我們整個集群的熱點情況。如上圖所示，我們將線上集群，通過數據和流量的復制過來以后，把新的流量導過來。我們可以看到任意時間點集群的寫入情況，例如我們可以看到當前情況下，字節寫入量，哪個庫，哪張表，以及它的 rowkey。在右圖，通過集群的明亮程度這個判斷指標，就可以看到我們整體 KEY 的一個繁忙程度，這張圖整體來講，這是一個比較符合預期的狀態，寫入整體比較均勻。如果是熱點的話，可能會出現一條線，可以明顯的看到我們的熱點 KEY，有了一個工具，我們可以快速的找到熱點 KEY。

快速查看集群狀態問題——TiDB DashBoard

針對集群狀態無法快速定位的問題，TiDB 4.0 有一個新的組件叫 TiDB DashBoard。通過 TiDB DashBoard 以及 TiDB 的集群的診斷報告，我們可以快速拿到集群的基本信息、負載信息、組件信息、配置信息以及錯誤信息，這些信息其實已經非常的豐富了，對于我們來講是非常有效的，可以穩準狠的找到我們的集群的異常。

TiDB DashBoard 是 TiDB 4.0 特別有亮點的一個功能，它可以實時的獲取到我們集群的信息。上圖是 DashBoard 概況頁面，里面包含了 QPS、響應延遲、節點的狀態，以及告警相關的一些內容。通過概況， DBA 可以迅速的查到集群的狀態，快速定位問題，提高了應用性，可以說 TiDB 4.0 整體的應用性已經非常高了。

慢查詢可以說是里程碑的一個功能。之前一直在吐槽 TiDB 慢查詢的問題，我們從 1.0 吐槽到 4.0，但是 4.0 有了 DashBoard 后，可以指定數據庫，查看不同的慢查詢，也可以快速的定位我們的慢查詢。我們不再需要自己 ETL，也不需要自己再上機器，就可以快速的定位到慢查詢，而且包含排序、執行時間等信息，這是對于即將要使用 TiDB 的公司來講，一個非常利好的消息。

我們可以通過慢查詢找到我們的慢查詢的列表，有了列表之后，我們就可以知道具體的 SQL 語句。SQL 語句信息包含 SQL 語句的模板、指紋 ID、樣例、執行計劃，以及事物相關的一些指標，這個指標對我們來講是非常難得的。在我們自己做 ETL 的時候，其實很多指標和信息是拿不到的，但是現在通過 SQL 語句分析，我們可以看到慢查詢的各個執行階段，也可以看到各個階段的執行時間，提高了我們整體 SQL 分析的體驗。

現在還添加了日志搜索功能。在早期我們做 ETL 的時候，需要檢索各種各樣的日志，然后再去分析，現在有了這個日志搜索這個功能，我們不再需要登陸機器了，也不再需要去做對應的系統來分析日志，這會極大的降低我們的人力成本和開發成本。有了這個工具以后，我們可以指定時間段，指定日志等級，還可以指定它的節點，通過節點可以檢索到我們最新的一些日志，這個對我們來講是非常友好的。

數據抽取增加線上響應延時問題——TiFlash 節點

現在我們啟用了 TiFlash 節點來解決數據抽取會增加線上響應延時的問題。TiFlash 的特性包括異步復制、一致性、智能選擇和計算加速，具體原理就不講了，我們主要講一下在轉轉的使用場景。在轉轉主要的使用場景是供數節點和物理隔離，相當于在新的機器上加了一個 TiKV 的節點，我們做了一個分離，不同的請求走不同的后端數據節點，這樣在進行數據抽取的時候，它不會影響到整體的線上性能。并且這是智能選擇的，可以根據我們業務、SQL 的復雜度，自己去判斷該走 TiKV 還是走 TiFlash，線上的就走 TiKV，線下的就走 TiFlash，這個是強制的。

超大集群無法做到有效備份——Backup & Restore

分布式備份恢復工具 Backup & Restore 解決了超大集群無法做到有效備份的問題。通過我們做的測試，在萬兆網卡的環境下，300GB 的數據，限速 120MB/s 的情況下，備份到網絡文件系統，耗時不到 10 分鐘。在同樣限速 120MB/s 的條件下，通過網絡文件系統進行數據恢復，我們測試的結果是耗時約 12 分鐘，可以說是極大的降低了我們備份恢復的時間。并且還有一個關鍵因素，就是備份的速度完全取決于我們 TiKV 的多少，TiKV 越多，我們的備份速度越快，恢復的速度也越快。

TiKV 線程池的配置問題——unified read pool

TiDB 4.0 的一個新的優化功能就是 unified read pool 的線程池。在 4.0 之前，我們的 readpool storage 和 coprocessor 是需要自己配置的，調整的時候也是自己動態去調整，而且每次調整可能會影響到業務，這個是比較痛的一個點。unified read pool 將 storage 和 coprocessor 這兩個進行了一個合并，合并到一個線程池里面。我們使用 storage 還是 coprocessor 是由我們的 SQL 自己來判斷，如果說我們需要用 storage，那我們就用 storage，需要 coprocessor，我們就用 coprocessor。這不僅提高了我們的使用體驗，也解決了我們資源分配不均勻的問題。上圖展示了我們如何開啟 unified read pool 的線程池的配置。