58 集團的 TiDB 技術實踐及經驗總結

大家好,我是來自 58 集團的 DBA 旋凱,今天給大家帶來的分享題目是 “58 集團數據庫技術選型思路”。

首先,我給大家介紹一下我們集團的業務概況。我們的業務範圍包含 58 同城、趕集、安居客、58 金融、中華英才、駕校一點通等公司。我們使用的數據庫有 MySQL、Redis、MongoDB、ES、TiDB等,大概每天的訪問情況在 8000 億次左右,集羣數量 4000+,物理服務器數量 1500+。

TiDB 在 58 集團的使用情況

我們現在線上生產環境一共有 11 套 TiDB 集羣,版本爲 3.0.3,物理機數量 80 臺,數據總量 40T,每天的訪問量在 10 億次左右。我們一共有 2300 套 MySQL 集羣,11 套 TiDB 集羣,比例大概爲 0.47%,訪問量比例爲 2%。

從響應時間來,TiDB 是分佈式數據庫,響應時間與單機的 MySQL 相比較高。之前我們做過的測試顯示 TiDB 與 MySQL 響應耗時比在 1.2 到 1.5 左右,可以接受,所以正在將 MySQL 逐步替換爲 TiDB 。

TiDB 在 58 集團的使用場景爲交易賬戶流水(也是現在最大的一個庫)、金融數倉、私有云監控、用戶行爲日誌、語音機器人、客服系統、廣告投放系統、交友系統、帖子信息等。

TiDB 的選型過程

我們從 2018 年的 Q1 開始調研 TiDB 2.0,當時我們遇到的問題場景是私有云監控的數據存儲在 MySQL,由於數據量巨大需要定期清理表,給 DBA 帶來了很大的工作量。

我們知道 TiDB 後開始調研,最終在 2018 年 4 月上線了第一個 TiDB,遷移了公司內部系統的一個監控日誌。第一套量非常小,訪問量大概每秒2000 左右,整體數據量在 7T~8T 之間。2018 年 12 月,我們開始測試 2.1 GA 版本,這個時候線上已經有大概 4 套集羣,存儲了內部私有云的全部日誌系統。到了 2019 年 9 月,我們線上和測試環境已經全部接入 TiDB 3.0.2。

我們使用 TiDB 主要解決了幾個 MySQL 遇到問題:

  • MySQL 單機容量有限,例如存儲日誌類數據需要定時清理的問題;
  • 分庫分表問題,58 集團沒有中間件團隊,開發側需要自己運維分表場景,同時,分庫分表後對於後期的數據聚合及 ETL 來說工作量也非常大;
  • MySQL 自身高可用的問題(8.0 之後的 MGR 還可以),之前我們使用了 MHA, 但是增加了維護成本;
  • MySQL 的從庫延遲問題,之前我們進行 DDL 時會造成從庫的延遲,這會對實時讀造成很大的影響;
  • 單機寫入量過大 MySQL 承受不了的問題,58 集團的一個規矩是當單點寫入達到 15,000 的時候,我們就會進行拆庫,而 TiDB 可以進行多點寫入。

這就引申出了我們選擇數據庫的一些思考維度:

  • 社區活躍度,如果社區不活躍,遇到問題或 bug 無法得到解決,就會被 PASS;
  • 方便運維,TiDB 自身的運維體系,包括高可用、一致性、監控等維度都非常好,我們可以很快地把它接入到內部的運維平臺上;
  • 能不能解決現有問題,例如我們遇到了大量的分庫分表,大量的數據刪除和寫入等問題,超出了現有數據庫的承受範圍。

於是我們選擇了 NewSQL 數據庫的代表 TiDB 來解決這些問題。

