分布式NewSQL數(shù)據(jù)庫UCloud TiDB Service 是如何煉成的？

　　TiDB 是 PingCAP 公司研發(fā)的開源分布式關(guān)系型數(shù)據(jù)庫，結(jié)合了傳統(tǒng)的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，具備「分布式強一致性事務(wù)、在線彈性水平擴展、故障自恢復(fù)的高可用、跨數(shù)據(jù)中心多活」等核心特性，是大數(shù)據(jù)時代理想的數(shù)據(jù)庫集群和云數(shù)據(jù)庫解決方案。

　　UCloud 于今年 8 月 將 TiDB 公有云化并推出UCloud TiDB Service，當(dāng)前使用的 TiDB 版本為 3.0.5 。UCloud TiDB Service相比裸機部署性能并無損耗，提供跨可用區(qū)高可用，對監(jiān)控和Binlog等做了改造增強，使用戶可獲得一鍵創(chuàng)建、按需付費、靈活擴縮容的TiDB服務(wù)。

　　UCloud TiDB Service為什么叫UCloud TiDB Service？這里強調(diào)Service是因為從公有云用戶的角度來看，TiDB運行在公有云平臺上，其實是以服務(wù)的形式呈現(xiàn)而不是一個物理資源。UCloud TiDB Service是一個支持原生MySQL協(xié)議的，高性能、跨可用區(qū)高可用、高可擴展的，面向Serverless的分布式數(shù)據(jù)庫服務(wù)。

　　兼容原生MySQL協(xié)議大多數(shù)情況下，無需修改代碼即可從 MySQL 輕松遷移至 TiDB，分庫分表后的 MySQL 集群亦可通過 TiDB 工具進行實時遷移。

　　跨可用區(qū)高可用TiDB本身雖具備一定高可用性，但一般用戶沒有跨可用區(qū)部署條件。UCloud TiDB Service的所有組件都是跨可用區(qū)部署。TiDB所有模塊的多實例部署能力，結(jié)合UCloud跨可用區(qū)部署能力，UCloud TiDB Service可抵御可用區(qū)級故障。

　　動態(tài)擴展TiDB無論是計算節(jié)點還是存儲節(jié)點都可以實現(xiàn)水平擴展，通過簡單地增加新節(jié)點即可按需擴展吞吐或存儲，輕松應(yīng)對高并發(fā)、海量數(shù)據(jù)場景。

　　ServerlessServerless的產(chǎn)品形態(tài)讓用戶更加簡單快捷的使用到TiDB，無需關(guān)心底層的物理資源，也無需關(guān)心底層分布部署的細節(jié)。

　　按需付費，接入成本低無需指定CPU、內(nèi)存、硬盤等資源，用戶只需按實際使用的硬盤和存儲量進行付費，節(jié)省了前期的硬件成本投入。

　　性能對比

　　我們做了一個測試，在相同物理配置（Intel Xeon E5-2620 v4, DDR4_16GB_2400MHz x12, U.2_NVMe_3.2TB x2 ）和相同軟件部署（TiDB x3, TiKV x3, PD x3 ）情況下，測試條件為sysbench 512 threads, 32 tables, 1000萬行。在裸機上部署TiDB和UCloud TiDB Service的性能對比如下表所示：

　　類別

　　指標(biāo)

　　裸機TiDB

　　UCloud

　　TiDB Service

　　對比

　　Select

　　TPS

　　95k

　　97k

　　略好

　　QPS

　　95k

　　97k

　　略好

　　Insert

　　TPS

　　21k

　　21k

　　一致

　　QPS

　　21k

　　21k

　　一致

　　Oltp

　　TPS

　　3.2k

　　3.5k

　　略好

　　QPS

　　64k

　　71k

　　略好

　　結(jié)果表明各項指標(biāo)基本一致，UCloud TiDB Service 和裸機部署相比較，并沒有帶來性能損耗，有些指標(biāo)表現(xiàn)略好。而在這背后，UCloud公有云后臺做了哪些事情呢？

　　打造分布式數(shù)據(jù)庫PaaS平臺

　　UCloud內(nèi)部做了一個分布式數(shù)據(jù)庫的PaaS平臺（如上圖），在管理功能上，左邊第一部分有物理機的資源管理，包括每次創(chuàng)建實例的時候資源分配以及實例刪除以后資源回收等等操作。第二部分是集群部署，一個創(chuàng)建過程先選取合適的物理機，檢測上面的資源是否滿足，滿足以后分配特定的一些資源出來，然后再執(zhí)行相應(yīng)的創(chuàng)建工作，這里面要創(chuàng)建TiDB集群，相應(yīng)的監(jiān)控、LB層，以及部署在公有云上都是運行在用戶VPC里面，需要做VPC網(wǎng)絡(luò)初使化等工作。第三部分是集群維護，比如某臺物理機有異常，就要把所有服務(wù)遷移到其他的節(jié)點面去。這里面主要涉及的是遷移、擴展、縮容這些工作。

　　右邊是監(jiān)控告警，主要用于對一些異常情況的及時通知告警管理；還有運營分析這塊是UCloud數(shù)據(jù)庫運營方面的管理。備份管理負責(zé)數(shù)據(jù)庫的備份與恢復(fù)，用戶可以設(shè)置比較詳細的備份策略，比如何時備份如何備份等。

