TiDB從 0 到 200+ 節(jié)點的小紅書探索和應用是怎樣的

TiDB從 0 到 200+ 節(jié)點的小紅書探索和應用是怎樣的，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

小紅書使用 TiDB 歷史可以追溯到 2017 年甚至更早，那時在物流、倉庫等對新技術比較感興趣的場景下應用，在 2018 年 5 月之后，我們就開始逐步鋪開，延展到其他適合 TiDB 的場景中去。截止目前，小紅書使用的 TiDB 節(jié)點數(shù)在 200+ 個，未來也有更大擴展空間。

本文根據(jù)近兩年 TiDB 在小紅書的落地過程，和大家一起探討一下，小紅書在新數(shù)據(jù)庫選型的考慮因素、以及 TiDB 從場景分類的角度是如何考量及逐步推廣使用的。具體包括以下內(nèi)容：

1. 目前小紅書數(shù)據(jù)服務整體架構(gòu)，以及從數(shù)據(jù)流角度如何對不同數(shù)據(jù)庫服務進行定義和劃分。

2. 從基本功能、數(shù)據(jù)同步、部署管理、運維、二次開發(fā)及優(yōu)化、安全等多個維度解讀小紅書在數(shù)據(jù)庫選型的考慮因素及思考。

3. TiDB 的適用場景，以及在小紅書如何進行場景選擇、如何逐步進行上線規(guī)劃。

一、小紅書數(shù)據(jù)服務整體架構(gòu)

如圖 1 所示，小紅書數(shù)據(jù)服務整體架構(gòu)最上層是在線應用層（online app），應用層往下肯定會依賴一些離線（offline）或者在線（online）的 database（其實它更多的意義應該算存儲，比如 Redis 也被我們理解為 database，所以稱之為“數(shù)據(jù)服務”可能會更好），這些在線數(shù)據(jù)服務（online database）會有兩條線：

• 通過實時數(shù)據(jù)流（dataflow）將數(shù)據(jù)導入到離線數(shù)據(jù)庫（offline database）支撐離線分析以及實時展示的場景，也就是圖 1 最下層的展示類服務（presentation）和數(shù)倉（data warehouse）。

• 這些數(shù)據(jù)還可能會回灌到線上其他 database 上，有些是離線，有些是實時。

圖 1 藍框中的部分基本上都由我們團隊負責。我們首先需要保證在線數(shù)據(jù)庫（online database） 的穩(wěn)定性、安全性以及性能優(yōu)化等，其次我們的多種數(shù)據(jù)庫數(shù)據(jù)同步服務（database to database replication） 有點像阿里提出的 data replication center 這個概念，這部分也基本上由我們團隊全權(quán)負責。

二、小紅書數(shù)據(jù)服務組件選型 RoadMap

對于一個新的數(shù)據(jù)庫或數(shù)據(jù)服務組件選型（如 TiDB），我們該從哪些方面去入手搞清楚它的特性？下面分享一下我們的經(jīng)驗。

1. 產(chǎn)品的基本功能

第一步，我們需要考察該數(shù)據(jù)服務/組件的基本功能，首先，我們要了解它的讀寫場景，包括點查、批量獲?。╞atch get）、范圍掃描（range scan）、過濾查詢（filter query）、聚合查詢（aggregation）等等。然后我們看看它是否符合響應時間（latency） 以及帶寬（bandwidth，即能承接多少并發(fā)）的要求。最后我們會關注可擴展性，比如 TiDB 可能最大的特點就是擴展性非常好。這幾點是大家都會想到的最基本的要求，這里我就一筆略過。

2. 數(shù)據(jù)同步與處理相關解決方案

第二部分是數(shù)據(jù)同步與處理相關解決方案。這里我們有以下 4 點考慮：

• 首先考慮這個數(shù)據(jù)服務組件的數(shù)據(jù)同步是同構(gòu)或異構(gòu)的場景，同構(gòu)的同步比如 Redis to Redis、MongoDB to MongoDB，異構(gòu)的同步比如 TiDB 到 Kafka 等等。這個情況基本上大家也會遇到，因為一個數(shù)據(jù)服務很難同時支持兩種或更多的場景，不同的數(shù)據(jù)服務之間的數(shù)據(jù)要保持一致，就會產(chǎn)生數(shù)據(jù)同步的問題。

• 接下來考察離線導出，比如如果我們依賴 Hive、 Spark 做離線分析，那么可能要放在 HDFS、S3 等對象存儲上，就需要離線導出，一般是每天導出一次。

