作者：多點，唐萬民
導讀
時隔 2 年， 在 TiDB 社區成都地區組織者馮光普老師的協助下，TiDB 社區線下地區活動再次來到成都。來自多點 Dmall 的國內數據庫負責人唐萬民老師，在《出海多雲架構，多點 TiDB 運維實戰》的主題分享中，介紹了多點在出海業務場景部署和使用 TiDB 的經歷。本文根據唐萬民老師的演講實錄進行整理，你可以從中瞭解到多點從無到有，使用 TiDB 的業務場景，多雲架構的實踐經驗，以及版本升級遇到問題的解決方案。
多點的 TiDB 之路
目前，多點在國內和出海都有使用 TiDB 的業務，線上生產環境中共有 46 套 TiDB 集羣，300+節點，400TB+ 數據量。這些集羣支撐着包含業財融合、TMS、結算、採銷、物流、庫存憑證、履約、存貨覈算等在內豐富的業務場景。底層的雲資源也根據各地業務需求，選擇了騰訊雲、華爲雲、微軟雲、火山雲等衆多公有云。
多點大概有二十多個線上生產環境，上圖是其中一個環境的部分 TiDB 集羣，從中能看出業財一體化的數據庫流量非常大，入網出網都是 500 MB/s 左右，QPS 17, 000 看着好像不高，但其實都是一些大的查詢和操作。
多點目前部署的 TiDB 版本很多，從上圖可以看出，從 5.1.1、5.1.2，一直到現在最新升級的 6.5.8 版本都有。其中，線上版本分佈最多的是 6.1.5 版。那爲什麼多點會有如此多的 TiDB 版本，而不全部升級到 6.5.8？其實作爲 DBA 而言，對待數據庫一般情況下都是能不動就不動，一旦動了就有出問題的風險。而數據庫的絕大多數問題、風險是由變更引起的。
但爲什麼我們又要做升級呢？一是因爲業務推動，數據庫當前這個版本可能已經滿足不了業務需求，不得不升；二是高版本實在太香了，有一些新功能很想用，這個需求已經超過了升級帶來的風險。一旦做出選擇，我們就會對 TiDB 的新版本做一些調研，看看升級到哪個版本更好。這時候就不得不提到 TiDB 社區的氛圍真的非常好，TiDB 的各個版本社區小夥伴都有在用，社區裏會有很多人熱心地回答我們的一些問題，也會有很多升級、部署的實踐分享，我們在選擇新版本時就會有更多的經驗來參考。
多點與 TiDB 攜手前行
作爲 TiDB 的老朋友，多點和 TiDB 的緣分很早，從 2018 年起就接觸了 TiDB，那時候還是 2.0.3 版本。當時我們想把 MySQL 的一些複雜查詢拿到 TiDB 裏做，但是測試發現 TiDB 2.0.3 版性能確實不是那麼好，MySQL 解決不了的問題，TiDB 也解決不了。
直到 2020 年的 TiDB 4.0 版本開始，TiFlash 出現了，我們就又想嘗試一下 TiDB。當時多點的業財業務非常複雜，數據量非常多，MySQL 已經承載不了這個數據。通過調研，我們最終選擇將這部分數據遷移到 TiDB。2020 年 6 月開始，TiDB 上線測試環境；9 月，生產環境正式升級到 TiDB 4.0 GA 版本；10 月，生產環境又升級到 4.0.6 版本；2021 年 4 月，繼續升級到 4.0.9 版本；2021 年 10 月，升級到 5.1.2 版本；2022 年，升級到 5.1.4；2023 年，升級到 6.1.5；直到最近，我們升級到 TiDB 的 6.5.8 版本。其實，多點每年都在升級新的版本，這裏面當然也有一些線上的問題在推動着我們升級，後面會詳細展開。
數據庫類型選擇
多點用 TiDB 到底在做什麼？爲什麼要選擇 TiDB？我會從四個場景展開分享多點將 TiDB 應用到哪些場景中。
第一個場景 是 持續增長類數據 。TiDB 在持續 增長類的場景中是非常適合使用的，一個是它只管寫入，無限擴容，不像 MySQL，如果寫多了就要做遷移，做分庫分表，要去保證集羣的高可用，遷移代價也非常高，要去做各種各樣的溝通，還有很多遷移風險。TiDB 有一個平滑遷移的功能，並且存儲成本降低了 70%。同時，TiDB 在存儲數據時和 MySQL 不一樣， MySQL 是沒有經過壓縮的， TiDB 會經過壓縮算法將數據進行壓縮。經過我們測試，TiDB 的一個單副本和 MySQL 的單副本比起來最大有接近 10 倍的差距。即便是日誌類的數據， TiDB 是三副本， MySQL 是主從兩份數據，TiDB 的數據存儲成本也會降低很多。
第二個場景 是 數據冷熱分離，歷史數據歸檔 。我們在剛開始用 TiDB 時， DM 還沒有現在的 DM cluster 那麼成熟，所以我們自研 了 DRC-TiDB 同步工具，用這個工具去做從 MySQL 到 TiDB 的同步，將一些冷數據、歷史歸檔數據放到 TiDB 裏面。然後 MySQL 就保持高性能讀寫， TiDB 全量儲存。
第三個場 景是 合庫合表，**OLAP** 聚合查詢 。MySQL 裏的數據 分佈在不同的庫和不同的表裏面，研發在查詢時就會非常痛苦。做分庫分表的都知道，在分庫分表裏去做查詢、聚合都非常痛苦。研發其實很喜歡把很多的分庫分表，很多的數據聚合在一起，TiDB 可以非常好地支持做這個事情，並且 TiFlash 是列存的數據，有全量數據，我們可以用 TiFlash 去加速一些統計的操作。
第四個場 景是 替換 ES 。在多點內部， ES 用的非 常多，但 ES 的成本非常高。如果涉及到大數據量存儲的話，ES 需要很多機器，我們用 TiDB 做了一些 ES 的替換。實話實說，有一些查詢場景，比如模糊查詢， ES 其實比 TiDB 會更好一些。所以做 ES 替換的時候，我們也做了一些測試，如果遷到 TiDB 裏查詢性能沒有 ES 好，我們就不會去替換。實際結果測下來，有大概 60% 的 ES 是可以替換的，整體成本也降低了很多。
多點的數據技術棧架構
上圖是多點數據技術棧的整體架構。數據從 MySQL、倉儲、銷售、支付這些數據庫，通過 DRC-TiDB，流轉到 TiDB 集羣裏；財務引擎也可以直接把數據清洗轉換過來，在 TiDB 裏面去做讀寫；其他一些業務也會在 TiDB 裏面去做讀寫。在這個流程的下游，我們會在 TiDB 裏面直接去做一些分析，比如一些財務相關 API 、財務覈算、全流程的跟蹤系統、經營分析等。此外，我們還有一些大數據的需求，是通過 TiCDC 將數據流轉到 Kafka，然後再到 Spark，再到大數據離線數倉。比如說有一些離線的報表需求，都是到 Hive 裏面去做，整個流程較長。
出海業務 TiDB 部署的架構選擇
之前，多點出海業務只部署在微軟雲上，但慢慢出現了一些問題：
- 第一是多點的 RTA OS （多點的零售技術平臺）部署在微軟雲新加坡 region 上，但經常出現基礎設施不穩定的狀況，比如雲主機異常重啓，網絡異常，這些問題會導致多點的機器重啓或者服務不可用、服務之間斷聯；
- 第二是 IO 性能不符合預期。比如說有一些磁盤雖然支持 ADE 磁盤加密，但 IO 性能就不是很好。如果不支持，可能又無法滿足我們在海外的一些安全要求；
- 第三是微軟雲的成本較高。
基於這些原因，我們就從只部署微軟雲改爲“微軟雲+華爲雲”雙機房的部署模式，目標是當任意機房不可用時，TiDB 都可以自動恢復補救數據。我們通過微軟雲和華爲雲，在新加坡爲 RTA 搭建同城雙活架構，應用、中間件、數據庫跨 2 個公有云部署，實現 3 個同城機房，任意一個機房不可用業務都可以快速恢復，提高 RTA OS 可用性。
上圖是雙機房部署方案的架構圖，微軟雲有兩個 zone，華爲雲有一個 zone，TiDB 的 PD 集羣跨三個 zone 部署， TiCDC 在微軟雲和華爲雲各部署一個節點，TiDB 也在微軟雲和華爲雲各部署一套，各部署一些節點。這樣做的話，需要在 TiKV 節點打上 dc 的 label，然後去把 region 分佈在三個機房。TiDB 至少 2 個節點，跨 2 個機房部署，TiCDC 也是跨 2 個機房部署。我們也對 DRC-TiDB 同步鏈路恢復做了一些優化，做了一些 master standby 的結構，如果一個 DRC-TiDB 鏈路中， MySQL 到 TiDB 的鏈路掛了，另外一個能起到 standby 的作用。
這是我們在 TiKV 上打的一些 dc 的 label，裏面的 zone、dc、rack、 host 其實大家都可以自己配置，這只是標識出你要把 region 分佈在哪些機器、zone 上。不過，Placement rules 跟這個方法是不能一起使用的，有可能出現預期外的一些問題。
實施方面，我們將 PD 集羣從微軟雲遷移 1 個節點到華爲雲，TiKV 節點打上 dc label，從微軟雲遷出部分節點到華爲雲，等它自動 rebalance 完，然後 TiDB 也從微軟雲遷出一個節點到華爲雲。整個過程其實是非常平滑的，如果我們用 MySQL 從一個雲遷移到多個雲的話，就會非常麻煩。或者將 MySQL 從一個雲遷移到另外一個雲，也非常麻煩。我們其實做過很多 MySQL 的遷移工作，比如前段時間把騰訊雲上的 MySQL 整體遷移到火山雲，其中一些環境的工作量非常大，而且風險也很大，但 TiDB 做這種遷移就非常平滑。
多雲 TiDB 集羣實踐過程中的問題
我們在使用 TiDB 的時候也會遇到一些問題，並不是說 TiDB 就完美無缺了。但 TiDB 的社區非常開放活躍，不管遇到什麼問題，你去 asktug 上一查，很多問題都有人遇到過了，從他們的分享中你可以直接獲得幫助。
比如在 4.0.9 版本，我們遇到過 TiDB Server 的 OOM 問題。它的 expensive SQL hashagg to sreamagg 有一個問題，在內存裏面去做一個哈希，TiDB server 耗費的內存非常高。我們當時改成 stream aggregation 走這個執行計劃，內存消耗一下就降下來。在 TiDB 更新的版本里，這些問題都已經解決了。其實，在 TiDB 4.0.9 版本中，不論是 TiDB Server、TiKV 或是 TiFlash，內存控制都沒現在的版本好。那爲什麼現在的版本就會好很多？這是因爲大量的社區用戶都反饋了使用 TiDB 時遇到的問題，經過官方優化，新版本自然就解決了。
4.0.9 還有一個 CDC 的問題。CDC 因爲主要是涉及到一些大數據需求，或者需要流轉到下游的需求才會用到。如果數據量小的話，應該不會遇到很多問題。當時，我們的 CDC 就是重啓後 checkpoint 不推進，掛了以後起不來。這主要是因爲當時 sort-engine 默認是 memory，如果機器內存不夠，在重啓後做排序的時候，它內存就不夠了。後面的新版本有 unified sort DR，內存不夠了就會先放到磁盤，然後再去做一些排序，做一些 check。
此外，我們的 dashboard 當時按非時間排序查詢 slowlog ，導致了 TiDB OOM ，這是因爲 plan decode 引起 insert SQL 較大。如果 insert SQL 不大這個問題是不會產生的。還有一些執行計劃跑偏的問題，TiFlash 重啓起不來的問題，當時我們都遇到過，後續的版本都已經解決了。其實，任何數據庫，數據量很小的時候都會沒問題，一旦上了量，問題就會變多。所以有我們這種數據量比較大的用戶使用 TiDB，就會幫大家把這些雷都排了，大家再遇到這些問題就可以放心使用了。
升級也是大家都會關心的問題，升級後 TiDB 萬一起不來怎麼辦？我們在 5.1.2 版本就遇到了這個問題。TiDB 升級的正常順序應該是 TiFlash、PD、TiKV、 pump、tidb、drainer、cdc、prometheus、grafana、alertmanager 這樣一個順序。有一次，我們升級的時候 TiFlash 升級完馬上就升級 CDC 組件，跳過了 PD、TiKV、 pump，最後升級失敗了。當時 TiUP 1.5.1 版本組件可能存在問題，升級到更新的 TiUP 版本就解決了這個問題。
在 6.1.5 版本升級的時候，我們也遇到過問題。當時升級後發現 TiDB 起不來，經過仔細檢查發現是因爲我們升級前有一個大的 DDL 在跑，升級過程中這個 DDL 阻塞了升級數據字典的操作，數據字典一直沒有升級成功，導致 TiDB 就起不來。
從上圖可以看到，有一個 alter table mysql.stats_meta 去加字段的時候加不了，這是我們升級過程中遇到的異常。所以，我建議升級的時候一定要檢查有沒有大的 DDL。實際上，這個問題也是因爲我們的數據量很大，DDL 執行的時間很長，當時沒有等 DDL 跑完就重啓了，如果數據量小的話應該就不會遇到這個問題。
綜上所述，曾經遇到的問題都可以在 TiDB 的新版本得到解 決。 我給大家的建議是能用新版本就不要用舊版本 。很多問題在我們這些老用戶用 的時候就已經遇到過，這些問題已經反饋給了社區，並陸續在新版本中都已經解決了。我相信，如果用 TiDB 的人越來越多，社區也像現在這樣一直活躍的話，TiDB 就會越來越好！