　　原生協(xié)議是MySQL本來的數(shù)據(jù)流，在這里我們加了一層負載均衡，主要有兩個目的：一個是把IP地址統(tǒng)一成一個，用戶不需要管理IP地址的切換；另外針對公有云服務(wù)傳輸做一些控制，主要是帳號和系統(tǒng)方面的控制。

　　跨可用區(qū)部署實現(xiàn)高可用

　　TiDB整體是由分布式 SQL 層（TiDB）、分布式 KV 存儲引擎（TiKV）以及管理整個集群的 PD 模塊組成。如圖我們將TiDB的 所有組件進行跨可用區(qū)部署，并且提供單一高可用接入地址，單一地址的好處是用戶不需要關(guān)注多地址，也不需要做地址之間的切換，另外一個好處是整個容災(zāi)過程對業(yè)務(wù)完全透明，比如要增加/縮掉一個TiDB節(jié)點，或者要遷移到另外一臺機器時。有了統(tǒng)一地址虛IP之后，業(yè)務(wù)就完全不用考慮地址，所有的操作對用戶完全透明。

　　對監(jiān)控的改造

　　TiDB 本身使用了 Prometheus 作為監(jiān)控和性能指標(biāo)信息收集方案、Grafana 作為可視化組件進行展示、Alertmanager用于實現(xiàn)報警機制，但是都是單點部署， 并不具備容災(zāi)能力。我們將這三個模塊都進行了高可用改造。大家知道，Grafana本身是沒辦法使用TiDB存儲元數(shù)據(jù)的，我們對 Grafana源碼進行了修改，改寫了大量Multi-schema語句，并且去掉了將字段改小的操作，從而支持了Grafana使用TiDB存儲元數(shù)據(jù)。

　　如圖是一個用戶業(yè)務(wù)監(jiān)控系統(tǒng)，左邊有一個LB，兩個Grafana節(jié)點，我們通過LB連到Prometheus，從而實現(xiàn)遠程高可用。

　　對Binlog的改造

　　有這樣一個用戶場景，將TiDB 數(shù)據(jù)導(dǎo)入已有的大數(shù)據(jù)集群作數(shù)據(jù)分析， 需要輸出到 Kafka 的日志格式為 json， 以便 Flink 消費解析。由于Binlog 是 PB 格式，目前提供的 driver 只支持txt, mysql。

　　經(jīng)過我們對Binlogdriver的改造之后，Binlog支持輸出 Json 格式、支持將Json 格式日志寫入Kafka。

　　品質(zhì)改善和Bug修復(fù)

　　在打造TiDB服務(wù)期間，我們也相繼發(fā)現(xiàn)解決了原生TiDB的一些小問題，從細節(jié)上提升產(chǎn)品品質(zhì)。其中很多在官方后續(xù)的新版本中也已經(jīng)陸續(xù)得到了改善和解決，例如：

　　Drainer 輸出 db.table 格式的語句 (fixed in 3.0)；

　　TiDB 升級到2.1以后時區(qū)變化；

　　Syncer 在 retry 階段不處理 SIGTERM (fixed)；

　　Syncer can’t decode set datatype (fixed)；

　　Drainer 只寫一個partition 導(dǎo)致數(shù)據(jù)傾斜，我們可以啟動多個drainer， 每個drainer 寫一個DB；

　　Raft store 單線程瓶頸 （fixed in 3.0）；

　　Binlog 開啟/關(guān)閉10分鐘內(nèi)DDL慢 （fixed in 2.1.14）。

　　還有一些由于跟MySQL原生協(xié)議不同而導(dǎo)致語句理解上產(chǎn)生的問題，比如ID 分段自增、GC 時間導(dǎo)致連接中斷、事務(wù)條數(shù)限制（單條 KV entry 不超過 6MB、總條數(shù)不超過 30w、總大小不超過 100MB）、失敗自動重試等。這些問題經(jīng)過UCloud內(nèi)部的長時間打磨和積累，已經(jīng)達到了一個相對成熟和穩(wěn)定的形態(tài)。

　　TiDB管理模塊

　　產(chǎn)品控制臺向用戶開放了TiDB的管理模塊，分為四個部分：備份管理、恢復(fù)任務(wù)、用戶管理、Binlog同步。具體如下：

　　備份管理：創(chuàng)建 TiDB 實例時可以選擇是否開啟自動備份策略，備份策略包括備份時間、自動備份保留份數(shù)以及自動備份周期。除了自動備份，TiDB 還提供手動備份選擇

　　恢復(fù)任務(wù)：TiDB 當(dāng)前支持從備份文件恢復(fù)至一個新的 TiDB 實例，用戶需要提前準(zhǔn)備好新實例，恢復(fù)工作會覆蓋新實例數(shù)據(jù)。

　　用戶管理：TiDB提供給用戶相應(yīng)的權(quán)限管理，包括新增用戶并初始化權(quán)限 、調(diào)整用戶權(quán)限、刪除非root用戶等。

　　Binlog同步：可將 TiDB 的增量數(shù)據(jù)實時同步到其他存儲中，當(dāng)前支持 MySQL，TiDB 作為目標(biāo)存儲。

　　總結(jié)

　　可以說TiDB 是為云而生的數(shù)據(jù)庫，UCloud TiDB Service 在保證TiDB 性能沒有損耗的前提下， 將 TiDB 以服務(wù)的形式提供給用戶， 降低了用戶使用門檻， 簡化了用戶管理， 提高了容災(zāi)能力。未來，UCloud將繼續(xù)與PingCAP官方深度合作，致力于為云上數(shù)據(jù)庫創(chuàng)造更多可能性。