• 第三點是實時導出，即在實時場景下可能需要導出到消息中間件，比如 Kafka、RocketMQ 等。

• 第四點是離線導入，導入的場景一般是在離線的引擎計算的結(jié)果，作為評估的指標再寫入線上的 database 提供數(shù)據(jù)服務。

3. 產(chǎn)品的部署及管理

部署其實非常重要，它涵蓋以下 5 個方面。

• 第一點是組件管理界面。當集群多到一定程度時，如果你沒有一個很好的管理界面，會連自己用的是什么集群都記不清楚。所以管理界面非常必要，而且最初可能是 1 個集群 1 個管理界面，然后是 100 個集群 1 個管理界面。

• 第二點是選版本和機型。在版本選擇方面，不同版本提供的功能不一樣，同時也要考慮版本升級的成本。在機型的選擇方面，無論是自建機房、用云主機，還是使用最近推出來的新概念“Bare-Metal”（裸金屬），機型選擇都是非常痛苦的事情，但同時機型選擇對存儲來說至關重要。我們目前絕大多數(shù)都是部署在騰訊云和 AWS 上，并且開始慢慢嘗試在 Bare-Metal 上的應用。

• 第三點是監(jiān)控、報警、日志收集。我將這個問題分為三個級別：機器級、應用級和業(yè)務級。機器級指機器主機上的問題，包括如何做監(jiān)控、報警、日志收集，雖然這點與該數(shù)據(jù)服務組件沒有太大關系，但是我們?nèi)匀恍枰P注；應用級指該數(shù)據(jù)服務組件的報警、監(jiān)控、日志收集具體是怎么做的；業(yè)務級指特定的業(yè)務有特定的報警需求，例如一個訂單表突然有幾十萬的 QPS 寫入，在平時屬于異常的情況，這種異常是需要自定義的，甚至需要我們在某些特定位置埋點并輸出結(jié)論，因為如果不關注這些異常情況，就很可能導致這三件事用三種不同架構(gòu)，最后部署的集群極其復雜繁瑣，三個級別用了三個不同的監(jiān)控工具，看到三個不同的監(jiān)控界面，導致運維成本增加。

• 第四點是跨區(qū)/跨云部署。這一點可能是互聯(lián)網(wǎng)公司的比較大的需求。在遇到跨區(qū)/跨云的部署的時候，需要考察該數(shù)據(jù)服務組件是否天生支持跨區(qū)/跨云。如果不支持，需要再考慮是否需要再啟動數(shù)據(jù)同步。

• 第五點是考察附屬組件，也就是與該數(shù)據(jù)服務組件強綁定的其他組件，比如 zk、lb、jmx_exporter 等等，這些組件的部署成本也需要考慮。我們需要減少 OPS 成本，或者說，一個好的整體架構(gòu)設計能夠防止業(yè)務瘋狂上線時很多意外的出現(xiàn)。

4. 運維的易用性

運維包括擴容、縮容、遷移，其中遷移可能要考慮跨區(qū)遷移、機型升級遷移等。在使用維護某個組件的時候會產(chǎn)出“XX 組件的運維手冊”，這樣下次遇到問題的時候，可以先去看看運維手冊里它是否是一個已知問題，有沒有現(xiàn)成的解決方案。在公司人員變動比較頻繁或者業(yè)務方直接介入到這個場景的時候，如果沒有運維手冊，有些項目很難落地。

5. 產(chǎn)品可優(yōu)化的空間

優(yōu)化部分基本上分為配置調(diào)優(yōu)、客戶端代碼調(diào)優(yōu)、二次開發(fā)、三次開發(fā)。其中二次開發(fā)就是在現(xiàn)有的開源產(chǎn)品上再開發(fā)，修復 bug 或者自己實現(xiàn)某些新增功能/工具，未來可能還會貢獻給社區(qū)；而三次開發(fā)則是自己寫一個和某些組件類似的東西，直接替換掉。在小紅書內(nèi)部，二次開發(fā)是比較主流的，三次開發(fā)很少，畢竟從零開始自研一個組件到適應特定業(yè)務場景，其實是跟不上我們的業(yè)務上線節(jié)奏的，所以三次開發(fā)至少眼下不適合作為我們主要的攻堅方向。

6. 其他考慮因素