前面我們提到使用 MySQL 時我們遇到的一些問題,那麼TiDB 是怎麼解決的呢?

  • 首先 TiDB 是分佈式存儲,可以水平擴展,解決了我們單機容量小的問題;
  • 其次 TiDB 具備的高可用特性解決了我們額外準備高可用服務帶來的運維成本問題;
  • 再次 TiDB 支持多點數據寫入,解決了我們單機寫入量在 15,000 左右就會出現瓶頸的問題;
  • 最後 TiDB 提供了分庫分表的聚合方案,它的監控體系也比較完善,不需要額外搭建監控體系。

TiDB 在 58 集團的使用架構

我們的 TiDB 架構比較簡單,應用上首先是分讀寫域名,後端使用 Load Balance 。默認情況下我們一套集羣上有 4 個 TiDB 節點,一個寫三個讀,如果寫達到瓶頸的話,可以擴容 TiDB 節點。

58 集團的 TiDB 體系建設

首先,我們建設了一個工單系統,開發人員要通過私有云平臺去進行數據庫的日常操作,比如 DDL、DML 等,不能直接連數據庫。

第二,我們做了一套監控系統,把 TiDB 的監控數據從 Prometheus 同步到我們的 Zabbix 上,然後在私有云平臺上根據我們的數據模型進行展示。

第三,我們做了一個自助查詢系統可以快速生成 SQL,而 SQL 可以直接進行數據導出,提高了 RD 使用平臺的效率。

第四,我們做了一個報表系統便於管理集羣,通過抓取 Prometheus 裏的數據在運維平臺上進行報表展示,每天的值班 DBA 通過報表可以掌握各集羣的狀態:是否有報錯、容量是否充足、是否需要擴容等。

第五,我們做了一個日常巡檢系統,會每天早晨九點和晚上六點對 TiDB 集羣進行巡檢。目前巡檢項目比較簡單,大概就十幾項,能夠幫我們及時發現一些隱患,比如某個時間點慢日誌突然爆增,某個表上的索引缺失,或是錯誤日誌裏出現異常等。

第六,近期我們做了運維工具和備份系統,使得數據庫能夠滿足審計的需要。

TiDB 工單系統介紹

我們的 TiDB 工單系統支持建表工單、改表工單、數據導出、數據變更、帳號授權等工單,能夠滿足大部分 RD 的日常需求。後端走的是 Inception 校驗,再提交到 TiDB 去執行,和 MySQL 的路徑一樣。但我們在 Inception 那裏和 MySQL 的規則做了一些區分,比如說目前 TiDB 不支持自增主鍵,但 MySQL 要求必須有自增主鍵。

監控系統

首先 Collector 會從雲 DB 平臺上拉取 TiDB 的硬件信息,再同步更新到 Ansible 的配置文件裏比較一致性,如果不一致就進行更新。Collector 會到 Prometheus 上拉取監控數據,再把數據通過 Zabbix_sender 發送到 Zabbix 上,如果發現異常 Zabbix 後端會把告警發到微信、短信、郵件、IM 中。

TiDB 運維

運維工具這一塊我們做了這麼幾項:我們有集羣拓撲的查詢工具、集羣的狀態檢查、慢日誌分析、TiDB 監控、檢查、自動部署、會話管理這些工具。

58 集團使用 TiDB 的經驗

最開始我們使用 TiDB 時,因爲機器上有四塊磁盤,於是我們在一臺機器上布了 4 個 TiKV,但造成了宕機時間特別長的問題,最長的一次是一臺 TiKV 機器宕機之後大概兩個半小時沒起來,解決方法就是打 label。打完 label,用了 3.0.1 後發現宕機時間還是比較長,於是我們尋求了 TiDB 官方人員的幫助,升級到 3.0.2 後宕機時間縮短到了一分鐘左右。

第二是 SQL 語法報錯,給大家舉個例子,3.0.1 時 left join 超過 4 個時可能就會報語法錯誤,select for update 的執行也有問題,目前在新的新版本都已經解決掉了。

