TiDB 在小紅書(shū)從 0 到 200+ 節(jié)點(diǎn)的探索和應(yīng)用

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

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

1. 目前小紅書(shū)數(shù)據(jù)服務(wù)整體架構(gòu)，以及從數(shù)據(jù)流角度如何對(duì)不同數(shù)據(jù)庫(kù)服務(wù)進(jìn)行定義和劃分。
2. 從基本功能、數(shù)據(jù)同步、部署管理、運(yùn)維、二次開(kāi)發(fā)及優(yōu)化、安全等多個(gè)維度解讀小紅書(shū)在數(shù)據(jù)庫(kù)選型的考慮因素及思考。
3. TiDB 的適用場(chǎng)景

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

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

通過(guò)實(shí)時(shí)數(shù)據(jù)流（dataflow）將數(shù)據(jù)導(dǎo)入到離線(xiàn)數(shù)據(jù)庫(kù)（offline database）支撐離線(xiàn)分析以及實(shí)時(shí)展示的場(chǎng)景，也就是圖 1 最下層的展示類(lèi)服務(wù)（presentation）和數(shù)倉(cāng)（data warehouse）。

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

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

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

對(duì)于一個(gè)新的數(shù)據(jù)庫(kù)或數(shù)據(jù)服務(wù)組件選型（如 TiDB），我們?cè)搹哪男┓矫嫒ト胧指闱宄奶匦?？下面分享一下我們的?jīng)驗(yàn)。

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

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

1. 數(shù)據(jù)同步與處理相關(guān)解決方案

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

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

接下來(lái)考察離線(xiàn)導(dǎo)出，比如如果我們依賴(lài) Hive、 Spark 做離線(xiàn)分析，那么可能要放在 HDFS、S3 等對(duì)象存儲(chǔ)上，就需要離線(xiàn)導(dǎo)出，一般是每天導(dǎo)出一次。

第三點(diǎn)是實(shí)時(shí)導(dǎo)出，即在實(shí)時(shí)場(chǎng)景下可能需要導(dǎo)出到消息中間件，比如 Kafka、RocketMQ 等。

第四點(diǎn)是離線(xiàn)導(dǎo)入，導(dǎo)入的場(chǎng)景一般是在離線(xiàn)的引擎計(jì)算的結(jié)果，作為評(píng)估的指標(biāo)再寫(xiě)入線(xiàn)上的 database 提供數(shù)據(jù)服務(wù)。

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

部署其實(shí)非常重要，它涵蓋以下 5 個(gè)方面。

第一點(diǎn)是組件管理界面。當(dāng)集群多到一定程度時(shí)，如果你沒(méi)有一個(gè)很好的管理界面，會(huì)連自己用的是什么集群都記不清楚。所以管理界面非常必要，而且最初可能是 1 個(gè)集群 1 個(gè)管理界面，然后是 100 個(gè)集群 1 個(gè)管理界面。

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

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

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

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

1. 運(yùn)維的易用性

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

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

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

1. 其他考慮因素

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

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

三、TiDB 在小紅書(shū)多場(chǎng)景下的應(yīng)用

場(chǎng)景 1：展示類(lèi)業(yè)務(wù)

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

項(xiàng)目 1：大促實(shí)時(shí)看板

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

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

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

這個(gè)項(xiàng)目最終全程寫(xiě)入和查詢(xún)?cè)诖蟠倨陂g保持穩(wěn)定，寫(xiě)入時(shí)延小于 20ms，查詢(xún)時(shí)延小于 1s，因?yàn)槲覀冃枰?2s 做一次查詢(xún)，這個(gè)響應(yīng)時(shí)間是能滿(mǎn)足要求的。

項(xiàng)目 2：實(shí)時(shí)業(yè)務(wù)數(shù)據(jù)展示

這個(gè)項(xiàng)目背景有兩點(diǎn)：

第一，我們業(yè)務(wù)方有實(shí)時(shí)分析的需求，需要實(shí)時(shí)觀測(cè)線(xiàn)上庫(kù)寫(xiě)入內(nèi)容，可能是針對(duì)某個(gè)用戶(hù)做一些查詢(xún)，還可能是一個(gè)非常大的 query，比如需要快速看到新上線(xiàn)功能的效果，尤其是在實(shí)驗(yàn)以及風(fēng)控等項(xiàng)目上響應(yīng)時(shí)間要求非常高。

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

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

我們的設(shè)計(jì)方案是把 TiDB 作為一個(gè) MySQL/MongoDB 的從庫(kù)，但對(duì)于 MongoDB 來(lái)說(shuō)可能還要做一點(diǎn)同步任務(wù)的數(shù)據(jù)改造工作。現(xiàn)在規(guī)模是 10 節(jié)點(diǎn) TiKV + 3 節(jié)點(diǎn) PD 的集群總共有 3 個(gè)，后面可能會(huì)按需求擴(kuò)增。

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

場(chǎng)景 2：分析類(lèi)業(yè)務(wù)

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