未來在小紅書數(shù)據(jù)服務組件系統(tǒng)，我們會做很多完善工作，比如安全、審計、服務化、容器化等方面的事情。譬如我們目前在部署一個組件的時候，容器化還沒有在討論范圍之內(nèi)，也就是需要用容器部署就容器部署，需要在虛擬機上部署就在虛擬機上部署，并沒有一個明確的結(jié)論傾向。當然，我個人認為未來容器化是一個主流趨勢。

以上就是小紅書的數(shù)據(jù)服務組件選型的 RoadMap，看起來跟接下來要講的“TiDB 在小紅書多場景下的應用”沒有太大的關系，但我認為在做應用之前應該先把上面列舉的這些方向思考清楚，這樣會對未來落地工作的投入產(chǎn)出比產(chǎn)生非常大的影響，比如我們最近按照上面的方向調(diào)研 Tidis 和 TiFlash 的時候速度就快很多。

三、TiDB 在小紅書多場景下的應用

場景 1：展示類業(yè)務

TiDB 在小紅書的第一個應用場景是展示類業(yè)務，它的 pipeline 如圖 4 中紅色部分所示，線上一般是 MongoDB 或者 MySQL，通過一條實時數(shù)據(jù)流（realtime dataflow） 連接 Redis 或者 TiDB，最后實現(xiàn) presentation 功能。接下來介紹這類場景下的兩個具體項目。

項目 1：大促實時看板

第一個項目是大促實時看板，在去年雙十一期間上線，當時我們的節(jié)奏也比較快，7、8 月開始調(diào)研，11 月就上大促業(yè)務。

當時該項目下一共有 8 個實時報表，QPS 寫入均值 5K，大促活動開始時 QPS 峰值接近 200K/秒，每過 2s 會有較大的聚合查詢 query，聚合結(jié)果還需要寫入 Redis 再 pop 到 TiDB，集群規(guī)模方面只用了 10 個 TiKV 和 3 個 PD。還有一點值得提一下，當時每個節(jié)點掛了 3.5T * 4 塊的 NVME SSD，但是后來事實證明這個選型是有問題的，因為大促的時候我們?nèi)巳硕荚诙⒅?，磁盤壞了會立刻得到解決，所以即使把四塊盤做了 raid0，然后上線了，根本無法確定 NVME 盤出問題的概率是多少，后來差不多每個月會出現(xiàn)一兩次類似的故障，故障率很高，雖然我相信未來 NVME 會做得更好，但這樣高的故障率從設計角度來看，這個選型就未必是最合適的。

在實現(xiàn)上，我們遇到的第一個問題是保證最終一致性的寫入。我們做了多線程寫入，每個線程寫入特定的記錄，保證線程之間不會沖突。除此之外，我們還做了一些調(diào)優(yōu)工作，我們發(fā)現(xiàn)每一個事務的 batch insert size 設置為 100 時能達到吞吐、延遲綜合最優(yōu)的要求。最初業(yè)務側(cè)設置的 batch size 非常大，后來發(fā)現(xiàn)事務之間沖突的概率、響應的時間等等都會出現(xiàn)一些問題，但 batch size 設置為 1，那么并發(fā)又會成為一個問題。所以經(jīng)過了一段時間的調(diào)優(yōu)，最后得到了前面的結(jié)論。這個參數(shù)大家可以根據(jù)需求自己調(diào)整，用二分法/折紙法試驗就可以得到。

這個項目最終全程寫入和查詢在大促期間保持穩(wěn)定，寫入時延小于 20ms，查詢時延小于 1s，因為我們需要 2s 做一次查詢，這個響應時間是能滿足要求的。

項目 2：實時業(yè)務數(shù)據(jù)展示

這個項目背景有兩點：

• 第一，我們業(yè)務方有實時分析的需求，需要實時觀測線上庫寫入內(nèi)容，可能是針對某個用戶做一些查詢，還可能是一個非常大的 query，比如需要快速看到新上線功能的效果，尤其是在實驗以及風控等項目上響應時間要求非常高。

• 其次需要作為離線 ETL 任務的數(shù)據(jù)源，同時需要預備改為線上服務。盤算一下業(yè)務量，總共支持需要超過一百個 MongoDB 或 MySQL 數(shù)據(jù)庫的實時展示，峰值總讀寫 QPS 超過 500K，現(xiàn)在的業(yè)務需求大概這個量級，未來可能會更高。