第三是我們之前選機器的時候,是根據磁盤去部署 TiKV 的,後來發現 CPU 資源不夠用了,TiKV 越升級 CPU 使用越多。我們跟官方人員溝通後換了一個新的機型,增加了 CPU 的核數,然後減少了 TiKV 的數量。於是我們得出了一個結論:用最好的機器,用最新的版本,遇到問題都會解決的。

後續規劃

這部分主要分爲四個方向。

首先我們會對監控模型進行優化,現在只是簡單地從 Prometheus 里拉取數據然後放到 Zabbix 去做報警,平臺再根據 Zabbix 數據進行聚合和展示,不如 MySQL 的監控那麼完善。

其次,我們會把 TiDB 和 TiKV 的自動擴縮容放到我們的運維平臺上去做。

接下來我們會搭建一個慢日誌系統。目前 MySQL 有慢日誌系統,包括每日的報表和一個類似實時流水的日誌,但是 TiDB 的日誌格式和 MySQL 不太一樣,目前我們就只能實時去文件系統裏讀,後續我們會單獨做一套 TiDB 的慢日誌系統。

最後是一個實時的數據恢復,因爲現在 TiDB 官方還沒有比較理想的備份系統,我們只是簡單用 Mydumper 去進行備份,之後我們也會用 Binlog 做實時備份,並且對兩塊的數據進行連動。

Q&A

Q1:你好,我想問一下,58 集團的 TiDB 備份恢復系統是怎麼實現的?是物理備份,還是邏輯備份,備份以後,這些文件有沒有什麼壓縮之類的這樣的優化?

A:是這樣的,官方的物理備份還沒有出,我們只是用 Mydumper 進行簡單的邏輯備份。如果庫比較小,我們會整個備份,如果比較大,我們會排優先級,會優先對一些重要的表進行單表的 Mydumper 備份,是邏輯備份,備份之後我們會放到專有的存儲機上。Binlog 也會實時備份到存儲機上,我們可以手動去找 Binlog 文件和備份文件,如果有需要可以進行相應恢復。

Q2:我想問一下,當前 58 集團的 TiDB 機器選型,大概用的是什麼樣的機器?

A:我們最開始引入 TiDB 的時候沒有把它當做一個核心的數據庫,所以我們採用了 DBA 這邊的低配機器,當時是 32 核的 CPU,型號是 E5 的 2630,主頻 2.1的,磁盤是 1.7T 的一個 PCIE 板卡,但是這個卡比較老了,是英特爾的 4530。上了 2.1 之後,我們發現 CPU 不夠用了,當時看了下,業務也沒有那麼大量,我們就忍了。後續到了 3.0 之後,CPU 的核數需求上升了,然後我們就開始換機器選型,現在採用了和 MySQL 一樣的配置機器,單臺核數沒變,還是 32 核,CPU 主頻提到 2.4,磁盤是單盤 1.7T 的,內存都是 128 的。今年第三季度採購了一批新機器,內存是 256 的,CPU 的主頻降到 2.1,核數是 48 核。

Q3:現在在一臺物理機上起多少個實例呢?

A:現在使用 3.0 版本的機器是一個機器上使用一個 TiKV。我們後續的一個機型是 48 核的機器,內存增加,磁盤是三塊 SSD。

Q4:請問一下,你剛纔提到有一個 select for update,這種悲觀鎖的這種場景,之前 TiDB 並不支持,我想請問一下你們這邊怎麼解決的呢?

A:這個悲觀鎖我們用的也是比較少的。之前我們金融數倉的同事反饋說它的執行和預期不符,但是 DBA 是沒有辦法去修復這個問題的,所以我們暫時讓他用樂觀鎖,我看官方的版本 3.0.3 裏面也解決了這個問題,但後續還需要測試。

作者介紹

旋凱:58 集團 DBA,TiDB User Group (TUG) 大使。

本文轉載自 AskTUG

原文鏈接

https://asktug.com/t/topic/1784

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章