項(xiàng)目 3：分庫(kù)分表 MySQL ETL

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

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

項(xiàng)目 4：MySQL 歸檔

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

項(xiàng)目 4 與項(xiàng)目 3 代碼相比處理的場(chǎng)景更復(fù)雜一些，因?yàn)樗?MySQL 的分庫(kù)分表邏輯不像項(xiàng)目 3 那些清晰，集群規(guī)模也會(huì)相對(duì)大一些，目前是 25 個(gè) TiKV 節(jié)點(diǎn) + 3 個(gè) PD 節(jié)點(diǎn)，未來(lái)可有擴(kuò)容的需求。實(shí)現(xiàn)細(xì)節(jié)上，項(xiàng)目 4 和項(xiàng)目 3 類(lèi)似，這里就不贅述了。

場(chǎng)景 3：線(xiàn)上服務(wù)

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

第一點(diǎn)是代碼更改成本，這一項(xiàng)成本已經(jīng)比較低了，因?yàn)榛旧隙际?jdbc 連接，但多多少少會(huì)有一些變更。

第二點(diǎn)是數(shù)據(jù)遷移成本，對(duì)于已經(jīng)上線(xiàn)的業(yè)務(wù)來(lái)說(shuō)，遷移數(shù)據(jù)都是一件非常費(fèi)勁的事情，尤其是我們還要求不停服務(wù)進(jìn)行熱遷移的話(huà)。

第三點(diǎn)是運(yùn)維成本，從原本的 MySQL 切換到我們自己維護(hù) TiDB ，其實(shí)無(wú)形中增加了運(yùn)維成本，尤其是在掛盤(pán)率比較高的場(chǎng)景下。

第四點(diǎn)是技術(shù)棧成本，因?yàn)橛行┤藢?duì) TiDB 不熟悉，會(huì)比較害怕接觸和使用，絕大部分人更愿意用自己熟悉的東西，所以需要有一個(gè)知識(shí)學(xué)習(xí)的過(guò)程，這也是一個(gè)成本。

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

我記得之前有同事問(wèn)了一個(gè)問(wèn)題，說(shuō)這個(gè)場(chǎng)景用別的東西也可以做，為什么一定要用 TiDB 呢？為什么要用牛刀來(lái)殺一只雞呢？我回答他：有種情況是你找不到一只牛來(lái)殺，只能先“殺雞”成功了，未來(lái)才有“殺牛”的機(jī)會(huì)，但是大家不要認(rèn)為“殺雞用牛刀”是一件很蠢事情，這可以理解為一個(gè)鑒定或者測(cè)試的過(guò)程。

四、未來(lái) TiDB 在小紅書(shū)的接入計(jì)劃

最后分享一下 TiDB 未來(lái)在小紅書(shū)的接入方向。

首先在 ETL 方面，TiDB 的事務(wù)隔離性對(duì)某些場(chǎng)景來(lái)說(shuō)有點(diǎn)高，我們希望能自定義事務(wù)隔離需求，比如兩個(gè)事務(wù)有沖突，但我們實(shí)際的寫(xiě)入需求只要最終一致性。但是從目前 TiDB 的設(shè)計(jì)來(lái)說(shuō)，這個(gè)需求可能比較困難，但是也不排除將這個(gè)事情 raise 起來(lái)的可能性。

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

第三點(diǎn)是自動(dòng)化運(yùn)維，目前是往 TiDB + K8s 的方向推動(dòng)，更好的解決集群部署問(wèn)題，因?yàn)樵谔摍C(jī)上部署還是比較痛苦的。

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

文：張俊駿 @PingCAP

PS：本公司承接小紅書(shū)關(guān)鍵詞排名，下拉推薦，熱門(mén)搜索，達(dá)人種草，代寫(xiě)代發(fā)，金冠薯，數(shù)據(jù)優(yōu)化等業(yè)務(wù)；

咨詢(xún)微信：139 1053 2512 (同電話(huà))

首席增長(zhǎng)官CGO薦讀小紅書(shū)推廣：

• 《?小紅書(shū)筆記排名，熱搜推廣，KOL種草，評(píng)論點(diǎn)贊收藏，下拉推薦?》
• 《小紅書(shū)種草的內(nèi)容電商邏輯，紅利還在》
• 《 掌握以下幾點(diǎn)，輕松打造有質(zhì)量的小紅書(shū)種草軟文！ 》

更多精彩，關(guān)注：增長(zhǎng)黑客（GrowthHK.cn）

增長(zhǎng)黑客（Growth Hacker）是依靠技術(shù)和數(shù)據(jù)來(lái)達(dá)成各種營(yíng)銷(xiāo)目標(biāo)的新型團(tuán)隊(duì)角色。從單線(xiàn)思維者時(shí)常忽略的角度和高度，梳理整合產(chǎn)品發(fā)展的因素，實(shí)現(xiàn)低成本甚至零成本帶來(lái)的有效增長(zhǎng)…