我們當前考慮是按業(yè)務線去拆分集群，部分核心表一式多份。比如用戶表可能有多個業(yè)務依賴，比如社區(qū)業(yè)務、訂單物流業(yè)務等等，但如果按照業(yè)務線拆分集群之后，就無法做 Join 了，這也是我們不能接受的，所以對核心表會以一式多份的形式存在。實際使用場景下，大部分都是點查，比如查特定用戶、特定訂單的線上狀態(tài)，同時有少量的單表聚合查詢和跨表 Join 查詢。換句話說，可以認為是一個實時的數(shù)據(jù)倉庫，但又不做復雜 ETL，更多依賴線上真實數(shù)據(jù)。

我們的設計方案是把 TiDB 作為一個 MySQL/MongoDB 的從庫，但對于 MongoDB 來說可能還要做一點同步任務的數(shù)據(jù)改造工作?，F(xiàn)在規(guī)模是 10 節(jié)點 TiKV + 3 節(jié)點 PD 的集群總共有 3 個，后面可能會按需求擴增。

在實踐細節(jié)上，首先我們會基于 Canal 去做 oplog/binlog 的實時同步。其次，目前我們對加列之外的 DDL 支持得不夠好，這部分還需要 DBA 手工介入，但在未來會有一些改進。最后是多租戶問題，比如判斷某個部門的同事是否有權(quán)限訪問另一個部門的數(shù)據(jù)庫，這件事在線上會非常頭疼，現(xiàn)在在接入層解決這個問題，我們內(nèi)部有一個叫 venus 的展示平臺，將上層全鏈控制、認證等事情去掉，所以我們就不用關注這件事了，至少眼下不用關注。這個項目已經(jīng)開始逐步上線，基本上架構(gòu)已經(jīng)確定。

場景 2：分析類業(yè)務

分析類業(yè)務的 pipeline 如圖 7 所示，最后的 data warehouse 構(gòu)建在 AWS 上。

項目 3：分庫分表 MySQL ETL

這個場景下的第一個項目是做分庫分表的 MySQL ETL。以最大的表為例，上游 10 節(jié)點的MySQL，共計 10000 個分表，存量數(shù)據(jù) 1000 億條左右，每日增量 10 億+，QPS 寫入均值 3000 條/s，峰值接近 10000 條/s，平臺促銷活動對這部分影響也不大，甚至反而會降低，因為活動主要是電商部門在做，社區(qū)的查詢需求反而變少。我們在 TiDB 離線庫保留了大約 30 天增量監(jiān)控數(shù)據(jù)，全量數(shù)據(jù)存在 S3 上，每日夜間（白天偶爾）會有基于 sqoop 的抽數(shù)任務觸發(fā)。集群規(guī)模方面，目前使用 10 節(jié)點 TiKV + 3 節(jié)點 PD。

在實踐細節(jié)方面，首先我們對 MySQL 自增 ID 進行了處理，然后對 sqoop 進行了一些基于 TiDB 的細節(jié)上適配，最后調(diào)整 TiDB 的 max transaction size 以優(yōu)化抽取率。除此之外，還有一個值得一提的事情，因為實體數(shù)據(jù)（用戶/筆記/訂單數(shù)據(jù)等）不宜硬刪除，但是在 MySQL 關系表做軟刪除是非?？膳碌氖虑?，最后可能會因為數(shù)據(jù)量太過于龐大造成雪崩。但 TiDB 不一樣，我們把線上的硬刪除變成了 TiDB 的軟刪除，這對于數(shù)倉來說是非常有價值的事情。對于每天全量抽數(shù)的表來說，無論軟硬刪除，第二天數(shù)倉里的數(shù)據(jù)總是對的。但是對于大數(shù)量的場景，全量抽數(shù)代價過高，就會采取增量抽取的方式，即設置一個條件，一般是 update_time 為今天。這時候硬刪除就存在問題了：上面的 query 條件無法判斷一條記錄究竟是被刪除了，還是在當天沒有被更新。而前面又提到，關系表上是不適合做軟刪除的。所以我們在做 ETL 的時候，線上做 delete 的操作，我們在 TiDB 上會新增一個 is_deleted 字段，并將其設置為 true。這個時候有一個小細節(jié)，刪除這個操作的時間戳怎么設置。刪除這個操作時的時間戳是跟普通寫入的時間戳不一樣的。普通的寫入，時間戳就是線上庫的 update time，但是刪除的時候是不會帶上線上的 update_time 的，所以因為這條記錄被硬刪除了，時間戳都找不到了，這時我們只能用收到這條消息的 update_time 去做它的時間戳，這時就會有些小問題，當然這個問題我們還沒有完全解決掉，假設大家有類似的需求的話，我們可以私下交流討論。目前這個項目已經(jīng)上線，運行穩(wěn)定。

