現(xiàn)狀
小米從創(chuàng)立到今天已經(jīng)過(guò)去了 10 年，2020 年 8 月 16 日雷總在線上直播，宣布小米正式開(kāi)啟新十年的創(chuàng)業(yè)者計(jì)劃。第二個(gè)月，云平臺(tái)部門(mén)的數(shù)據(jù)庫(kù)與存儲(chǔ)團(tuán)隊(duì)啟動(dòng)了 TiDB 項(xiàng)目，作為團(tuán)隊(duì)在小米新十年中的第一個(gè)三年規(guī)劃。2021 年 1 月，TiDB 產(chǎn)品正式在小米的內(nèi)部私有云上線，落地各項(xiàng)業(yè)務(wù)。
先介紹一下小米與 TiDB 的現(xiàn)狀。經(jīng)過(guò)近一年的發(fā)展，TiDB 在小米已經(jīng)部署了 20 多個(gè)集群，TiKV 節(jié)點(diǎn)也達(dá)到了三位數(shù)，覆蓋的業(yè)務(wù)場(chǎng)景包括電商、供應(yīng)鏈、大數(shù)據(jù)等等。右邊這個(gè)米字 logo 的詞云是由我們的一部分業(yè)務(wù)線組成的，包括了零售中臺(tái)、小米有品、智能制造、代工廠、還有門(mén)店等。
小米經(jīng)過(guò)十年的發(fā)展，在傳統(tǒng)數(shù)據(jù)庫(kù)上的使用中，確實(shí)遇到了相當(dāng)多的痛點(diǎn)。因?yàn)闀r(shí)間有限，這只列舉其中四個(gè)。
第一，容量瓶頸。我們內(nèi)部的單機(jī)只有 2.6 T，經(jīng)過(guò)十年的發(fā)展，很多業(yè)務(wù)線單機(jī)的存儲(chǔ)都已經(jīng)達(dá)到了 2 T 以上，甚至只有幾百 G 的空間剩余，馬上就要滿了。為了解決容量問(wèn)題，之前一般采用傳統(tǒng)的分庫(kù)分表解決方案，如果你對(duì)業(yè)務(wù)邏輯沒(méi)有很深的了解，是成本非常高的事情，然而業(yè)務(wù)線的建設(shè)時(shí)間往往已經(jīng)過(guò)去很久，以至于代碼都不知道從何下手去重構(gòu)。通過(guò)引入 TiDB 就能夠比較輕松地解決這個(gè)問(wèn)題。
第二，高可用。MySQL 的主從架構(gòu)下，我們嘗試使用很多方法來(lái)做高可用實(shí)現(xiàn)，比如通過(guò) LB + Orchestrator + 中間件的方案來(lái)解決。但是，如果半夜主庫(kù)掛了，可能仍然睡不好覺(jué)。
第三，高寫(xiě)入。TiDB 作為一個(gè)分布式數(shù)據(jù)庫(kù)，很好地解決了多點(diǎn)寫(xiě)入的問(wèn)題。傳統(tǒng)的 MySQL 主從架構(gòu)，只能寫(xiě)到主庫(kù)上，很容易達(dá)到瓶頸，達(dá)到瓶頸之后就會(huì)帶來(lái)非常強(qiáng)的主從延遲。主從延遲就會(huì)帶來(lái)一致性問(wèn)題，一致性問(wèn)題對(duì)很多業(yè)務(wù)來(lái)說(shuō)是一個(gè)災(zāi)難。
最后，我們還有一些歷史包袱。小米十年發(fā)展以來(lái)，我們內(nèi)部有各種各樣的解決方案去適應(yīng)業(yè)務(wù)規(guī)模的增長(zhǎng),但都各有優(yōu)劣。小米曾開(kāi)源過(guò)一個(gè)叫 Gaea 的中間件，也是支持分庫(kù)分表的，我們內(nèi)部還有其他的中間件，方案非常多，而且都分散在各個(gè)業(yè)務(wù)線。一旦相關(guān)人員有一些變動(dòng)，就會(huì)變得非常難以維護(hù)。但是 TiDB 實(shí)現(xiàn)了這些方案的打包，我不再需要考慮是用這個(gè)中間件還是那個(gè)中間件，他們分別適應(yīng)什么樣的場(chǎng)景。
發(fā)展
我們發(fā)展的非�？�，從我們剛剛了解 TiDB，到去年 9 月份接入了第一個(gè)業(yè)務(wù)，然后我們開(kāi)始正式立項(xiàng)，建立團(tuán)隊(duì)。在今年 1 月份，我們就完成了包括部署、監(jiān)控、告警、工單等基礎(chǔ)能力的建設(shè)，開(kāi)始類似于一個(gè) DBaaS 平臺(tái)，去對(duì)業(yè)務(wù)提供服務(wù)。
到今年 4 月，我們開(kāi)始做質(zhì)量提升工程，完成了小時(shí)級(jí)的備份恢復(fù)，還有巡檢系統(tǒng)、兩地三中心等方案的落地，大大提升了業(yè)務(wù)質(zhì)量。到今年 7 月份，業(yè)務(wù)規(guī)模開(kāi)始快速增長(zhǎng)，TiKV 節(jié)點(diǎn)很快就過(guò)百了。我們現(xiàn)在看到的節(jié)點(diǎn)數(shù)過(guò)百，完成業(yè)務(wù)規(guī)模翻倍，其實(shí)僅僅就兩三個(gè)月的時(shí)間。因?yàn)楹芏鄻I(yè)務(wù)確實(shí)看到了 TiDB 很大的一個(gè)可擴(kuò)展性，在遇到存儲(chǔ)瓶頸時(shí)，他們也很愿意去做這個(gè)遷移接入。后面，我們也會(huì)持續(xù)的去做 TiDB、TiKV 的穩(wěn)定性、性能還有成本等方面的工作，并且會(huì)重倉(cāng)云原生的方向。
我們正式成立 TiDB 團(tuán)隊(duì)投入到 TiDB 產(chǎn)品的落地中還不到一年，和很多廠商相比算是后輩，我們也充分利用了后發(fā)優(yōu)勢(shì)，直接引入了大量生態(tài)產(chǎn)品如 BR、TiCDC、TiUP、DM 等等這些生態(tài)產(chǎn)品極大地減小了我們的運(yùn)維成本，方便我們構(gòu)建 TiDB 服務(wù)平臺(tái)，促進(jìn)了產(chǎn)品的快速發(fā)展。
挑戰(zhàn)
其實(shí)接入 TiDB 也不是那么一帆風(fēng)順。
第一是從分庫(kù)分表到 TiDB 的遷移過(guò)程。歷史問(wèn)題造成的上游數(shù)據(jù)質(zhì)量堪憂（如業(yè)務(wù)自行分庫(kù)分表的設(shè)計(jì)，主鍵ID重復(fù)，甚至觸發(fā)器、存儲(chǔ)過(guò)程等），需要業(yè)務(wù)端做改造，從而導(dǎo)致遷移周期漫長(zhǎng)。
第二是復(fù)雜的業(yè)務(wù) SQL 導(dǎo)致查詢計(jì)劃不準(zhǔn)。我們的老業(yè)務(wù)遷到 TiDB 之后，某一個(gè) SQL 突然比以前執(zhí)行時(shí)間大大增長(zhǎng)。SPM 無(wú)法完全解決，一是 SQL 變化多、數(shù)量大。二是根據(jù) cost，執(zhí)行計(jì)劃也會(huì)變化。而很多老業(yè)務(wù)的復(fù)雜 SQL 非常多，我們需要一一去調(diào)整查詢計(jì)劃，去幫業(yè)務(wù)做調(diào)優(yōu)。
第三是部分內(nèi)部工具對(duì)接，比如為了對(duì)接內(nèi)部消息隊(duì)列，我們建了一個(gè) TiCDC 的內(nèi)部分支版本、Drainer 的內(nèi)部分支版本，當(dāng)然后續(xù)比較根源的解決辦法是內(nèi)部工具去迎合外部開(kāi)源工具，支持相應(yīng)開(kāi)源工具的接口。
最后，硬件、軟件多方面的性能調(diào)教。比如一些反直覺(jué)的情況：我們之前使用的一款NVMe 硬盤(pán)表面上磁盤(pán)性能比 SSD 要高，但實(shí)測(cè) sysbench 的 workload 和業(yè)務(wù)的 workload 都有不小性能差距，有的情況下甚至 NVMe 的并發(fā)性能比 SSD 還要差一倍。硬件的適配和兼容也是后期我們調(diào)優(yōu)的一個(gè)方向。
點(diǎn)贊
第一個(gè)是社區(qū)支持非常友好，文檔非常完善，因此我們的接入非常快速。我之前也講了，其實(shí)僅僅一個(gè)季度的時(shí)間，我們就把整個(gè)以前看來(lái)各種高大上的平臺(tái)做好，可以對(duì)業(yè)務(wù)提供服務(wù)了。
第二個(gè)是完善的數(shù)據(jù)庫(kù)周邊生態(tài)，降低了運(yùn)維的成本。我們知道一個(gè)數(shù)據(jù)庫(kù)產(chǎn)品的落地需要有自動(dòng)化部署、監(jiān)控告警、運(yùn)維管理平臺(tái)等一系列基建，得益于 TiDB 社區(qū)良好的可觀測(cè)性和豐富的生態(tài)組件如 TiUP / BR / Dashboard 等等，我們很輕松的完成了相關(guān)建設(shè)，極大降低了運(yùn)維成本，減輕了運(yùn)維壓力。
第三個(gè)，跨機(jī)房，多機(jī)房容災(zāi)，異地多活這個(gè)話題也是一個(gè)很深的話題。我們真正實(shí)踐起來(lái)發(fā)現(xiàn) TiDB 在跨機(jī)房上表現(xiàn)得非常優(yōu)秀，很容易落地三中心的計(jì)劃。對(duì)于一些需要異地容災(zāi)的業(yè)務(wù)來(lái)說(shuō)，TiDB是一個(gè)很好的選擇。
第四個(gè)，加密存儲(chǔ)及傳輸?shù)墓δ?/STRONG>。透明數(shù)據(jù)加密 (Transparent Data Encryption)，簡(jiǎn)稱 TDE，是 TiDB 推出的一個(gè)新特性，應(yīng)用在風(fēng)控隱私集群上，極大簡(jiǎn)化了業(yè)務(wù)邏輯。
最后是說(shuō)下 HTAP 的內(nèi)容。我們內(nèi)部也有一些 HTAP 的實(shí)踐，右邊這個(gè)指標(biāo)是我們的一個(gè)核心業(yè)務(wù)做的 HTAP 的實(shí)踐，我們之前通過(guò) TiSpark 打在 TiKV 上的任務(wù)時(shí)間是在左邊，我們換了 TiFlash 之后，我們可以看到，無(wú)論是從任務(wù)執(zhí)行時(shí)間，還是 P99 延時(shí)、負(fù)載上，我們都提高了不只三倍。如果我們自己去優(yōu)化這三倍的性能，需要投入的精力有多少，大家做過(guò)性能優(yōu)化的應(yīng)該都知道。TiFlash 的引入大大簡(jiǎn)化了我們的工作。
連接
前面我們提到，TiDB 豐富的生態(tài)，極大降低了我們的運(yùn)維成本。取之社區(qū)，回饋社區(qū)。包括 TiDB 產(chǎn)品在內(nèi)，很多生態(tài)產(chǎn)品我們都有提 patch�，F(xiàn)在，小米團(tuán)隊(duì)是多個(gè)產(chǎn)品的 contributor，包括 dumpling、br、ticdc、tiup 等，TiDB 產(chǎn)品目前是 active contributor。
畫(huà)虛線的產(chǎn)品 TiKV、TiDB Operator，雖然目前還不是 contributor，但是我們和 PingCAP 已經(jīng)達(dá)成合作，后續(xù)將持續(xù)貢獻(xiàn) TiDB、TiKV、TiDB Operator 產(chǎn)品，同時(shí)也是符合我們持續(xù)性優(yōu)化穩(wěn)定性、性能及成本目標(biāo)。
我們不僅僅是 DBA，還是研發(fā)工程師，都有代碼層面了解產(chǎn)品的執(zhí)拗，當(dāng)然對(duì)生態(tài)產(chǎn)品的代碼了解也有助于我們落地到業(yè)務(wù)中，同時(shí)反哺社區(qū)，幫助完善生態(tài)，也是開(kāi)源社區(qū)所倡導(dǎo)的良性循環(huán)。
探索
玩過(guò)云的，大家可能都知道，云發(fā)展歷程中經(jīng)歷過(guò)很多基礎(chǔ)設(shè)施的不同潮流，包括選擇私有云還是公有云，以及底層的一些框架如何使用。
因?yàn)樾∶椎膰?guó)際化業(yè)務(wù)現(xiàn)在越來(lái)越發(fā)達(dá)，我們對(duì)海外的公有云的需求也會(huì)越來(lái)越大。所以我們制訂了一個(gè)全球混合多云的戰(zhàn)略。我們同時(shí)使用 IDC 機(jī)房和多種公有云，并且對(duì)外封裝，把他變成一個(gè)屏蔽細(xì)節(jié)的、全球化的混合多云。
這個(gè)混合多云的具體有哪些好處呢？
首先是安全性。在國(guó)際化業(yè)務(wù)中，我們可以根據(jù)需求把數(shù)據(jù)存儲(chǔ)在不同的位置。這個(gè)是可以通過(guò)我們的存儲(chǔ)來(lái)做，業(yè)務(wù)無(wú)需關(guān)心。第二個(gè)靈活性。我們可以對(duì)業(yè)務(wù)屏蔽掉底層這個(gè)復(fù)雜的多云環(huán)境，從而提供一個(gè)通用的環(huán)境。這樣我們?cè)谇袚Q供應(yīng)商，或者是做一些底層操作的時(shí)候，業(yè)務(wù)就不會(huì)有感知。第三個(gè)成本。云原生的好處之一，就是優(yōu)化調(diào)度，資源共享。第四個(gè)質(zhì)量。云的另一個(gè)好處就是高彈， 我們可以快速完成擴(kuò)縮容。而我們?nèi)绾卧诨旌显葡伦龈邚�，又是一個(gè)非常大的挑戰(zhàn)。
我這里畫(huà)了一個(gè)非常粗粒度的規(guī)劃。
用戶層我們不展開(kāi)講。服務(wù)是我們給用戶提供的服務(wù)，包括運(yùn)維管控、用戶平臺(tái)、數(shù)據(jù)流以及一些調(diào)優(yōu)服務(wù)。然后是管理：由于 TiDB Operator 部署在單個(gè) K8s 集群中，控制范圍僅能在單個(gè) K8s 集群，而我們的需求可能包含跨機(jī)房，跨云，甚至 IDC 和 K8s 混合（比如 TiCDC 部署在云中，而 TiDB 集群在 IDC 物理機(jī)上），所以我們需要在 TiDB Operator 上另外增加一些自定義調(diào)度。所以我們可以看到除了 TiDB Operator、傳統(tǒng)的 CMDB，我們?cè)黾恿艘粋�(gè)自定義的 Operator。
底層的資源剛剛已經(jīng)介紹了大部分，需要提的一項(xiàng)是底層的存儲(chǔ)資源。從本地磁盤(pán)到云盤(pán)到 Ceph，再到其他分布式存儲(chǔ)。開(kāi)發(fā)者嘉年華的吐槽大會(huì)環(huán)節(jié)，美團(tuán)的黃瀟老師對(duì) TiDB 對(duì)演進(jìn)方向有一個(gè)靈魂拷問(wèn)：我們未來(lái) TiKV 到底是繼續(xù)提高調(diào)度呢，還是說(shuō)去往 PolarDB 這邊靠，做一些共享存儲(chǔ)的方案？東旭的回答是：我們?yōu)槭裁床欢甲瞿兀?/P>
其實(shí)我們也在研究這個(gè)問(wèn)題。在支持本地磁盤(pán)和云盤(pán)的過(guò)程中，我們也在調(diào)研云原生的分布存儲(chǔ)。StarFS 是我們數(shù)據(jù)庫(kù)與存儲(chǔ)團(tuán)隊(duì)目前正在自研的分布式云原生文件系統(tǒng)，與普通分布式存儲(chǔ)如 HDFS、Ceph 等有區(qū)別，主打高性能、低延遲。分布式存儲(chǔ)有一個(gè)天然弱勢(shì)就是 latency 不穩(wěn)定，所以很難作為線上數(shù)據(jù)庫(kù)的存儲(chǔ)后端，目前沒(méi)有能滿足數(shù)據(jù)庫(kù)需求的開(kāi)源分布式存儲(chǔ)。StarFS計(jì)劃采用基于高性能存儲(chǔ)介質(zhì) SSD、NVMe，采用 SPDK、RDMA 等技術(shù)實(shí)現(xiàn)適合數(shù)據(jù)庫(kù)的分布式存儲(chǔ)后端。
當(dāng)然，這只是初步規(guī)劃，并在有條不紊推進(jìn)過(guò)程中，也期待引進(jìn)越來(lái)越多的新技術(shù)，來(lái)迭代優(yōu)化混合云的架構(gòu)設(shè)計(jì)。
云原生探索踩過(guò)一些小坑，這里技術(shù)細(xì)節(jié)比較多了。可以簡(jiǎn)單介紹一下，假如 PD-pod 假死，Operator 的控制邏輯就會(huì)失效。表面上是在 Running 的狀態(tài)，但其實(shí)這個(gè) pod 已經(jīng)無(wú)法提供服務(wù)了，這個(gè)坑也很難受。還有一些分布式存儲(chǔ)的調(diào)度問(wèn)題、故障切換問(wèn)題造成服務(wù)不可用的問(wèn)題等。另外 Controller 的串行化設(shè)計(jì)也需要注意。我們知道 Controller 是把你的集群控制在一個(gè)期望的狀態(tài)，但是這個(gè)串行化的控制邏輯會(huì)讓你在擴(kuò)容 TiDB 的時(shí)候，假如 TiDB 擴(kuò)容不成功，TiKV 也無(wú)法擴(kuò)容成功，這樣的話就導(dǎo)致阻塞，導(dǎo)致你整個(gè)運(yùn)維操作的失敗。
預(yù)見(jiàn)
最后表達(dá)一下期望，我們已經(jīng)和 TiDB 社區(qū)建立了深度的合作，我們會(huì)共同推進(jìn)混合多云戰(zhàn)略，推進(jìn)核心業(yè)務(wù)的 MySQL 遷移，以及做一些 Committer 的培養(yǎng)。在內(nèi)部也會(huì)繼續(xù)推進(jìn) TiDB 落地到小米金融、小米 AI、小米 IoT 等多個(gè)業(yè)務(wù)場(chǎng)景。