項目 4：MySQL 歸檔

項目 4 MySQL 歸檔是基于項目 3 的演進。業(yè)務背景方面，以最大的表為例，主要為物流倉儲部門的訂單及衍生信息，存量非常非常大，每月進行歸檔到 TiDB 的數(shù)據(jù)有數(shù)十億，但對 QPS 要求不是很高，與業(yè)務方討論之后暫定，過去一年半的記錄存放在 TiDB 供業(yè)務方查詢，更久遠的記錄歸檔到 S3/Cos 上。

項目 4 與項目 3 代碼相比處理的場景更復雜一些，因為它之前 MySQL 的分庫分表邏輯不像項目 3 那些清晰，集群規(guī)模也會相對大一些，目前是 25 個 TiKV 節(jié)點 + 3 個 PD 節(jié)點，未來可有擴容的需求。實現(xiàn)細節(jié)上，項目 4 和項目 3 類似，這里就不贅述了。

場景 3：線上服務

TiDB 接入實時數(shù)據(jù)寫入服務的業(yè)務有以下四個考慮：

• 第一點是代碼更改成本，這一項成本已經(jīng)比較低了，因為基本上都是 jdbc 連接，但多多少少會有一些變更。

• 第二點是數(shù)據(jù)遷移成本，對于已經(jīng)上線的業(yè)務來說，遷移數(shù)據(jù)都是一件非常費勁的事情，尤其是我們還要求不停服務進行熱遷移的話。

• 第三點是運維成本，從原本的 MySQL 切換到我們自己維護 TiDB ，其實無形中增加了運維成本，尤其是在掛盤率比較高的場景下。

• 第四點是技術棧成本，因為有些人對 TiDB 不熟悉，會比較害怕接觸和使用，絕大部分人更愿意用自己熟悉的東西，所以需要有一個知識學習的過程，這也是一個成本。

現(xiàn)在我們已經(jīng)有一部分線上業(yè)務從 Hive 離線導入到 TiDB 做 T+1 級別數(shù)據(jù)服務，而且我們新上線業(yè)務的關系型數(shù)據(jù)庫選型已經(jīng)開始傾向于 TiDB，主要是因為它的擴展性為我們節(jié)省了很大的時間成本，尤其是業(yè)務增長比較快的情況下，選擇 MySQL 分庫分表其實是一件代價極其大的事情。

我記得之前有同事問了一個問題，說這個場景用別的東西也可以做，為什么一定要用 TiDB 呢？為什么要用牛刀來殺一只雞呢？我回答他：有種情況是你找不到一只牛來殺，只能先“殺雞”成功了，未來才有“殺?！钡臋C會，但是大家不要認為“殺雞用牛刀”是一件很蠢事情，這可以理解為一個鑒定或者測試的過程。

四、未來 TiDB 在小紅書的接入計劃

最后分享一下 TiDB 未來在小紅書的接入方向。

• 首先在 ETL 方面，TiDB 的事務隔離性對某些場景來說有點高，我們希望能自定義事務隔離需求，比如兩個事務有沖突，但我們實際的寫入需求只要最終一致性。但是從目前 TiDB 的設計來說，這個需求可能比較困難，但是也不排除將這個事情 raise 起來的可能性。

• 第二個很重要的事情是跨數(shù)據(jù)中心的部署，這是我們未來會重點關注的方向，可能最終會得到一個通用的解決方案，目前的規(guī)劃還不是特別明晰，因為未來業(yè)務可能在不同的云會有不同的形態(tài)，我們也希望能找到成本相對更低的解決方案。

• 第三點是自動化運維，目前是往 TiDB + K8s 的方向推動，更好的解決集群部署問題，因為在虛機上部署還是比較痛苦的。

• 最后，我們已經(jīng)有同事負責調(diào)研 TiFlash、Tidis，但目前還沒有線上應用在依賴。同時我們也在做 CK 和 TiFlash 的對比調(diào)研，目前 CK 已經(jīng)在線上提供服務，未來如果 TiFlash 的調(diào)研結(jié)論是比較優(yōu)秀的，肯定也會有計劃替換。

關于TiDB從 0 到 200+ 節(jié)點的小紅書探索和應用是怎樣的問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業(yè)資訊頻道了解更多相關知識。